n8n App: A DevOps Guide to Self-Hosting and Deploying It

Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

The n8n app is a workflow automation platform that lets engineering teams connect APIs, databases, and internal services without writing a full custom integration layer for every task. For teams that already run Docker and manage their own infrastructure, deploying the n8n app on a VPS gives you complete control over data, credentials, and execution limits that hosted automation tools typically restrict. This guide walks through installing, configuring, securing, and operating the n8n app in a production-like environment.

What the n8n App Actually Does

The n8n app is a node-based automation engine. Each workflow is a directed graph of nodes — triggers, actions, and logic — connected visually in a browser-based editor. Under the hood, it’s a Node.js application that can run as a single process or be split into separate components (main process, worker processes, and a webhook listener) for higher-throughput deployments.

Unlike simpler “if this then that” tools, the n8n app supports:

Conditional branching and merging within a workflow

Custom JavaScript or Python code nodes for logic that doesn’t fit a pre-built node

Sub-workflows that can be called from other workflows

Native support for queued/distributed execution via Redis

A REST API for programmatically creating, triggering, and monitoring workflows

Because it’s open source, the n8n app can be run entirely on infrastructure you control, which matters if your workflows touch sensitive credentials — database passwords, payment provider keys, internal service tokens — that you don’t want passing through a third-party SaaS platform.

Where the n8n App Fits in a DevOps Stack

In a typical DevOps context, the n8n app sits between systems that don’t natively talk to each other. Common uses include:

Triggering CI/CD notifications based on webhook events from GitHub or GitLab

Syncing data between a CRM, a spreadsheet, and an internal database on a schedule

Orchestrating content pipelines (fetch data → transform → publish → notify)

Acting as a lightweight ETL tool for moving data between APIs without a dedicated data pipeline framework

If you’re evaluating whether to build custom scripts versus using a workflow tool, the n8n app usually wins when the integration involves multiple branching conditions, retries, or needs a visual audit trail non-engineers on your team can read.

Installing the n8n App with Docker

The most reliable way to run the n8n app in production is Docker, since it isolates the Node.js runtime and dependencies from the host system and makes upgrades a matter of pulling a new image tag.

Minimal Docker Compose Setup

A single-container setup is enough for low-to-moderate workflow volume:

version: "3.8"
services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=your-domain.com
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - WEBHOOK_URL=https://your-domain.com/
      - GENERIC_TIMEZONE=UTC
      - N8N_ENCRYPTION_KEY=replace_with_a_long_random_string
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Bring it up with:

docker compose up -d

N8N_ENCRYPTION_KEY is critical — it’s used to encrypt stored credentials at rest. Set it once, keep it in a secrets manager, and never regenerate it after the n8n app has stored real credentials, or every saved connection will fail to decrypt. If you need a refresher on managing environment variables safely in Compose files rather than hardcoding them, see this guide to Docker Compose environment variables.

Adding PostgreSQL for Production Reliability

By default, the n8n app stores its data (workflows, credentials, execution history) in a local SQLite file. That’s fine for testing, but SQLite doesn’t handle concurrent writes well under real load, and it complicates backups since the database lives inside the container volume. For anything beyond a personal instance, point the n8n app at PostgreSQL instead:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=change_me
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      - postgres
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=change_me
    ports:
      - "5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  postgres_data:
  n8n_data:

If you haven’t set up Postgres in Compose before, this Postgres Docker Compose setup guide covers volume persistence and connection tuning in more depth. It’s also worth reviewing how to inspect running containers with Docker Compose logs when the n8n app fails to connect to its database on first boot — misconfigured DB_POSTGRESDB_HOST values are the most common cause.

Configuring the n8n App for Production Use

A default installation of the n8n app is meant for evaluation, not production traffic. There are a handful of settings worth changing before you rely on it for real workflows.

Authentication and Access Control

Never expose the n8n app editor UI to the public internet without authentication. At minimum, enable basic auth:

N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=a_strong_password

For anything beyond a single-user instance, use n8n’s built-in user management (available since n8n moved past pure basic-auth) instead, since it supports per-user roles and doesn’t share one static credential across a team.

Putting the n8n App Behind a Reverse Proxy

Running the n8n app directly on port 5678 without TLS is not appropriate for production. Put it behind a reverse proxy that terminates HTTPS — Caddy, Nginx, or Cloudflare in front of your VPS. If you’re using Cloudflare for TLS and caching in front of the n8n app, Cloudflare Page Rules can help control caching behavior for the webhook endpoints specifically, since webhook responses should generally bypass cache entirely.

Scaling Execution with Queue Mode

By default, the n8n app executes workflows in the same process that serves the web UI. Under load, a long-running workflow can block the editor from responding. Queue mode splits this apart using Redis:

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379

With queue mode, you run separate worker containers that pull jobs from Redis, so the main n8n app process stays responsive even while workers are busy. If you haven’t containerized Redis before, this Redis Docker Compose setup guide walks through the basic service definition and persistence options.

Comparing the n8n App to Alternatives

Before committing to the n8n app, it’s worth understanding what you’re trading off against other automation tools.

n8n App vs. Hosted Automation Platforms

Hosted platforms like Zapier or Make handle infrastructure for you but charge per execution or per task, and typically restrict how much custom code you can run inside a workflow. The n8n app, self-hosted, has no per-execution billing — your cost is the VPS itself — but you take on responsibility for uptime, backups, and security patching. If you’re deciding between n8n and Make specifically, this n8n vs Make comparison breaks down pricing models and node libraries side by side.

n8n App vs. n8n Cloud

n8n also offers a managed cloud version, which removes the hosting burden but reintroduces the pricing-tier and data-residency tradeoffs that self-hosting avoids. If cost is the deciding factor, review this breakdown of n8n Cloud pricing against your expected workflow volume before choosing between the self-hosted n8n app and the managed option.

Operating the n8n App Day to Day

Once the n8n app is running, ongoing operational tasks matter more than the initial install.

Backups

Back up two things separately: the database (Postgres dump, scheduled via cron) and the N8N_ENCRYPTION_KEY. Losing the encryption key without a backup means every stored credential becomes permanently unreadable, even if the database itself is intact. A simple backup routine:

docker exec -t postgres pg_dump -U n8n n8n > /backups/n8n_$(date +%F).sql

Store the encryption key outside the container volume — a secrets manager or an encrypted offline copy — not just inside the .env file sitting next to your Compose file.

Monitoring and Logs

Treat the n8n app like any other production service: monitor container health, disk usage (execution history grows over time and should be pruned via EXECUTIONS_DATA_PRUNE settings), and error rates on workflow runs. n8n exposes execution history in its UI, but for alerting you’ll generally want to forward container logs to your existing log aggregation, the same way you would for any other Docker service.

Automating Workflow Deployment with the API

Rather than manually recreating workflows across environments, the n8n app exposes a REST API for importing and exporting workflow JSON, which lets you version-control workflows alongside your other infrastructure code and promote them between staging and production programmatically instead of clicking through the UI each time.

Recommended: Ready to put this into practice? DigitalOcean is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.

FAQ

Is the n8n app free to self-host?
Yes. The n8n app is open source under a fair-code license, and self-hosting it on your own VPS or server incurs no licensing fee — your only cost is the infrastructure it runs on.

How much does the n8n app cost to run on a VPS?
That depends entirely on the VPS provider and instance size you choose, but a small-to-moderate workload typically fits on a modest VPS. Providers like DigitalOcean and Hetzner offer VPS tiers commonly used for self-hosted n8n instances.

Can the n8n app scale to handle high workflow volume?
Yes, using queue mode with Redis and multiple worker containers, as described above. This decouples the web UI from execution and lets you add worker capacity independently of the main process.

Does the n8n app require a database?
It works with SQLite by default for small or test instances, but PostgreSQL is strongly recommended for production because it handles concurrent execution writes reliably and simplifies backup and restore.

Conclusion

The n8n app gives DevOps teams a self-hosted alternative to SaaS automation tools, trading a small amount of operational overhead — container management, database setup, encryption key custody — for full control over data and no per-execution billing. A production-ready deployment means Docker Compose with PostgreSQL, a reverse proxy terminating TLS, authentication enabled, and a real backup routine covering both the database and the encryption key. Once that foundation is in place, the n8n app scales from a single-container hobby instance to a queue-mode, multi-worker deployment without changing the underlying workflow definitions. For further reference on the underlying container tooling, see the official Docker documentation and the n8n documentation.