TL;DR: Self-hosting n8n gives you unlimited executions and full data sovereignty, but production-ready setup takes 15-25 hours (not a weekend afternoon) and true monthly costs are $220-400 when you factor in maintenance labor alongside the $30-100 server bill. DIY is the right choice if you have a developer who genuinely enjoys infrastructure work. If you want n8n's power without the DevOps burden, a managed partner handles the infrastructure while you use the workflows.

The case for self-hosting n8n is genuinely compelling. No per-task pricing. Unlimited executions. Full data sovereignty — your data never touches a third-party server unless you send it there. Over 70 AI and LangChain nodes baked in. A visual workflow editor that, once you're comfortable with it, is faster and more expressive than anything else in the automation market. You've probably read the docs. Watched a few community tutorials. Maybe you've already spun up a test instance on Docker with docker-compose up -d and seen n8n running on localhost:5678, and it looked good.

Then you started reading about what "production-ready" actually means. SSL termination. A reverse proxy in front of n8n — Nginx or Caddy — properly configured for WebSocket pass-through so the UI doesn't break. PostgreSQL instead of the default SQLite, because SQLite will corrupt under concurrent writes in any real-world load scenario. Daily encrypted backups shipped off-site. Queue mode for high-volume workflows, which requires Redis and a separate worker process. Uptime monitoring. Error alerting. Execution failure notifications that actually wake you up when something breaks at 3am. Version pinning so a surprise n8n update doesn't take down a production workflow. An incident response process for when a webhook stops receiving because a firewall rule changed. An encryption key backup, because if you lose it, your stored credentials are gone.

The appeal of self-hosted n8n is real. The infrastructure work is also real. This article is a straightforward accounting of what DIY n8n actually demands — time, skills, ongoing maintenance — and how that compares to having an agency run n8n for you. No attempt to convince you one way is inherently superior. They serve different people with different constraints.

Two Ways to Use n8n (And One More)

Before going further, it is worth being precise about the options, because they are often conflated.

n8n Cloud is n8n's own hosted product. You pay n8n directly — plans start at €20/month for Starter, scaling to €50+/month for Pro and enterprise contracts for larger volumes. You get a managed n8n instance without worrying about infrastructure. The trade-off: you are back to execution-based pricing (50,000 executions on the Starter plan), you do not control the server, and data flows through n8n's infrastructure. (For a comparison of n8n Cloud against Zapier and Make.com, see our n8n vs Zapier vs Make guide.)

n8n self-hosted DIY is what this article is primarily about. You run n8n on your own infrastructure — a VPS, a dedicated server, Kubernetes if you're at that scale. You own everything: setup, configuration, monitoring, updates, incident response. The power ceiling is high. The operational overhead is real.

n8n managed by a partner — EsperaStudio's model — is the third option. n8n runs self-hosted on infrastructure managed by us, with the same technical capabilities and data sovereignty as DIY, but without the DevOps work landing on you. We handle setup, monitoring, updates, backups, and incident response. You get the workflows built, maintained, and optimized without needing to know what a Caddyfile is.

This article is a comparison of options two and three. If n8n Cloud fits your budget and execution volume, it is a legitimate choice — we are not here to talk you out of it. But if the reason you're considering self-hosted n8n is cost, control, data sovereignty, or workflow complexity, then the real question is whether you run it yourself or have someone else run it for you.

What "Production-Ready" n8n Actually Requires (DIY)

This is the section that gets glossed over in most n8n tutorials. Running n8n in Docker on your laptop for testing is easy. Running it in a way that you can stake client workflows on — that needs to be up and working when you are not looking at it — is a different project.

Server Setup

You need a VPS with enough resources for n8n to run reliably under load. Minimum practical specs for a real production environment: 2 vCPUs, 4GB RAM. Hetzner's CX22 is €4.35/month — but for production with a database, monitoring stack, and buffer for traffic spikes, you're more realistically looking at a CX32 at €8.49/month or equivalent. On DigitalOcean, a 2 vCPU / 4GB Droplet runs $24/month. For queue mode with Redis and worker nodes, add another €10-20/month for the worker instance, or go to a larger single server.

n8n itself runs via Docker. You will need docker and docker-compose (or Docker Compose V2) installed, a working docker-compose.yml that defines the n8n container, the PostgreSQL container, the Redis container if you are using queue mode, volume mounts for persistence, and environment variable management via a .env file or secrets manager. This is not difficult if you have done it before. If you have not, the learning curve is non-trivial — not because it is arcane, but because the failure modes are subtle and debugging a misconfigured Docker network or a volume permission error takes time.

Reverse Proxy and SSL

You cannot run n8n on port 5678 with no SSL in production — webhooks from external services require HTTPS, and the n8n UI over unencrypted HTTP is a credential exposure risk. You need a reverse proxy: Nginx or Caddy. Caddy is simpler for this use case because it handles Let's Encrypt certificate issuance and renewal automatically. Nginx requires either Certbot configuration or manual certificate management.

Either way, you need to configure WebSocket proxying correctly for n8n's UI — n8n uses WebSockets for real-time workflow execution feedback, and a proxy that does not handle the upgrade header will leave you with a UI that silently fails in non-obvious ways.

Estimated setup time just for reverse proxy and SSL: 2-4 hours if you have done it once before, longer if you have not.

Database: PostgreSQL, Not SQLite

The default n8n Docker setup uses SQLite. This is documented as not suitable for production and it genuinely is not. Under concurrent workflow executions, SQLite will generate database lock errors. For any non-trivial workflow volume — more than a handful of concurrent executions — you need PostgreSQL.

Setting up PostgreSQL as a separate container in your Docker Compose file is not hard, but you then need to manage it: connection pooling, index maintenance over time, and most critically, backups. A PostgreSQL database with no backup strategy is an incident waiting to happen. At minimum, you need a daily pg_dump shipped to S3 or equivalent cold storage, with a tested restore procedure. Automated with a cron job, this is achievable — but it is another thing to set up, monitor, and periodically test.

Queue Mode for High Volume

By default, n8n processes workflow executions in the main process. For low volume — a few hundred executions per day — this is fine. For high volume or any workflows where you care about execution reliability under load, you want queue mode. Queue mode uses Redis as a message broker and separates the main n8n process (which handles the UI and webhook ingestion) from worker processes (which execute the actual workflows).

This means: a Redis container in your Docker Compose setup, EXECUTIONS_MODE=queue in your n8n environment, a separate docker-compose service for n8n workers with n8n worker as the command, and concurrency settings configured based on your workflow characteristics. The operational benefit is real — worker crashes do not take down webhook ingestion, and you can scale workers horizontally. The operational overhead is also real: you now have a Redis instance to monitor and two classes of n8n processes to keep track of.

Monitoring and Alerting

An n8n instance with no monitoring is not a production n8n instance — it is a server you will find out is broken when a client asks why their automation has not run in three days.

Minimum viable monitoring stack:

• ▸Uptime monitoring: UptimeRobot (free for 50 monitors) or Better Stack monitors your n8n instance URL and sends alerts if it goes down. Setup time: 15 minutes. Non-negotiable.
• ▸Execution failure alerts: n8n has a built-in error workflow feature — you can configure a workflow that runs when any other workflow fails, sending a Slack message, email, or PagerDuty alert. This requires building and maintaining that error workflow.
• ▸Server resource monitoring: CPU, memory, and disk usage. Without this, you will not know a disk is filling up until n8n crashes because the PostgreSQL volume ran out of space. Netdata (free, self-hosted) or Grafana + Prometheus covers this, but adds to setup time.
• ▸Database health: Monitoring PostgreSQL for connection errors, slow queries, and backup completion.

Updates and Version Management

n8n releases new versions frequently — often multiple minor versions per month. Each version potentially contains breaking changes for specific nodes, changed API response handling, or workflow behavior differences. You cannot just run docker pull n8naio/n8n:latest automatically in production; you will eventually pull a version that breaks one of your workflows.

A responsible update process looks like: review the n8n changelog for the new version, test the update on a staging instance (which means maintaining a second n8n environment), then apply to production. This is not optional hygiene — it is the difference between controlled updates and discovering a broken production workflow after the fact.

Estimated time per update cycle: 1-2 hours including testing and rollback preparation.

Security Baseline

Production n8n security requirements:

• ▸Firewall rules: ports 80 and 443 open, everything else closed. No direct exposure of PostgreSQL or Redis ports to the internet.
• ▸n8n instance encryption key: stored securely and backed up separately from the server. If you lose this key, all stored credentials in n8n are unrecoverable.
• ▸Environment variable management: no hardcoded secrets in docker-compose.yml files committed to version control. Use .env files excluded from git, or a secrets manager.
• ▸n8n user accounts: if multiple people access the instance, configure n8n's user management properly — not everyone with admin.
• ▸Regular audit of which n8n credentials and integrations are active versus orphaned.

Realistic Time Investment

If you are competent with Linux, Docker, and basic networking, here is an honest estimate:

• ▸Initial setup (VPS + Docker + PostgreSQL + reverse proxy + SSL + queue mode + monitoring): 15-25 hours for a properly configured production environment. Not 2 hours. Not a weekend afternoon.
• ▸Ongoing monthly maintenance: 2-4 hours/month for monitoring review, n8n version updates, database maintenance, backup verification, and debugging any issues that arise.
• ▸Incident response: Variable. A webhook reliability issue or an n8n crash at an inconvenient time is not a 15-minute fix.

These numbers assume competence with the stack. If you are learning Docker and Linux networking at the same time, double them.

The Real Monthly Ongoing Overhead

DIY advocates tend to calculate the cost of self-hosted n8n as the server bill. The actual cost is the server bill plus the time investment priced at your real hourly rate.

Infrastructure costs:

• ▸VPS: €20-60/month depending on specs and provider
• ▸Backup storage (S3 or equivalent): €2-5/month
• ▸Monitoring tooling (if beyond free tier): €10-20/month
• ▸Staging environment (if you maintain one): €10-20/month
• ▸Total infrastructure: €30-100/month

Labor costs:

• ▸3 hours/month ongoing maintenance × €75/hour (a conservative fully-loaded hourly rate for technical labor, not billing rate) = €225/month
• ▸Plus amortized setup cost: 20 hours initial setup / 24 months assumed lifespan = ~0.8 hours/month amortized = €60/month

True monthly cost of DIY self-hosted n8n: €315-385/month for a properly maintained production environment.

This calculation gets starker when the maintenance falls on a founder or a senior developer whose effective cost to the business is higher than €75/hour, or when an incident consumes a full day of debugging time.

The cost is not the server. The cost is maintaining infrastructure that is not your core business.

There is also a skill requirement worth being direct about. Running production n8n is not a one-skill task. You need: Linux server administration basics, Docker and Docker Compose, networking and DNS, PostgreSQL administration, enough JavaScript or Python to write custom code nodes when needed, and familiarity with n8n's architecture and failure modes. If all of those are already in your skill set and you find that work genuinely interesting, DIY is viable. If any of them are gaps, those gaps are where production incidents come from.

EsperaStudio's Approach — n8n, Managed

To be unambiguous about the technical foundation: EsperaStudio runs n8n self-hosted. The same software, the same architecture, the same capabilities. This is not a pitch for a different tool. It is an argument about who should run the infrastructure and who should build the workflows on top of it.

What "Managed" Means in Practice

When we set up n8n for a client engagement, we are delivering a production environment that covers the full checklist above:

• ▸VPS provisioned on Hetzner or equivalent, with specs matched to expected workflow volume
• ▸Docker Compose configuration with PostgreSQL, Redis for queue mode, and the n8n main + worker processes
• ▸Caddy reverse proxy with automatic SSL, properly configured for WebSocket pass-through
• ▸Automated daily PostgreSQL backups to off-site storage with tested restore procedures
• ▸Uptime monitoring with alert routing to on-call channel
• ▸n8n error workflow that catches execution failures and notifies relevant parties
• ▸Version update process: changelog review, staging test, controlled production deployment
• ▸Firewall rules, encryption key management, and credential security baseline

That infrastructure is part of the engagement — not a premium add-on. You are not charged separately for backup storage or monitoring configuration. It is the baseline because it has to be the baseline for production workflows to be reliable.

Workflows Built for Production

There is a second component beyond infrastructure: the quality of the workflows themselves. A workflow that works in testing and a workflow that is production-ready are different things.

Production n8n workflows need error handling on every external API call — because APIs return unexpected status codes, rate limits, and transient 500 errors. They need retry logic with appropriate backoff — because a webhook payload that fails on first delivery should not disappear silently. They need execution logging that is structured enough to debug problems after the fact, not just "workflow failed." They need alerting that routes to the right person when something breaks.

Every workflow we build includes this infrastructure by default. It adds development time. It is also the reason client workflows keep running when they should, and get fixed quickly when they do not.

AI-Native Workflow Design

n8n's LangChain nodes make it possible to embed LLMs as genuine decision-makers inside workflows — not just as text formatters. We use this to build workflows where an LLM evaluates content quality, routes records based on unstructured input, generates structured data from arbitrary documents, handles exception cases that rule-based logic cannot cleanly address, and acts as an orchestration layer for multi-step AI pipelines.

We work with Claude, GPT-4, and Gemini depending on task requirements, connecting them through n8n's AI nodes or direct API calls with custom code steps. The model selection is based on what the workflow actually needs — not what happens to have a pre-built connector.

When n8n Is Not the Right Tool

Sometimes it is not. An automation workflow connecting a webhook to a CRM is the right use case for n8n. A purpose-built application with its own data model, user interface, authentication, and custom business logic is not — regardless of how creatively you configure the nodes.

We also build full custom software when the problem requires it. An example: an AI-powered English language testing system built for a language school — full application, not a workflow. Test delivery, AI-based scoring, progress tracking, student and instructor interfaces. That is not a workflow. That is software. Having both capabilities — automation and software development — means a client's problem gets the right solution rather than being forced into the tool that happens to be available.

Honest Constraints

To be direct about what the managed model is not:

You do not control the infrastructure directly. The server is ours. You have full visibility into your workflows and execution logs, but you are not SSHing into the VPS. For some organizations — particularly those with strict internal IT governance requirements — this is a non-starter.

The ongoing cost is higher than raw server costs. A €30/month VPS is cheaper than an agency engagement. That comparison is only accurate if your time is worth nothing and you already know everything required to run the stack well.

It requires a collaborative relationship. Your workflows cannot be built in isolation from your processes. Effective automation requires clear communication about what the workflow is supposed to do, what the edge cases are, and what "success" looks like. That communication takes time and cannot be eliminated.

Head-to-Head Comparison

When to Self-Host n8n Yourself

DIY is genuinely the right answer for a specific set of situations. Here is an honest list.

You have a developer or DevOps engineer who finds this work interesting. Not just capable — genuinely interested. Infrastructure work done reluctantly by someone who has other priorities is infrastructure that gets neglected. If someone on your team would enjoy the Docker configuration and finds PostgreSQL tuning satisfying, the total cost drops dramatically because the labor cost is absorbed.

You are building automation-as-a-product. If n8n is the technical backbone of something you are selling to customers — a SaaS product, a reseller offering, an internal platform — you need full control of the infrastructure. Delegating that to an agency creates a dependency that does not belong in your product's critical path. Run it yourself.

Your volume is high enough that per-seat agency costs do not scale. At some point — high enough execution volume, large enough team, broad enough workflow footprint — the economics of a managed engagement stop working. What that inflection point is depends on specifics, but it exists.

Your team is technical and internal. If this is an internal tooling project for a technical team, GDPR sensitivity is low, the workflows are not client-facing, and you have the skills in-house, the case for managed infrastructure is weak. Run it yourself, monitor it reasonably, and spend the difference on something else.

When EsperaStudio Makes More Sense

Your time is worth more than the infrastructure cost delta. This is the most common situation. A founder or agency principal who would spend 20 hours setting up n8n and 3 hours a month maintaining it is paying a high price for something that is not their business. The calculation only works if you value your time at zero.

You need n8n's capabilities without DevOps work. You have read the n8n docs. You understand what it can do. You want those workflows — the AI-native pipelines, the unlimited executions, the data sovereignty — without the infrastructure ownership. That is what the managed model is for.

Your workflows are client-facing and require reliability you cannot guarantee yourself. A webhook that fails because your n8n instance went down during an unmonitored update affects your clients, not just your internal operations. SLA-level reliability requires production-grade infrastructure and active monitoring. That is hard to maintain part-time alongside other work.

You want AI embedded intelligently, not assembled from tutorials. Building effective LLM-driven workflows — ones where the AI is doing real reasoning work, not just text reformatting — requires both n8n expertise and AI engineering experience. If you want the full capability of n8n's LangChain nodes, custom agents, and multi-model orchestration, having someone who has built these systems before matters.

You need a partner, not a configuration. An ongoing engagement means someone is actively looking at your workflows when you are not. When an upstream API changes its response format and breaks three of your workflows, you find out because we catch it — not because a client reports that their onboarding sequence stopped sending emails.

FAQ

Is n8n self-hosted free?

The n8n software itself is free and open-source under a fair-code license. Self-hosting it is not free — you pay for the VPS or cloud server that runs it, which ranges from €15 to €80/month depending on specs and provider. You also pay in engineering time: setup, maintenance, updates, and incident response. The licensing cost is zero. The operational cost is not.

How much does it cost to self-host n8n?

Infrastructure alone: €30-100/month for a production-ready setup with VPS, PostgreSQL, backups, and monitoring. When you factor in the engineering labor — setup amortized over the server's lifetime plus ongoing maintenance at a realistic hourly rate — the true monthly cost of properly self-hosted n8n is typically €220-400/month. Cheap if you have the skills and time. Expensive if you are paying for those skills at market rate or taking them from other priorities.

Is n8n hard to set up?

A basic Docker test instance: no, it takes 20 minutes. A production-ready self-hosted environment with PostgreSQL, a reverse proxy with SSL, queue mode, backups, monitoring, and proper security: yes, it is a substantial infrastructure project. Expect 15-25 hours for initial setup done properly, and 2-4 hours per month for ongoing maintenance. The difficulty is not in n8n itself — it is in everything that needs to surround it to be reliable.

What is the difference between n8n Cloud and n8n self-hosted?

n8n Cloud is n8n's managed SaaS product. You pay n8n directly on an execution-based pricing plan, and n8n handles all the infrastructure. The trade-off: your data lives on n8n's servers, and at high execution volumes the pricing becomes significant. n8n self-hosted runs on your own infrastructure — or on managed infrastructure like EsperaStudio's — with no execution-based pricing, full data control, and no dependency on n8n's hosting. The capability is identical; the infrastructure ownership and cost model differ.

The Bottom Line

n8n is the right foundation for serious automation work. That is not in question. The question is whether you should run the infrastructure yourself or have someone else run it while you use the workflows it produces.

If you have a developer who finds infrastructure work genuinely interesting, you are building automation-as-a-product, or your volume is high enough that managed costs do not scale — run it yourself. The capability is all there, the community documentation is good, and the operational overhead is manageable with the right skills and attention. Either way, check out our 5 n8n workflows that save agencies 20+ hours per week for practical starting points once your instance is running.

If you want n8n's power — unlimited executions, AI-native workflows, full data sovereignty, no per-task pricing ceiling — without the DevOps burden, the ongoing maintenance, and the 3am incident response landing on you: that is what we do. We run n8n on production-grade infrastructure, build workflows with error handling and alerting baked in, manage updates and backups, and extend into custom software when n8n is not the right abstraction for the problem.

The starting point is the €500 Automation Audit. It is not a sales call with a deck. It is a structured diagnostic of your current operations — where the manual work is, what the automation opportunity actually is, and what a custom build would require and deliver. Before deciding how you want to run n8n, it helps to know exactly what you need to build on it. If you're ready for that conversation, book the audit here.