HadesFlow at the 2nd n8n Community Meeting in Bulgaria: What Nobody Tells You About Self-hosting

Anyone can build an AI automation. You wire up a few nodes, drop in a Claude call, watch the demo fire, and it feels finished. But “works on my machine” is the easy half. The harder job - the one most content quietly skips - is taking that automation from a working demo to something secured, deployed, and reliable enough to leave running unattended. That gap is exactly where our work lives, and it’s what we came to talk about.

Last week we spoke at the 2nd n8n Community Meeting in Bulgaria, with a talk titled “Self-hosting n8n: what nobody tells you.” A lot of hands went up afterwards asking for specifics, so this is the fuller version of that talk - written down, in one place. Everything here is for the free, self-hosted Community edition, and it’s aligned with n8n’s own official guidance. None of it is exotic. It’s the unglamorous baseline that separates a hobby instance from one you’d trust with a client’s data.

Where this actually comes from

The question we got most after the talk wasn’t about a specific setting. It was: “Where did you actually learn all this?” The honest answer surprises people - there was no paid course and no guru. Almost everything came straight from n8n’s own material:

• n8n Docs - start here, and read them end to end. docs.n8n.io even has a built-in AI assistant you can chat with for quick answers.
• The n8n Community Forum - real problems and real fixes from people running n8n in anger: community.n8n.io.
• n8n’s YouTube channel - walkthroughs and deep dives that fill in what reading alone won’t.
• Live events & webinars - the meetups (like the one we spoke at) and official sessions.
• n8n’s official LinkedIn - where new features and security guidance get announced first.

The takeaway for anyone starting out: you don’t need to buy your way to competence here. The official sources are thorough, current, and free. Read the docs first, lean on the forum when you’re stuck, and you’ll be ahead of most.

The essentials: four things to get right

Security on a self-hosted instance isn’t one big decision - it’s a handful of small ones that are easy to skip when you’re focused on building. These four are the baseline. Get them right and you’ve closed the doors that actually get kicked in.

1. Lock the front door

The single most common mistake is exposing the n8n editor to the internet without a login. Don’t. Put authentication in front of it and turn on 2FA - it’s built into the Community edition, so there’s no excuse. The mental model that keeps this straight: webhooks are meant to be public; your editor is not. Webhook URLs are how the outside world triggers your workflows, so they live on the open internet by design. The editor, where every workflow and credential is visible and editable, should never be reachable without authenticating first.

2. Encrypt everything

Two layers, in transit and at rest. In transit, terminate HTTPS with a reverse proxy - nginx or Caddy in front of n8n handles the TLS certificates (Caddy will even fetch and renew them automatically). There is no good reason to move workflow data or credentials over plain HTTP. At rest, encrypt the disk the instance and its database live on, so a snapshot or a stolen volume doesn’t hand someone everything in plaintext.

3. Mind your secrets

Never hardcode API keys and passwords into workflows. Use n8n’s built-in encrypted credentials - they exist precisely so secrets aren’t sitting in plaintext inside a node. The one file to guard above all others is the encryption key: it unlocks every saved credential in your instance, so treat it like the master key it is. Back it up somewhere safe, keep it out of your repo, and know that you can rotate it if you ever suspect it’s been exposed.

4. Stay current and back up

Old versions carry known CVEs - running months behind is running with publicly documented holes. Keep n8n updated, but pin your image versions so an update is a deliberate, tested step rather than a surprise. Run the container as a non-root user to limit the blast radius if something does go wrong. And back up the two things you genuinely cannot recreate: your database and your encryption key. A backup of the database without the key is just encrypted noise.

A few n8n-specific switches worth flipping

Beyond the general hygiene, n8n ships with environment variables that meaningfully harden an instance. These are the ones worth knowing:

• N8N_BLOCK_ENV_ACCESS_IN_NODE=true - stops workflows from reading your server’s environment variables. Without it, a Code node can quietly read whatever secrets live in the host environment.
• N8N_SSRF_PROTECTION_ENABLED=true - blocks requests to internal and cloud-metadata endpoints. This is what stops a crafted request from reaching, say, your cloud provider’s metadata service to lift credentials.
• NODES_EXCLUDE - disable risky nodes you don’t actually use, like Execute Command and SSH. If a node can run arbitrary commands and you never need it, removing it removes the risk entirely. And keep the Code node isolated by running it with task runners, so workflow code executes in a sandbox rather than in the main process.

The good news: n8n v2.0+ makes several of these the default. If you’re on a recent version, much of this is already handled for you - but it’s worth confirming rather than assuming. On older versions, you’ll need to flip them on yourself. n8n’s security and hardening documentation spells out the current defaults and every switch in detail.

The 30-second win: run n8n audit

If you do one thing after reading this, do this. n8n ships with a built-in audit command - run n8n audit against your instance and it flags the problems for you: unprotected webhooks, risky nodes, unused credentials still sitting around, and missing security settings. It’s the fastest possible read on where you stand, it costs you about half a minute, and it turns the abstract checklist above into a concrete list of things to fix on your instance specifically. There’s no faster return on security effort available to a self-hoster.

The talk, if you want the slides

Huge thanks to the organizers of the 2nd n8n Community Meeting in Bulgaria, and to everyone who came to the talk and pushed for the specifics afterwards - those questions are what turned a 20-minute slot into the write-up above. Here’s a shot from the talk itself:

You can flip through the full deck right here - use the controls to move slide to slide - or download it to keep:

Download the deck (PDF)

Got a technical question on any of this? The n8n community forum is the right place for the n8n-specific ones - and for the rest, our inbox is open.

The part that doesn’t fit on a slide

Step back from the individual switches and there’s a single idea underneath all of them. Building the automation and owning the infrastructure it runs on are not two jobs - they’re one discipline. The reverse proxy, the encryption key, the pinned versions, the audit you run before going live: none of it shows up in the demo, and all of it is what makes the difference between something that works and something you can rely on. That’s the same thread that runs through how we run n8n in production: the demo is the start of the work, not the end of it.

Most automation content stops at the demo. Our work starts where it ends - taking AI agents and automations from “works on my machine” to secured, deployed, and reliable in production. If that’s what you need done properly - the build and the infrastructure under it - let’s talk.