How do I self-host n8n with Docker Compose for a POC, and what changes when upgrading to n8n Business?

Quick Answer: Use Docker Compose to spin up a self-hosted n8n POC in minutes—typically a single docker-compose.yml file with n8n, Postgres, and optional Redis. When you upgrade to n8n Business, the core runtime stays familiar, but you gain enterprise features like SSO, RBAC, environments, Git-based version control, and support that influence how you deploy, secure, and operate your instance.

Frequently Asked Questions

How do I self-host n8n with Docker Compose for a proof of concept (POC)?

Short Answer: Create a docker-compose.yml with n8n, a database (e.g., Postgres), and a volume for persistent storage, then start it with docker compose up -d. That’s usually enough to run a realistic POC on your own infrastructure.

Expanded Explanation:
For a POC, you don’t need a full production cluster. A single Docker host and a well-structured docker-compose.yml is enough to test triggers, nodes, JavaScript/Python steps, and basic observability (logs, execution history). The key is to externalize n8n’s data (database and encryption key) so you can safely restart containers without losing workflows, credentials, or execution logs.

Most teams start with an n8n container, a Postgres container, and a named volume for the database. You can add Redis later if you want to test queues or higher throughput. From there, you expose n8n on a port behind your preferred reverse proxy (e.g., Traefik, Nginx) and start building workflows triggered by schedules, webhooks, or app events.

Key Takeaways:

• A simple Docker Compose stack (n8n + Postgres) is enough for a credible POC.
• Persist data and credentials via volumes and environment variables so your POC behaves like a future production setup.

---

What are the step-by-step instructions to run n8n with Docker Compose for a POC?

Short Answer: Install Docker/Docker Compose, define docker-compose.yml, set basic environment variables, then run docker compose up -d and open n8n in your browser.

Expanded Explanation:
You want your POC to feel close to production without over-engineering. That means picking Postgres from day one, setting the encryption_key, and wiring environment variables instead of baking secrets into images. The actual process is fast: set up Docker, create a compose file, configure ports and volumes, and then build a few workflows that hit real APIs via nodes or the HTTP Request node.

Here’s a lean, realistic process you can follow on any Linux VM, local machine, or lab server.

Steps:

1. Prepare your host

   • Install Docker Engine and Docker Compose (or use docker compose with recent Docker versions).
   • Ensure ports (e.g., 5678 or your chosen HTTPS port) are open on your firewall.
   • Create a working directory, for example:

     mkdir -p ~/n8n-poc && cd ~/n8n-poc
     

2. Create a minimal docker-compose.yml Example (Postgres + n8n):

   version: "3.8"
   
   services:
     postgres:
       image: postgres:16
       restart: unless-stopped
       environment:
         POSTGRES_USER: n8n
         POSTGRES_PASSWORD: n8n
         POSTGRES_DB: n8n
       volumes:
         - n8n-postgres-data:/var/lib/postgresql/data
   
     n8n:
       image: n8nio/n8n:latest
       restart: unless-stopped
       ports:
         - "5678:5678"
       environment:
         N8N_BASIC_AUTH_ACTIVE: "true"
         N8N_BASIC_AUTH_USER: "admin"
         N8N_BASIC_AUTH_PASSWORD: "change-me"
         DB_TYPE: "postgresdb"
         DB_POSTGRESDB_HOST: "postgres"
         DB_POSTGRESDB_PORT: 5432
         DB_POSTGRESDB_DATABASE: "n8n"
         DB_POSTGRESDB_USER: "n8n"
         DB_POSTGRESDB_PASSWORD: "n8n"
         N8N_ENCRYPTION_KEY: "replace-with-long-random-string"
         N8N_HOST: "localhost"
         N8N_PORT: 5678
         N8N_PROTOCOL: "http"
       depends_on:
         - postgres
   
   volumes:
     n8n-postgres-data:
   

   For a POC this is fine; for anything sensitive, put secrets into an .env file instead of hardcoding them.

3. Start the stack and validate

   • Run:

     docker compose pull
     docker compose up -d
     

   • Open http://<your-host>:5678 in your browser.
   • Log in with the basic auth credentials you defined.
   • Build a test workflow:
     • Add a Cron node (scheduled trigger) or Webhook node.
     • Add an HTTP Request node calling a familiar API.
     • Add a Function or Python node for last-mile logic.
   • Run the workflow and inspect inputs/outputs, execution logs, and retries to see how n8n behaves under real data.

---

What’s the difference between a Docker Compose POC setup and a production-grade n8n Business deployment?

Short Answer: The POC stack is usually a single host with basic auth and minimal governance, while a production n8n Business deployment layers on SSO, RBAC, environments, Git-based version control, stronger observability, and stricter security controls—often with more structured infrastructure around it.

Expanded Explanation:
The containers themselves don’t dramatically change when you move from a POC to n8n Business; what changes is how you operate them and which enterprise features you enable. In a POC, it’s acceptable to run everything on one VM with a single environment and simple credentials. In Business, you’ll want identity integration (SSO SAML/LDAP), role-based permissions, dedicated environments (e.g., dev/stage/prod), and Git-based version control so you can diff workflows, track changes, and roll back safely.

You also start treating n8n like a critical service: external log streaming to your SIEM, backups, tighter secret management, and often a more robust reverse proxy/TLS setup. The goal isn’t to completely rebuild your POC; it’s to harden it with governance, security, and lifecycle practices.

Comparison Snapshot:

• Option A: Docker Compose POC
  • Single-node or small VM.
  • Basic auth and local users.
  • One environment, ad-hoc changes in the UI.
  • Local Docker logs only.
• Option B: n8n Business (production)
  • Enterprise auth (SSO SAML/LDAP) and RBAC.
  • Multiple environments + Git-based workflow version control.
  • Audit logs, log streaming, and governance features.
  • Enterprise support, SLAs, and SOC2/GDPR-aligned operations.
• Best for:
  • POC stack: quick validation, low-stakes data, short feedback loops.
  • n8n Business: mission-critical workflows where you need compliance, change control, and operational rigor.

---

What changes technically when I upgrade my self-hosted POC to n8n Business?

Short Answer: Your workflows and Docker Compose base can remain, but you’ll introduce Business-specific configuration: SSO, RBAC, environments, Git integration, and external observability (logs, SIEM, backups) alongside more formalized deployment practices.

Expanded Explanation:
If you’ve already standardized on Postgres and Docker Compose, upgrading is mostly about configuration and governance, not a full rebuild. You’ll align n8n with your identity provider, enable features like RBAC and audit logs, and decide how to manage environments and workflow versions (often Git-based). You’ll also tighten secret management and begin treating logs and executions as production telemetry—streamed to your SIEM, with retention policies and alerting.

Behind the scenes, you’re still running containers and building workflows on the same visual canvas with JavaScript/Python nodes and HTTP Request nodes. The difference is you now have enterprise-grade guardrails around who can change what, how those changes are tracked, and how you inspect and replay executions.

What You Need:

• An existing self-hosted n8n stack using Postgres (ideally similar to your POC).
• Access to your identity provider, Git, and logging/monitoring stack to wire in SSO, version control, and observability.

---

How should I plan my POC if I expect to move to n8n Business later?

Short Answer: Design your Docker Compose POC like a “mini-prod”: use Postgres, define an encryption key, separate environments logically, and start with basic security in mind so you can layer on n8n Business features without re-architecting.

Expanded Explanation:
If you know you’re heading toward n8n Business, treat your POC as the first iteration of your production deployment. Choose a database you’ll keep (Postgres), use an N8N_ENCRYPTION_KEY you won’t throw away, and avoid putting secrets into workflows directly. Build workflows with clear boundaries (e.g., separate dev/test workflows) so it’s easy to map them into development/staging/production environments later.

On the operations side, enable at least basic observability from day one: inspect logs, use execution history, and get comfortable re-running single steps and replaying data. These habits carry directly into Business, where you’ll have additional tooling like audit logs, log streaming, and Git diffs for workflows. That’s what lets you scale from “cool POC” to “this runs core processes and won’t surprise us at 3 a.m.”

Why It Matters:

• A production-minded POC reduces migration friction when you switch on n8n Business and enterprise controls.
• Early attention to security, observability, and structure gives you reliable, auditable workflows instead of one-off experiments that don’t survive contact with production.

---

Quick Recap

A Docker Compose POC for n8n is straightforward: run n8n with Postgres, persist data via volumes, and start building workflows that hit real APIs and data. When you upgrade to n8n Business, you keep the same core runtime and builder experience but add the enterprise layer—SSO, RBAC, environments, Git-based version control, audit logs, log streaming, and formal support. If you design your POC with Postgres, encryption keys, and basic security from the start, the path to a governed, production-ready Business deployment is mostly configuration and policy, not a full rebuild.

Next Step

Get Started