Cloud Computing: Self-Hosting n8n? You Might’ve Just Exposed Your Entire Workflow Stack to the Internet (Without Knowing It)

Self-Hosting: Power, Privacy… and Panic

Did you know, n8n is brilliant? It’s powerful, hackable, and self-hostable — a dream for developers who’ve been burned by Zapier’s pricing tiers or Airtable’s trigger limits. But here’s what almost nobody tells you in the tutorials:

When you self-host n8n, it’s your responsibility to lock it down. And if you don’t… You might be exposing far more than you realize.

The Default Install: Exposed By Design

Here’s what happens when most devs spin up n8n for the first time:

docker run -it --rm \
  -p 5678:5678 \
  n8nio/n8n

You’ve got workflows. A visual editor, all good, except:

There’s no password on the editor by default.
It’s running on a public port (5678).
If your Docker host has an open IP (like a VPS or cloud VM), the whole thing is world-accessible…

And guess what attackers are scanning for 24/7? Open ports. Default dashboards. Unauthenticated tools.

What Can an Attacker Do With an open n8n Instance?

With access to your n8n dashboard, a malicious actor can:

View and edit your credentials…
Trigger webhooks manually (with any payload)
Create new workflows to exfiltrate your data…
Drop in a Node.js “Execute Command” node and run shell commands on your host.
Delete all workflows…
Spin up infinite cron jobs that make you hit your API rate limits.

How to Check If You’re Exposed

Find your public IP or domain.

curl ifconfig.me

2. Try accessing http://YOUR-IP:5678/ in an incognito window

If the editor opens without a login, you’re exposed.

3. Try this too: http://YOUR-IP:5678/rest/credentials

If you see JSON, that’s credential data.

How to Lock Down Your n8n Instance (Before Someone Else Uses It)

1. Set up Basic Auth immediately

Use environment variables to enable login:

-e N8N_BASIC_AUTH_ACTIVE=true \
-e N8N_BASIC_AUTH_USER=yourusername \
-e N8N_BASIC_AUTH_PASSWORD=yourstrongpassword \

This stops random people from accessing your instance.

2. Never Expose Port 5678 Publicly

If you’re not reverse proxying, at least use a firewall or Docker’s — network flag to limit access.

On cloud: use security groups/firewall rules
On Docker: run n8n behind a Traefik, Nginx, or Caddy reverse proxy.
Use internal networks or VPNsss (e.g., Tailscale).

3. Force HTTPS or Use a Tunnel

Running n8n behind HTTPS is non-negotiable in prod.

Options:

Use Caddy or Nginx with Let’s Encrypt.
Use Cloudflare tunnel to expose securely via Cloudflare.
Or run behind a secure proxy like Traefik + Authelia.

4. Rotate or Encrypt Credentials

If you’ve ever had n8n exposed, assume your stored credentials are compromised.

Delete them.
Rotate all API keys.

Consider setting up external secret storage for sensitive credentials (via env variables).

But it was just for testing

Even if it’s just for dev — if it’s publicly accessible, you’re at risk.

Attackers don’t care that it’s a sandbox.

They’ll use your workflows to probe internal services.
Or use your VPS to mine crypto.
Or log credentials from your Slack, Notion, or Stripe integrations.

It’s Not Just About You

If you’re self-hosting automation that triggers real APIs, you’re holding the keys to third-party platforms.

Your insecure n8n setup could:

Spam clients
Trigger invoices
Update CRMs
Or worse: delete production data.

And the worst part? It won’t show up in your logs unless you built error handling into every workflow.

The Final Checklist (Don’t Skip These)

Use Basic Auth or SSO.
Run behind a reverse proxy with HTTPS.
Never expose 5678 directly to the public web.
Use firewall rules to whitelist your IPs.
Don’t use default credentials — even in dev.
Assume a compromise if your instance was ever open.

Self-Hosting Is Powerful — But With Power Comes Config Hell

Running n8n yourself gives you freedom. But freedom comes with risk — and responsibility. You wouldn’t run a raw Postgres DB on the public internet. Don’t do it with your automation brain, stay protected.