Self-hosting n8n: a production-grade setup guide

Architecture: main instance vs. queue mode

The default n8n setup runs everything in a single process: the web UI, the API, the workflow scheduler, and the workflow execution engine. This works well for development and low-volume use. In production, it has a critical limitation: if a long-running workflow ties up the process, new workflows queue behind it. If your instance has memory pressure, a single misbehaving workflow can take down the UI and stop new executions entirely.

Queue mode separates concerns. The main instance handles the UI and API. Worker instances handle workflow execution. A Redis queue sits between them — the main instance adds jobs to the queue, workers pick them up and execute them. You can run multiple workers, distributing execution across machines. If a worker goes down, other workers continue processing. If you need more capacity, you add workers.

For production use handling more than 100 workflows per day or any workflow that takes more than a few seconds to execute, queue mode is not optional. The operational overhead of running Redis and separate worker instances is minimal compared to the reliability improvement. The sections below cover the full setup, but start with the queue mode decision before anything else.

Database: moving off SQLite

n8n defaults to SQLite for its internal database. SQLite is fine for development. In production, it has three problems: it doesn't support concurrent writes (a problem with multiple workers), it's hard to back up reliably while the instance is running, and it grows without bound as execution history accumulates. Migrate to PostgreSQL before you put anything important on the instance.

Set up a Postgres database with a dedicated user and a separate schema for n8n. The connection string goes in the DB_POSTGRESDB_* environment variables. Run n8n once to apply the schema migrations, verify the tables are created, and then export any existing data from SQLite if you have workflows you want to keep. The migration is a one-time operation and n8n handles it automatically on first start with Postgres configured.

Execution history in Postgres grows significantly with high-volume usage. Configure EXECUTIONS_DATA_PRUNE to delete old execution data automatically. We keep 30 days of execution history for most workflows and 90 days for business-critical ones. Add a Postgres maintenance job to run VACUUM ANALYZE weekly — n8n's execution log creates a lot of dead tuples under high write volume.

Security defaults that must be set before going live

The n8n defaults are not production security defaults. Several settings need to change before your instance is exposed to the internet. First: disable basic auth if you're using it and set up proper authentication. n8n supports SAML and LDAP in the enterprise version, or you can place it behind an auth proxy like Authentik or Authelia that handles authentication at the reverse proxy layer before requests reach n8n.

The N8N_ENCRYPTION_KEY environment variable must be set to a strong random value before your first run. This key encrypts stored credentials. If you lose it, you lose access to all stored credentials. If you change it without proper migration, existing credentials become unusable. Generate it once, store it in your secrets manager, and treat it with the same care you'd treat a private key.

Restrict the webhook URL if your instance is exposed publicly. Anyone who can guess your webhook paths can trigger your workflows. Use the WEBHOOK_URL environment variable to set the public URL, ensure HTTPS is enforced at the reverse proxy, and consider adding webhook authentication (a shared secret in the webhook path or header) for any webhook that triggers sensitive operations. Don't rely on security through obscurity — use real authentication.

• Set N8N_ENCRYPTION_KEY before first run, store in secrets manager
• Enable HTTPS via reverse proxy (Caddy or Nginx with Let's Encrypt)
• Configure authentication — auth proxy or n8n's built-in user management
• Restrict EXECUTIONS_DATA_MAX_AGE to avoid unbounded database growth
• Disable the n8n diagnostics and usage telemetry in air-gapped environments
• Set up network-level access controls — n8n should not be publicly accessible on port 5678

Backup strategy: what to back up and how

The data you care about in n8n falls into three categories: workflow definitions, credential configurations, and execution history. Workflow definitions are the most critical — losing them means losing all your automation logic. Credential configurations are next — losing them means re-entering all API keys and tokens. Execution history is useful for debugging but is the least critical to restore.

Back up the Postgres database daily with pg_dump. Store the backup in a separate location from the instance — at minimum an S3 bucket in a different region. Test the restore process quarterly: spin up a fresh n8n instance, restore the database dump, and verify that workflows load and credentials are accessible. An untested backup is not a backup.

n8n also exposes an API for exporting workflows in JSON format. Running a nightly n8n workflow that calls the API and commits workflow JSON to a git repository gives you version-controlled workflow history — you can see exactly what changed in each workflow over time and roll back to a previous version if needed. This is separate from the database backup and complements it.

Monitoring and alerting for production instances

A production n8n instance needs monitoring at two levels: infrastructure health and workflow health. Infrastructure health means the instance is running, memory and CPU are within bounds, and the database connection is live. Workflow health means critical workflows are executing on schedule and not failing silently.

For infrastructure health, basic uptime monitoring with a tool like Uptime Kuma (which can itself run as a Docker container on the same host) handles the basics. Set up alerts for the main n8n endpoint, the Redis connection, and the Postgres connection. A dead Redis instance stops all queued workflow execution while the main instance continues to appear healthy — monitoring only the main instance isn't enough.

For workflow health, n8n's built-in error workflow feature is underused. Configure a global error workflow that fires whenever any workflow fails. The error workflow receives the error details, the workflow ID, and the execution context. Use it to send a Slack alert with enough context to debug the failure — the workflow name, the node that failed, and the error message. Without this, workflow failures are silent until a business outcome fails.

Managing updates without downtime

n8n releases updates frequently, and they occasionally include breaking changes. Running on the latest version is important for security patches, but uncontrolled updates in production environments cause incidents. The update strategy that works best in production: pin the Docker image to a specific version, test updates on a staging instance first, and deploy to production during low-traffic windows.

Before any update, back up the database. Read the n8n release notes carefully — they flag breaking changes and required migration steps. After the update, verify that all previously-working workflows still execute correctly by running a test execution on each critical workflow manually. The staging environment test catches most issues, but production sometimes has subtle differences in configuration or data.

For zero-downtime updates with queue mode, update worker instances first while the main instance continues serving UI requests and queuing new jobs. Once workers are on the new version and stable, update the main instance. Active jobs may fail during the main instance restart — configure your critical workflows with retry logic so they recover automatically when the main instance comes back up.