Running NiFi with HTTP and No Authentication — Local Development & PoC Guide

Since Apache NiFi 1.14, the default installation comes up with HTTPS + Single User authentication, which means first-time developers have to go through three steps before even reaching the UI: self-signed certificate warning → find the auto-generated username/password → login. With authentication getting in the way before you can even start designing data flows, for local development, PoC, and internal sandboxes, it's much faster to strip it away. This post covers the shortest path to running NiFi in HTTP + anonymous mode by editing nifi.properties.

Warning: This configuration is for local development and isolated sandboxes only. HTTP + anonymous NiFi means anyone who can access the UI can modify flows, expose secrets, and execute processors. Never deploy this way on office networks, cloud VMs, multi-tenant environments, or production servers. For production, follow the official TLS + user authentication guide.

1. When You Need This Configuration

2. Prerequisites

• Apache NiFi 1.x (1.14 ~ 1.28). NiFi 2.x has some property name changes, covered separately below.
• JDK 11 or 17 (depending on NiFi version)
• Port 8080 is available
• NiFi installed from binary distribution or using the official Docker image

3. Editing nifi.properties

Open conf/nifi.properties in your NiFi installation directory. There are two blocks to modify.

3.1 Web server port settings

The defaults have HTTPS enabled and HTTP empty. Flip them:

# Before (defaults)
nifi.web.http.host=
nifi.web.http.port=
nifi.web.https.host=127.0.0.1
nifi.web.https.port=8443
 
# After
nifi.web.http.host=0.0.0.0
nifi.web.http.port=8080
nifi.web.https.host=
nifi.web.https.port=

Key points:

• nifi.web.http.host=0.0.0.0 means "listen on all network interfaces." If you're only accessing from the local PC, 127.0.0.1 is safer. Use 0.0.0.0 when you need to access from the host to a VM.
• nifi.web.https.host and nifi.web.https.port must be emptied. If both still have values, NiFi will start in HTTPS mode.

3.2 Remove security/authentication settings

In HTTP mode, keystore, truststore, and user authentication settings are all unnecessary. Clear all of these to empty values:

# After — all empty
nifi.security.keystore=
nifi.security.keystoreType=
nifi.security.keystorePasswd=
nifi.security.keyPasswd=
nifi.security.truststore=
nifi.security.truststoreType=
nifi.security.truststorePasswd=
 
# Disable user authentication
nifi.security.user.login.identity.provider=
nifi.security.user.authorizer=
 
# Disable cluster security options
nifi.cluster.protocol.is.secure=false
 
# Disable TLS for Site-to-Site (the path for other NiFi instances to push data in remotely).
# Must be false in HTTP mode for startup to succeed.
nifi.remote.input.secure=false

nifi.security.user.login.identity.provider and nifi.security.user.authorizer must both be empty. If the default values single-user-provider / single-user-authorizer remain, even in HTTP mode, the login screen appears first and blocks with an error saying "this provider is HTTPS-only."

Also, nifi.remote.input.secure is an easy-to-miss key. Its default is true, and even if you switch the entire web UI to HTTP, if this key remains true, the Site-to-Site connection path still requires TLS, and logs show "Remote input requires TLS ..." warnings while S2S functionality fails to start. When running everything in plaintext as in this guide, make sure to set it to false.

3.3 Only when behind a reverse proxy

If you're running NiFi behind a reverse proxy like nginx, add this one line. Skip if accessing directly.

nifi.web.proxy.host=myhost.internal:8080

If this value doesn't match the Host: header of the actual request, NiFi will reject it with System Error — the request contained an invalid host header.

4. Running

4.1 Binary installation

cd /opt/nifi-1.28.0
./bin/nifi.sh start
 
# Check startup status
./bin/nifi.sh status
 
# Wait for "JettyServer ... Started Server" in logs
tail -f logs/nifi-app.log | grep -E "Started Server|ERROR"

Startup takes about 30 seconds to 1 minute. When you see this message, it's ready:

INFO  org.apache.nifi.web.server.JettyServer ... Started Server @45123ms

Open http://localhost:8080/nifi in your browser — the canvas appears directly without a login screen.

4.2 Faster with Docker

If you want to skip downloading the binary and editing configuration, using environment variables with the official image is more convenient:

docker run --rm -d --name nifi \
  -p 8080:8080 \
  -e NIFI_WEB_HTTP_PORT=8080 \
  -e NIFI_WEB_HTTP_HOST=0.0.0.0 \
  apache/nifi:1.28.0

The image's entrypoint script automatically disables HTTPS and rewrites nifi.properties for HTTP mode when NIFI_WEB_HTTP_PORT is specified. Check startup logs like this:

docker logs -f nifi | grep -E "Started Server|ERROR"

http://localhost:8080/nifi → no login → straight to canvas.

5. Common Troubleshooting

System Error — the request contained an invalid host header

Cause: NiFi compares the Host: header value against a whitelist. If the host sent by the browser isn't in the default whitelist (localhost, bind IP), it's rejected.

• Verify you're accessing via http://localhost:8080. To access via http://<VM_IP>:8080, add nifi.web.proxy.host=<VM_IP>:8080.
• For access from multiple hosts, separate with commas: nifi.web.proxy.host=localhost:8080,10.0.0.5:8080,dev.example.com:8080

HTTPS is required for this login identity provider

Cause: You didn't empty nifi.security.user.login.identity.provider / nifi.security.user.authorizer in step 3.2. The remaining single-user-provider forces HTTPS.

• Verify both properties are truly set to empty values
• Restart NiFi after saving (./bin/nifi.sh restart)

Address already in use (port 8080)

Cause: Another process is occupying port 8080.

• Check with lsof -iTCP:8080 -sTCP:LISTEN and terminate the process
• Or change nifi.web.http.port to 8081 or another port

Can access but login screen appears

• Verify that nifi.web.https.host and nifi.web.https.port are truly empty (no spaces or tabs after =)
• Confirm you restarted after editing nifi.properties. NiFi does not re-read the file at runtime.
• If you previously started NiFi in HTTPS mode, the generated conf/flow.xml.gz, conf/users.xml, conf/authorizations.xml may remain. Delete them and restart (only in dev environments, as this erases data)

6. Notes for NiFi 2.x Users

Starting with NiFi 2.x, the following differences exist:

• The nifi.web.http.host / nifi.web.http.port properties themselves remain the same, but the project's official recommendation has shifted even more strongly toward "use HTTPS + single-user for development too, not just production."
• Some components may reject the "no security context" state. In particular, AWS/GCP connector components may require JKS for signing logic.
• Leaving single-user-provider while running in HTTP mode produces a clearer error message than in 1.x.

Bottom line: Where possible, run NiFi 2.x with single-user HTTPS. The auto-generated credentials are printed to logs/nifi-app.log only once at first startup, so capture them right after the initial boot.

7. Reverting — Returning to HTTPS

To ensure this configuration is never accidentally deployed to production, document the revert procedure:

1. ./bin/nifi.sh stop
2. Restore conf/nifi.properties from the backup file (cp conf/nifi.properties.bak conf/nifi.properties)
3. Delete conf/flow.xml.gz, conf/users.xml, conf/authorizations.xml (HTTPS mode will auto-generate new ones)
4. Specify login credentials explicitly (see section 8), or skip and check logs/nifi-app.log after ./bin/nifi.sh start for auto-generated username/password
5. Access https://localhost:8443/nifi

Tip: Before performing step 3.1, be sure to run cp conf/nifi.properties conf/nifi.properties.bak. It's the fastest way back to defaults.

8. Pre-Setting the Single User Password

While this post's main content assumes "HTTP + anonymous," sandboxes shared even slightly more broadly (team VMs, PoC clusters, etc.) are safer with HTTPS + single user login as a middle ground. The problem is that single-user mode auto-generates a random username/password at first startup and only prints it to the log. Miss the log and it's hard to find again; if multiple people need access, it's even more frustrating.

NiFi 1.14+ provides a CLI command to explicitly set the single user credentials for this scenario.

8.1 Prerequisite: Stop NiFi first

./bin/nifi.sh stop

set-single-user-credentials won't take effect while NiFi is running. Always run it stopped.

8.2 Set username / password

Command syntax:

./bin/nifi.sh set-single-user-credentials <USERNAME> <PASSWORD>

Example:

./bin/nifi.sh set-single-user-credentials admin 'VeryLongDevPassword!2026'

Requirements:

• Username must be at least 4 characters
• Password must be at least 12 characters

The command immediately errors out if length requirements aren't met. This is a minimum requirement enforced by NiFi, so short values like dev / admin1234 won't be accepted.

8.3 What this command does

Internally, it finds the single-user-provider section in conf/login-identity-providers.xml and updates two fields:

• Username → stored as the specified username
• Password → the provided plaintext is hashed with bcrypt and stored. The plaintext is never written to disk

So even if you later inspect login-identity-providers.xml, the original password cannot be reverse-engineered — only the hash is stored.

8.4 Keeping the password out of shell history

Typing the password directly after the command as shown above permanently records it in ~/.bash_history. This is a pattern to avoid on operator PCs or shared VMs.

# Method 1: Via environment variable (recommended)
read -s -p "NiFi single-user password: " DEV_NIFI_PW
echo
./bin/nifi.sh set-single-user-credentials admin "$DEV_NIFI_PW"
unset DEV_NIFI_PW
 
# Method 2: Leading space excludes from history in HISTCONTROL=ignorespace environments
 ./bin/nifi.sh set-single-user-credentials admin 'VeryLongDevPassword!2026'

Method 1 is more portable. read -s disables echo during password input, and the variable is removed with unset immediately after use.

8.5 Start and verify

./bin/nifi.sh start
tail -f logs/nifi-app.log | grep -E "Started Server|ERROR"

Access https://localhost:8443/nifi and the login screen appears. Log in with the username/password you just set. Once you see Authentication successful for user admin in logs/nifi-user.log after successful login, you're done.

Note: set-single-user-credentials is HTTPS-only. Running this command while in HTTP configuration from section 3 will work, but at startup NiFi will fail with "single-user provider requires HTTPS." To use section 8, first restore HTTPS settings via the section 7 revert procedure, then run it.

9. Operational Checklist

Defensive measures to prevent this configuration from leaking into production:

• Never commit nifi.properties with HTTP settings to Git. Keep only samples and inject actual values via .env / Ansible vault / Terraform variables
• Development Docker compose image tags should be like apache/nifi:X.Y.Z-dev — always distinct from production tags
• Add a lint step in the production deployment pipeline to verify nifi.web.http.port is empty
• Verify firewall rules to ensure the development NiFi address doesn't leak externally from internal DNS
• Periodically compare conf/nifi.properties using md5sum to audit that no one secretly switched to HTTP

This post covered only the fastest path to get NiFi started. Once actual data pipelines start running, you'll soon need authentication, TLS, and processor permissions — at that point, we plan to share our experience helping clients with TLS/LDAP configuration in another post.

— Data Dynamics Engineering Team