7 n8n Self-Hosting Mistakes I Made (So You Don't Have To)

February 2, 2025 · 10 min read

I've been running n8n on an AWS EC2 instance for weeks now. It powers my entire automation stack — site monitoring, content pipelines, AI workflows, alerting systems. Along the way, I made every mistake in the book. Here are the ones that actually cost me time.

1. Not Backing Up the SQLite Database

n8n uses SQLite by default. Your workflows, credentials, execution history — it's all in one file. I assumed Docker volumes were persistent across container rebuilds. They're not always.

One bad docker-compose down -v and I lost a week of workflow configs. The -v flag removes volumes. I'd been using it out of habit from other projects.

✅ Fix

Set up a cron job that copies the SQLite file to a backup location daily:

0 3 * * * cp ~/.n8n/database.sqlite ~/.n8n/backups/database-$(date +%Y%m%d).sqlite

2. Exposing n8n Directly to the Internet

My first setup: n8n on port 5678, open to the world. No reverse proxy, no auth beyond the basic login. This worked for about a week before I saw suspicious requests in the logs.

Then CVE-2026-21858 dropped — unauthenticated remote code execution in n8n. Anyone could take over my instance without logging in. That was a wake-up call.

✅ Fix

Put n8n behind Tailscale or Cloudflare Tunnel. Your instance should never have a public IP. If you need webhooks from external services, use Cloudflare Tunnel with specific paths whitelisted.

3. Using JSON Body Type with Expressions

This one burned hours. The HTTP Request node has a "Specify Body" option. If you set it to JSON and use n8n expressions like {{ $json.name }}, it fails silently.

Why? n8n validates the JSON before evaluating expressions. So it sees {{ $json.name }} as invalid JSON and rejects it.

✅ Fix

Set Specify Body to "String" instead of "JSON". Then write your JSON as a string with expressions. n8n evaluates expressions first, then parses the result as JSON.

4. Not Setting Execution Timeouts

I had a workflow that called an external API. The API went down. My workflow hung forever, holding the execution slot. Since n8n has limited concurrent executions by default, this blocked other workflows from running.

✅ Fix

Set timeouts at two levels:

HTTP Request node: Set timeout in Options (e.g., 10000ms)
Workflow level: Set EXECUTIONS_TIMEOUT env var (e.g., 300 for 5 minutes)

5. Ignoring Memory Limits

n8n loads entire datasets into memory. If a workflow processes a large API response (thousands of records), it can crash the whole instance. I learned this when a Stripe webhook handler tried to process a full customer export.

✅ Fix

Set NODE_OPTIONS=--max-old-space-size=512 in your Docker config. Process data in batches using the Loop Over Items node. And always paginate API calls instead of fetching everything at once.

6. Not Monitoring n8n Itself

I had 8 workflows running but no way to know if n8n itself went down. The automation tool that was supposed to make things reliable was a single point of failure.

✅ Fix

Use an external monitor. I built a simple check that pings n8n's health endpoint every 15 minutes from outside the n8n instance. If it fails, it alerts me through a completely separate channel. Don't use n8n to monitor n8n.

7. Building Workflows Before Mapping the Process

This is the meta-mistake that caused half the others. I'd get excited about n8n's capabilities and start building immediately. Two workflows later, I realized I was automating processes that didn't need to exist.

Now I follow a simple rule: sketch the process on paper first. Identify where the actual friction is. Often the answer isn't "automate this" — it's "stop doing this entirely."

✅ Fix

Before opening n8n, answer three questions: (1) What problem am I solving? (2) Who has this problem? (3) What happens if I don't automate it? If you can't answer all three, don't build yet.

The Bigger Lesson

Self-hosting n8n isn't just "install and forget." It's infrastructure. You're the ops team now. That's powerful — you control everything — but it means security patches, backups, monitoring, and capacity planning are your responsibility.

The good news: once you have these basics in place, self-hosted n8n is incredibly reliable. I run 10+ active workflows and the total cost is about $5/month for the EC2 instance. Try getting that from any cloud automation platform.

Production-Ready Workflow Templates

All our templates are tested on self-hosted n8n 2.4.6. They include error handling, timeouts, and documentation — the stuff you only learn matters after something breaks.

Browse Templates →