An n8n production setup involves migrating your workflows from a local test environment to a stable, secure, and scalable server configuration designed to handle mission-critical automations. This process includes choosing the right hosting with Docker, configuring a robust database like PostgreSQL, securing your instance with a reverse proxy, and fine-tuning performance with specific environment variables. Getting this right is the key to building reliable automations that your business can depend on.
From “It Works on My Machine” to Production-Ready
We’ve all been there. You spend hours, maybe even days, perfecting a workflow. It pulls data from three APIs, transforms it beautifully, and sends out the perfect notification. You hit ‘Execute Workflow,’ and it runs flawlessly on your laptop. It’s a moment of pure joy! But then, the big question looms: how do you make this automation a reliable, always-on part of your business? Moving to production is more than just running n8n on a server; it’s about building a fortress of reliability, security, and scalability.
Let’s be honest, the default setup is fantastic for getting started, but it’s not built for the demands of a live environment. Think of it like this: your local n8n is a brilliant but messy workshop. A production setup is a clean, organized, and automated factory floor. Let’s build that factory.
The Foundation: Choosing Your Hosting and Database
Before you can configure anything, you need a place for your n8n instance to live. This is the single most important decision you’ll make in your n8n production setup journey.
Where Should Your n8n Live?
While you can install n8n directly on a server, the undisputed champion for hosting is Docker. Using Docker is like putting your n8n application and all its needs into a standardized, portable container. It simplifies deployment, updates, and management immensely. You’re no longer asking, “What version of Node.js is on this server?” You’re just running the container.
Most professionals deploy their n8n Docker container on:
- A Virtual Private Server (VPS): Services like DigitalOcean, Hetzner, or Linode give you a blank slate Linux server where you can run Docker with full control.
- Cloud Platforms: AWS, Google Cloud, and Azure offer more advanced, scalable options, often using services like Kubernetes for orchestration.
For most users, a simple VPS running Docker Compose is the perfect balance of cost, control, and simplicity.
Why a Dedicated Database is Non-Negotiable
n8n uses a database to store everything: your workflows, credentials, and execution logs. By default, it uses SQLite, which saves everything to a single file. This is great for testing, but for production, it’s a recipe for disaster. It’s like using a personal notepad for your company’s entire financial ledger—it’s slow, prone to corruption under heavy load, and doesn’t scale.
The industry standard and highly recommended choice is PostgreSQL (or Postgres). It’s robust, reliable, and can handle a massive amount of data without breaking a sweat. Migrating to Postgres is a fundamental step in any serious n8n production setup.
Essential Configurations via Environment Variables
Environment variables are how you talk to your n8n instance and tell it how to behave. Instead of editing configuration files, you pass these settings to the Docker container on startup. They are the control knobs for your n8n engine.
While there are dozens of variables, here are the non-negotiables for production:
| Category | Key Variables | Why It’s Crucial for Production |
|---|---|---|
| Security | N8N_ENCRYPTION_KEY |
This is the master key to your credentials kingdom. If you don’t set this, n8n uses a default one. Set a long, random string here and back it up somewhere safe. If you lose it, your credentials are gone forever. |
| Execution | EXECUTIONS_MODE=queue |
This is arguably the most critical performance setting. It tells n8n to use a main process to receive tasks and dedicated ‘worker’ processes to execute them, preventing long workflows from timing out your whole instance. |
| Database | DB_TYPE=postgresdb & DB_... |
These variables tell n8n to use your external PostgreSQL database instead of the default SQLite file. |
| Maintenance | EXECUTIONS_DATA_PRUNE=true & EXECUTIONS_DATA_MAX_AGE |
Automatically deletes old execution logs from your database. This keeps your instance snappy and prevents your database from growing to an unmanageable size. I usually set MAX_AGE to 168 (7 days). |
| Networking | WEBHOOK_URL |
This tells n8n its public-facing address (e.g., https://n8n.mycompany.com/). Without this, it can’t generate the correct URLs for webhooks in your workflows. |
The Public Face: Security with a Reverse Proxy
You should never expose your n8n instance directly to the internet. Think of your n8n as a VIP that needs a bodyguard. That bodyguard is a reverse proxy.
A reverse proxy is a server (apps like Nginx, Caddy, or Traefik are popular choices) that sits in front of n8n. All public traffic hits the proxy first, which then intelligently forwards it to n8n running safely on its internal port (e.g., 5678).
A reverse proxy handles critical jobs:
- SSL/TLS Termination: It manages your SSL certificate, giving you that secure
https://lock icon in the browser. - Clean URLs: It maps your pretty domain (
n8n.mycompany.com) to the internallocalhost:5678address. - Enhanced Security: It can be configured to add extra security layers, like IP whitelisting for the editor UI while leaving webhook endpoints open to the public.
Real-World Example: A Secure Reporting Workflow
I once worked with a marketing agency that automated client report generation. The workflow was triggered when a client filled out a form, which sent data to an n8n webhook.
- The Challenge: They needed the webhook URL to be public but wanted to prevent anyone from accessing the n8n editor where all their client workflows were stored.
- The Production Solution:
- We set up n8n with Docker Compose on a DigitalOcean droplet, connected to a managed PostgreSQL database.
- We installed Nginx as a reverse proxy.
- The critical part was the Nginx configuration. We created two rules:
- Any request to
/webhook/*was passed directly to n8n, no questions asked. This allowed the client form to work. - Any request to
/(the root, which loads the UI) was configured to only allow traffic from the agency’s office IP address. Everyone else got a block page.
- Any request to
- Finally, we set the
WEBHOOK_URLenvironment variable tohttps://reports.theiragency.com/.
This n8n production setup gave them the perfect blend of public accessibility and private security.
Scaling and Maintenance: Keeping It Running Smoothly
A production system isn’t ‘set it and forget it.’ It needs care and feeding.
- Backups Are Your Lifeline: Regularly back up two things: your PostgreSQL database and your
~/.n8ndirectory (which contains yourn8n-config.jsonand, crucially, your encryption key!). A failure to do so is just asking for a very, very bad day. - Understand Queue Mode: As mentioned,
EXECUTIONS_MODE=queueis vital. It creates different types of processes. Themainprocess manages the UI,webhookprocesses quickly acknowledge incoming webhooks, andworkerprocesses do the heavy lifting of running the actual logic. This separation is key to a responsive system. - Monitor Your System: Keep an eye on your server’s CPU and memory usage. If you find your workers are constantly maxed out, it might be time to increase the number of workers (
EXECUTIONS_PROCESS=main) or upgrade your server.
Taking your n8n automations to production is a huge step. It transforms them from fun experiments into reliable, powerful business assets. By focusing on a solid foundation with Docker and Postgres, securing it with a reverse proxy, and fine-tuning it with the right environment variables, you’ll build an n8n setup that you can trust.
