Self-Hosted n8n Security: How to Lock Down Your Automation Server

Your n8n instance is connected to everything: your email, your CRM, your database, your payment system, your WhatsApp business account. If someone gains unauthorized access to your n8n dashboard, they can read all that data, modify workflows to exfiltrate information, or use your API credentials to make API calls on your behalf.

This isn't a theoretical concern. n8n instances exposed to the internet without proper authentication are actively scanned and attacked. This guide covers exactly what you need to do to keep your automation server secure.

Step 1: Never Run n8n Without Authentication

Out of the box, n8n has no authentication if you don't configure it. If you started your instance and didn't set up a username and password, stop and do this first.

n8n supports two authentication modes:

• Basic Auth: Username and password for the web interface. Simple, works fine for small teams.
• User Management: n8n's built-in multi-user system with individual accounts, roles (owner, admin, member), and granular workflow sharing. This is the recommended approach for any team setup.

To enable user management, set these environment variables in your n8n configuration:

N8N_USER_MANAGEMENT_DISABLED=false
N8N_EMAIL_MODE=smtp
N8N_SMTP_HOST=smtp.gmail.com
N8N_SMTP_PORT=465
N8N_SMTP_SSL=true
N8N_SMTP_USER=your@email.com
N8N_SMTP_PASS=your-app-password
N8N_SMTP_SENDER=your@email.com

Once user management is enabled, the first time you visit your n8n URL you'll be prompted to create the owner account. Do this immediately before sharing the URL with anyone.

Step 2: Run n8n Behind HTTPS

Running n8n over plain HTTP means usernames, passwords, and workflow data are transmitted in cleartext. Anyone on the same network — including your hosting provider's network — can intercept this.

The correct setup is to put n8n behind a reverse proxy (Nginx or Caddy) with an SSL certificate. If you're hosting at SNBD HOST on a BDIX VPS, here's the Nginx configuration:

server {
    listen 443 ssl;
    server_name n8n.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/n8n.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

server {
    listen 80;
    server_name n8n.yourdomain.com;
    return 301 https://$host$request_uri;
}

Get a free SSL certificate from Let's Encrypt using Certbot: certbot --nginx -d n8n.yourdomain.com. The certificate renews automatically every 90 days.

Step 3: Firewall Configuration

Your n8n server should not be broadly accessible. Use UFW (Uncomplicated Firewall) to restrict access:

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

This blocks all incoming traffic except SSH, HTTP (to redirect to HTTPS), and HTTPS. n8n's port 5678 should never be directly accessible from the internet — only through Nginx on port 443.

If you want to restrict n8n to specific IP addresses (for example, only your office network), add an allow rule before the nginx ports:

ufw allow from YOUR_OFFICE_IP to any port 443

Step 4: Secure Your API Credentials in n8n

n8n stores credentials (API keys, passwords, OAuth tokens) encrypted in its database. This is good. But there are still practices to follow:

• Use environment variables for sensitive credentials where possible: n8n supports referencing environment variables in credentials using the $env prefix. This keeps your most sensitive keys out of the n8n database entirely.
• Never share your n8n credentials export file: If you export credentials for backup, treat that file like a password database. Encrypt it.
• Rotate API keys regularly: Treat your n8n instance as a high-privilege system. Review and rotate the API keys it uses at least every 6 months.
• Use service accounts, not personal accounts: When connecting Google Sheets or Gmail, use a dedicated service account email, not your personal Gmail. If the service account is compromised, you can revoke it without losing access to your personal account.

Step 5: Protect Your Webhooks

n8n webhook URLs are publicly accessible by design — they need to be reachable by external services. But that also means anyone who discovers the URL can send data to your webhook. Protect them:

• Use non-guessable webhook paths: n8n generates random webhook IDs by default. Don't rename them to simple paths like /webhook/orders.
• Validate incoming data: Add an IF node at the start of every webhook workflow that checks for a shared secret in the request headers or body. Reject requests that don't include it.
• Validate webhook signatures: Services like Stripe, GitHub, and WhatsApp sign their webhook payloads with a secret. n8n has built-in support for verifying these signatures — always enable it.

Example validation node — check for a secret header:

// In an IF node condition:
{{ $json.headers['x-webhook-secret'] === $env.WEBHOOK_SECRET }}

Step 6: Set Up Proper Logging and Alerts

You need to know if something unusual is happening on your n8n instance. Configure:

• n8n execution logs: n8n keeps execution history. Set a reasonable retention period (30 days is usually fine) in Settings > Executions.
• Failed execution alerts: Configure an Error Workflow that sends a Telegram or email notification when any workflow fails. This catches both errors and potential attacks (attackers sending malformed payloads to your webhooks will cause workflow errors).
• Server-level monitoring: On your VPS, monitor authentication log (/var/log/auth.log) for failed SSH attempts. Tools like fail2ban automatically block IPs with repeated failures.

Step 7: Backups

Your n8n instance contains your workflows (which represent significant investment), your credentials, and your execution history. Back up regularly:

• Export workflows: In n8n Settings > Import/Export, you can export all workflows as a JSON file. Store this in a secure location (not on the same server).
• Database backup: n8n uses either SQLite or PostgreSQL. For SQLite, a simple cron job that copies the database file to cloud storage (Backblaze B2, AWS S3) is sufficient. For PostgreSQL, use pg_dump.
• Test your backups: A backup you've never restored is not a backup. Periodically test restoring your workflow export to a fresh n8n instance.

Managed Hosting vs Self-Managing Security

Implementing all of the above correctly takes time and security knowledge. If you're not confident in server administration, a managed hosting approach removes most of these concerns.

SNBD HOST's managed n8n hosting includes HTTPS configured by default, firewall rules set up on initial deployment, server-level monitoring, and regular backups. You still need to handle application-level security (credential hygiene, webhook validation) but the infrastructure layer is handled for you.

For businesses that want full control, our BDIX VPS plans give you a clean Linux server where you can implement all of the above yourself, with the advantage of BDIX connectivity for fast access from within Bangladesh.

Quick Security Checklist

• n8n authentication enabled (user management or basic auth)
• HTTPS configured with valid SSL certificate
• Firewall blocking port 5678 from public internet
• API credentials using service accounts, not personal accounts
• Webhook validation in place for all public webhooks
• Error workflow configured for failure alerts
• Automated daily database backups to off-server storage
• SSH key authentication only (password authentication disabled)

Running through this checklist once when you set up your n8n instance prevents the vast majority of security incidents. Automation servers are high-value targets — treat them accordingly.