Is self-hosted n8n secure?

It can be, if you use HTTPS, a firewall, strong access control, a protected encryption key, regular updates and backups.

Should I expose port 5678 to the internet?

No. Bind n8n to localhost and put a reverse proxy with HTTPS in front of it.

What happens if my encryption key leaks?

Someone with both the key and your database could decrypt stored credentials. Rotate the credentials in your connected services and restrict access to the key.

n8n Security Checklist: Harden Your Self-Hosted Server

n8n Security Checklist for Self-Hosted Servers

26 October 2026
by Admin

Copied successfully! The link has been copied to clipboard

n8n Security Checklist for Self-Hosted Servers

A self-hosted n8n holds API keys, database passwords and access tokens. If someone gets into it, they get into everything it connects to. Go through this checklist once when you set up, and again every few months.

Server and network

Use SSH keys and turn off password login for SSH.
Enable a firewall. Allow only SSH, 80 and 443. Keep the n8n port (5678) and the database port closed to the internet.
Bind n8n to 127.0.0.1 and let a reverse proxy handle public traffic.
Install fail2ban or similar to slow down repeated login attempts.
Keep the OS updated with security patches.

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

HTTPS everywhere

Serve n8n only over HTTPS with a valid certificate from Caddy or Nginx and Let's Encrypt. Never log in to n8n over plain HTTP on the internet.

n8n settings and credentials

Set N8N_ENCRYPTION_KEY yourself, store a copy safely and never change it.
Create a strong owner account. Enable two-factor authentication if your n8n version offers it.
Give each person their own user instead of sharing one login.
Use least privilege. Create API keys with the minimum permissions each workflow needs.
Do not store secrets in workflow nodes as plain text. Use the credentials system.
Prune execution data. Old executions can hold sensitive data. See the environment variables guide.

Webhooks

Use long, hard-to-guess webhook paths.
Check a secret or signature on incoming requests when the sending service supports it.
Validate the data you receive before you act on it.
Remember webhook paths must be public, so do not put a login page in front of them. See webhook troubleshooting.

Docker

Do not expose the Docker socket to containers.
Pin image versions and update on purpose.
Do not publish the Postgres port to the internet.
Keep .env readable only by your user.

Updates and backups

Updates fix known vulnerabilities, so follow the routine in how to update n8n without losing data. Back up daily and store copies off the server, as in our backup guide.

Acceptable use

Run only automations that follow the law and your provider's rules. PCRDP's acceptable usage policy explains what is allowed on our servers.

With managed n8n hosting, we handle server and Docker patching and take daily backups, so most of the server-side items above are done for you.

Server hardening, patching and backups are part of our managed n8n plans.

See Managed n8n Plans

Frequently asked questions

Is self-hosted n8n secure?
It can be, if you use HTTPS, a firewall, strong access control, a protected encryption key, regular updates and backups.
Should I expose port 5678 to the internet?
No. Bind n8n to localhost and put a reverse proxy with HTTPS in front of it.
What happens if my encryption key leaks?
Someone with both the key and your database could decrypt stored credentials. Rotate the credentials in your connected services and restrict access to the key.

n8n Security Checklist for Self-Hosted Servers