Apache NiFi

Sign in to the AWS Management Console, open the EC2 service, and choose Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Apache NiFi. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. NiFi is a Java application and benefits from memory, and the data volume gives it room to spool content. Choose your EC2 key pair under Key pair (login).

Under Network settings, select your VPC and subnet. Create or select a security group that allows inbound port 22 from your management network and inbound port 443 from the trusted networks that will reach the console (port 80 redirects to 443). Do not open these ports to the public internet unless you intend the console to be publicly reachable. Leave the root volume at the default size or larger.

Choose Launch instance. First boot initialisation takes approximately one to two minutes after the instance state becomes Running and the status checks pass, while NiFi generates the login password and starts up.

The following command launches an instance from the SecureAnyCloud Apache NiFi Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing. Replace <key-name> with your EC2 key pair name and <subnet-id> with your subnet ID. Replace <security-group-id> with a security group that opens ports 22 and 443 (and optionally 80) as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":20,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=nifi-01}]'

The command prints a JSON document on success. Note the instance ID. Once the instance is running, retrieve its public address with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from Step 2. The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant SSH login user

Apache NiFi on Ubuntu 24.04 ubuntu

The first boot service runs before the SSH daemon becomes ready, so the credentials file is always in place when you log in for the first time. Print it with:

ssh <login-user>@<public-ip>
sudo cat /root/apache-nifi-credentials.txt

The file is plain text and contains the NiFi URL, the administrator username (admin) and the generated login password. Copy these values somewhere secure, such as a password manager or an encrypted vault. Do not commit them to source control.

The credentials file is owned by root and readable only by root. Confirm this with:

sudo ls -l /root/apache-nifi-credentials.txt

-rw------- 1 root root 482 Jun 17 10:36 /root/apache-nifi-credentials.txt

NiFi, the nginx reverse proxy and the first boot service should all report active:

for u in nifi nginx nifi-firstboot; do printf "%s: " "$u"; systemctl is-active "$u"; done

nifi: active nginx: active nifi-firstboot: active

The deployed Java runtime is OpenJDK 21, which NiFi 2.x requires:

java -version

openjdk version "21.0.11" 2026-04-21 OpenJDK Runtime Environment (build 21.0.11+10-1-24.04.2-Ubuntu) OpenJDK 64-Bit Server VM (build 21.0.11+10-1-24.04.2-Ubuntu, mixed mode, sharing)

nginx listens on port 443 (TLS) and port 80 (which redirects to 443). It forwards to the NiFi HTTPS console bound to the loopback address on port 8443:

sudo ss -tlnp | grep -E ':80 |:443 |:8443'

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 511 0.0.0.0:443 0.0.0.0:* LISTEN 0 50 127.0.0.1:8443 *:*

Browse to https://<public-ip>/ from a machine on a network the security group allows. The edge certificate is self-signed, so your browser warns about the connection the first time. Accept the warning to proceed, or install your own certificate as described in Step 11.

The root path redirects to the NiFi user interface at /nifi/. Sign in as the admin user with the password from the credentials file.

After you sign in, NiFi presents the flow canvas, the empty workspace where you build your dataflow. The toolbar across the top carries the components you drag onto the canvas: the Processor, the Input Port, the Output Port, the Process Group and the Funnel.

The nginx HTTPS listener encrypts the connection with a self-signed certificate, which is why the browser warns on first use. Step 11 shows how to install your own CA-signed certificate so the warning disappears.

A NiFi flow is a set of processors connected by relationships. The simplest useful flow generates some data and writes it to disk.

On the canvas, drag the Processor icon from the toolbar onto the canvas. In the Add Processor dialog, filter for GenerateFlowFile, select it, and choose Add. Drag a second processor onto the canvas and add a PutFile processor.

Double-click the GenerateFlowFile processor to open its configuration. On the Scheduling tab, set the run schedule to a few seconds so it does not flood the flow. On the Properties tab, set a small file size such as 10 B. Apply the change.

Double-click the PutFile processor. On the Properties tab, set Directory to a writable path such as /var/lib/nifi/out. Apply the change.

Hover over the GenerateFlowFile processor until the connection arrow appears, then drag it onto the PutFile processor to create a connection. In the Create Connection dialog, select the success relationship and add it. On the PutFile processor, auto-terminate the success and failure relationships so the flow has somewhere to send completed work.

Select both processors, right-click and choose Start. NiFi begins generating flow files and writing them to the directory. The numbers on each processor update live to show throughput. To inspect the data in flight, right-click a connection and choose List queue.

Everything the canvas does is also available through NiFi's REST API. Request a token with the login credentials, then call the API with that token as a bearer credential. Run these commands on the instance, where the loopback HTTPS listener is reachable:

PASS="$(sudo awk -F= '/^nifi.admin.pass=/ {print $2}' /root/apache-nifi-credentials.txt)" TOKEN="$(curl -sk -X POST https://127.0.0.1:8443/nifi-api/access/token \
  --data-urlencode 'username=admin' --data-urlencode "password=${PASS}")" curl -sk https://127.0.0.1:8443/nifi-api/flow/current-user \
  -H "Authorization: Bearer ${TOKEN}" | head -c 400

The first call returns a signed JSON Web Token. The second call returns the identity of the authenticated user, which confirms that the API round trip works end to end.

The NiFi install lives under /opt/nifi, and its working data lives on the dedicated volume mounted at /var/lib/nifi:

ls -d /opt/nifi/nifi-2.9.0 findmnt /var/lib/nifi -o TARGET,SOURCE,FSTYPE
ls /var/lib/nifi

/opt/nifi/nifi-2.9.0 TARGET SOURCE FSTYPE /var/lib/nifi /dev/nvme1n1 ext4 content_repository database_repository flow flowfile_repository provenance_repository state

The content_repository holds the bytes of the data NiFi is processing. The flowfile_repository tracks the metadata of every flow file, the provenance_repository records the lineage of every event, and flow holds your saved dataflow definition.

Keeping all of these on the data volume means you can grow the disk independently, and your flow and its data survive a root volume replacement.

NiFi runs under systemd as nifi.service and the reverse proxy as nginx.service:

sudo systemctl status nifi --no-pager sudo systemctl restart nifi
sudo journalctl -u nifi -n 50 --no-pager

After a start, NiFi takes up to a minute to fully initialise while it loads its flow and warms the JVM. Allow that time before the console responds.

To change the single-user login password, use the bundled nifi.sh helper as the nifi service user, then restart NiFi:

sudo systemctl stop nifi
sudo -u nifi JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64 \
  /opt/nifi/nifi-2.9.0/bin/nifi.sh set-single-user-credentials admin '<new-password>'
sudo systemctl start nifi

The password must be at least 12 characters. Update your stored copy of the credentials after you rotate it, because the file under /root still holds the value generated on first boot.

The nginx reverse proxy ships configured for HTTPS on port 443 using a self-signed certificate at /etc/nginx/ssl/nifi-selfsigned.crt. To remove the browser warning, replace it with a certificate issued for your DNS name by a trusted certificate authority such as Let's Encrypt or your own internal CA.

Copy your certificate and private key onto the instance. Point nginx at them by editing the ssl_certificate and ssl_certificate_key lines in /etc/nginx/sites-available/nifi. Reload nginx with sudo nginx -t && sudo systemctl reload nginx.

Then add your DNS name to NiFi's proxy host allow list. Edit nifi.web.proxy.host in /opt/nifi/nifi-2.9.0/conf/nifi.properties and restart NiFi.

Your dataflow definition and the in-flight data all live under /var/lib/nifi. The simplest backup is an EBS snapshot of the data volume taken while NiFi is briefly stopped. This captures a consistent copy of the repositories and the flow:

sudo systemctl stop nifi aws ec2 create-snapshot --volume-id <data-volume-id> --description "nifi data $(date +%F)"
sudo systemctl start nifi

To export only the flow definition, copy /var/lib/nifi/flow/flow.json.gz to a safe location.

Keep the operating system patched with sudo apt-get update && sudo apt-get -y upgrade. Review the NiFi release notes before you upgrade the NiFi binary itself.

• Keep ports 443 and 80 closed to the public internet. Expose the console only to the networks that operate it, or front it with a load balancer or VPN and the certificate from Step 11.
• Rotate the login password after first launch and store it in a secrets manager.
• NiFi enforces authentication on every request, including the REST API. Never disable the single-user login provider or enable anonymous authentication on an internet-reachable instance.
• Take regular EBS snapshots of the data volume so your flows and their provenance survive an instance failure.
• Apply operating system security updates promptly.