Self-Hosting n8n: What You Need (and What You Don't)

So you've decided to self-host n8n. Good call. Whether you're tired of per-execution pricing on the cloud version, or you just want full control over your workflows and data, running your own instance is one of the smarter moves you can make as an automation enthusiast. But before you spin up a server and start importing workflows, let's talk about what you actually need versus what the internet tells you that you need.

Spoiler: it's less than you think. n8n is surprisingly lightweight, but there are a few gotchas that can ruin your weekend if you skip them. This guide walks you through realistic resource requirements, persistence and backup strategies, and the small details that make the difference between a workflow engine that just works and one that quietly drops your data at 3 AM.

What You Actually Need to Run n8n

Let's start with the hardware. n8n itself is a Node.js application, and at idle it sips resources. For a personal or small-team setup running maybe 20-50 workflows with moderate complexity, you can comfortably get by with 1 GB of RAM and 1 vCPU. That's it. If you're running heavier workflows with lots of data transformation, parallel executions, or AI nodes that pull large payloads, bumping up to 2 GB RAM gives you breathing room.

Disk-wise, the n8n binary and its dependencies take around 500 MB. The real growth comes from your execution history, which is stored in the database. If you're running hundreds of workflows daily and keeping full execution logs, plan for 10-20 GB of disk space over time, or set up automatic pruning (more on that below). Most folks self-hosting on a small VPS will never touch that ceiling.

One thing people overestimate: CPU. Unless you're doing heavy data processing inside Function nodes, n8n is mostly waiting on external APIs. A modest VPS handles this beautifully. What you want is reliable uptime and a stable network, not a beefy machine.

Persistence and Backups: The Part Everyone Skips

Here's where self-hosters get burned. By default, if you run n8n in Docker without configuring volumes, your workflows, credentials, and execution history live inside the container. Restart the container the wrong way, and poof, gone. Always mount a persistent volume for /home/node/.n8n (or wherever your data path is), and back that directory up regularly.

For the database, n8n uses SQLite by default, which is fine for personal use but starts to feel sluggish once you cross a few thousand executions. If you're running a busy instance, switch to PostgreSQL. It handles concurrent executions better and makes backups cleaner. A nightly pg_dump piped to off-site storage is your friend.

Don't forget to back up your encryption key. n8n encrypts stored credentials with a key it generates on first run. Lose that key, and every saved API token, OAuth connection, and password becomes unreadable garbage. Store it somewhere safe, somewhere that is not the same server as your n8n instance.

The Gotchas Nobody Warns You About

First gotcha: webhook URLs. If you're behind a reverse proxy or NAT, n8n needs to know its public URL to generate working webhook endpoints. Set the WEBHOOK_URL environment variable to your actual public domain, including HTTPS. Otherwise your webhook nodes will spit out localhost URLs and you'll spend an hour wondering why nothing works.

Second: execution data bloat. n8n saves every execution's input and output by default. On a busy instance, this fills up your database fast. Set EXECUTIONS_DATA_PRUNE=true and configure a max age (e.g., 14 days) so old runs get cleaned up automatically. You'll thank yourself later.

Third: timezone issues. Cron and Schedule nodes use the server's timezone. If your server is on UTC and you set a workflow to run at 9 AM thinking that's local time, you'll be confused. Either set the GENERIC_TIMEZONE variable or be deliberate about UTC in your schedules.

Skip the Setup with TPC Hosting's One-Click Install

If everything above sounds like a fun weekend project, dive in. n8n's documentation is solid and the community is helpful. But if you'd rather skip the Docker compose files, reverse proxy configuration, SSL certificates, and environment variable juggling, that's exactly why we built our n8n hosting at TPC Hosting.

Our one-click install gives you a production-ready n8n instance with persistent storage, automatic backups, HTTPS configured out of the box, and the right environment variables already set. PostgreSQL is wired in for you, execution pruning is sensible by default, and your encryption key is safely stored. You log in, start building workflows, and skip the infrastructure detour entirely.

That said, we're fans of self-hosting in any form. If you'd rather run n8n on your own VPS, the guide above should keep you out of the common traps. And if you outgrow your DIY setup or just want someone else to handle the boring parts, TPC Hosting is here.

Frequently Asked Questions

FAQ