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

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

7 min read

Quick Answer: You can self-host n8n for a POC with a minimal docker-compose.yml (PostgreSQL or SQLite plus the n8n container), then later move to n8n Business to get managed hosting, enterprise controls (SSO, RBAC, audit logs), and support—without losing your existing workflows.

Frequently Asked Questions

How do I self-host n8n with Docker Compose for a POC?

Short Answer: Use a simple Docker Compose stack (n8n + database + optional reverse proxy), set a few core environment variables, and you’ll have a self-hosted n8n instance ready for a proof of concept in minutes.

Expanded Explanation:
For a POC, you don’t need a complex setup. A basic docker-compose.yml with n8n and a database (PostgreSQL for anything beyond trivial testing) is enough to start building and running real workflows. You’ll run everything on a single host, bind a port (e.g., 5678), and point your browser at that host to access the editor UI.

From there you can wire up triggers (webhooks, schedules, app events) and nodes for your stack, and validate that n8n can handle the branching, waiting, and iteration you need. When you outgrow the POC, you can either harden this stack (reverse proxy, TLS, backups, external DB) or move to n8n Business and migrate your workflows.

Key Takeaways:

  • A POC-friendly Docker Compose setup for n8n is usually just: n8n + PostgreSQL + optional reverse proxy.
  • Start simple for evaluation, then add security, external DB, and backups if you keep self-hosting or migrate to Business.

What’s the step-by-step process to self-host n8n with Docker Compose for a POC?

Short Answer: Create a basic docker-compose.yml, set environment variables, start the stack with docker compose up -d, then access the n8n editor via your host’s URL.

Expanded Explanation:
You can treat this as a disposable but realistic environment: single-node, minimal secrets management, and no HA—good enough to prove that n8n can automate your workflows. I recommend PostgreSQL from the start so you don’t have to migrate from SQLite later if the POC sticks. For external use, put n8n behind a reverse proxy (e.g., Traefik, Nginx) with HTTPS.

Below is a typical workflow: write the compose file, bring the stack up, configure basic settings, then start building and testing workflows with real data.

Steps:

  1. Create a docker-compose.yml for n8n + Postgres (POC-grade)
    Example starting point:

    version: '3.8'
    
    services:
      n8n:
        image: n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - "5678:5678"
        environment:
          - N8N_HOST=localhost
          - N8N_PORT=5678
          - N8N_PROTOCOL=http
          - N8N_EDITOR_BASE_URL=http://localhost:5678
          - N8N_ENCRYPTION_KEY=change_me_to_a_long_random_string
          - DB_TYPE=postgresdb
          - DB_POSTGRESDB_HOST=postgres
          - DB_POSTGRESDB_PORT=5432
          - DB_POSTGRESDB_DATABASE=n8n
          - DB_POSTGRESDB_USER=n8n
          - DB_POSTGRESDB_PASSWORD=n8n_password
          - GENERIC_TIMEZONE=Etc/UTC
        depends_on:
          - postgres
        volumes:
          - n8n_data:/home/node/.n8n
    
      postgres:
        image: postgres:14
        restart: unless-stopped
        environment:
          - POSTGRES_USER=n8n
          - POSTGRES_PASSWORD=n8n_password
          - POSTGRES_DB=n8n
        volumes:
          - postgres_data:/var/lib/postgresql/data
    
    volumes:
      n8n_data:
      postgres_data:
    

    For a quick local-only POC, you can swap Postgres for SQLite by removing the DB service and DB env vars and mounting a single volume, but Postgres is better if you might keep the instance around.

  2. Start the stack and confirm n8n is running

    docker compose up -d
    docker compose logs -f n8n
    

    Then open http://localhost:5678 (or your server’s IP / hostname and mapped port) in your browser.

  3. Do minimal hardening and validation

    • Set a strong N8N_ENCRYPTION_KEY before building anything serious.
    • If you’ll expose n8n beyond localhost, put it behind a reverse proxy with TLS.
    • Build a couple of representative workflows that use your stack—webhook triggers, HTTP Request nodes, AI calls—and test them with real data. Use n8n’s execution history and step-level inputs/outputs to verify behavior before involving more users.

What’s the difference between a self-hosted Docker Compose POC and n8n Business?

Short Answer: A Docker Compose POC gives you a single, self-managed instance, while n8n Business gives you managed infrastructure plus enterprise controls like SSO, RBAC, audit logs, environments, and support.

Expanded Explanation:
With a POC, you’re responsible for everything: Docker updates, backups, monitoring, security, and scaling. That’s fine for a small evaluation, but it becomes a hidden tax when workflows go production-critical. n8n Business moves that operational burden to n8n’s team and layers on governance: SSO (SAML/LDAP), granular RBAC, audit logs, environments, Git-based version control, and log streaming to your SIEM.

In practice, the workflow-building experience stays familiar—the same visual canvas, nodes, code steps (JavaScript/Python), and execution view. The difference is what surrounds it: enterprise-grade access control, observability, and support for teams who can’t afford “future incident” automation.

Comparison Snapshot:

  • Option A: Self-hosted Docker Compose POC
    • You own infrastructure, updates, backups, networking, and security.
    • Single environment, manual user management, limited governance by default.
  • Option B: n8n Business
    • Managed hosting with SOC2, GDPR, EU data hosting (Frankfurt) options.
    • SSO SAML/LDAP, RBAC, audit logs, log streaming, environments, Git-based version control, and priority support.
  • Best for:
    • POC: quick validation and internal experiments.
    • Business: production workloads with compliance, security, and multi-team collaboration requirements.

How does upgrading from a self-hosted Docker Compose POC to n8n Business work?

Short Answer: You export workflows and credentials from your self-hosted instance, import them into n8n Business, then rewire environment-specific details like URLs, secrets, and triggers.

Expanded Explanation:
The core artifacts—workflows and their logic—move cleanly between self-hosted and Business because they use the same engine and editor. The main work is in mapping environment differences: base URLs, authentication, secrets storage, and any external services you relied on in your POC.

In n8n Business, you’ll likely also restructure around environments (e.g., Dev/Stage/Prod) and adopt Git-based version control so you can diff and roll back workflow changes. That’s where the “proof of concept” turns into something you’d be comfortable putting in an on-call runbook.

What You Need:

  • Exportable artifacts from POC:
    • Workflows (JSON exports) and, if applicable, credentials (or a plan to recreate them securely).
    • A list of triggers (webhooks, schedules, app events) and external dependencies (APIs, databases, queues).
  • A migration plan into Business:
    • Target environments and naming (e.g., dev, staging, prod).
    • Mapping of secrets into n8n’s encrypted secret store and any SSO/RBAC roles you want to enforce.
    • A short validation checklist: trigger firing, execution logs, guardrails on AI steps, and error workflows.

Strategically, when should I move from a Docker Compose POC to n8n Business?

Short Answer: Move to n8n Business once your workflows are becoming production-critical, touching sensitive data, or involving multiple teams that need governance, observability, and formal support.

Expanded Explanation:
A local or self-hosted Docker Compose setup is ideal for proving that n8n can handle your use cases: testing AI flows with real data, integrating your internal APIs via HTTP Request nodes, and validating performance. But once those workflows start carrying revenue, customer experience, or security impact, the calculus changes.

At that point, you don’t just need “automation that works”—you need automation you can operate: SSO to control who can edit what, RBAC to limit risk, audit logs and log streaming for incident investigations, Git-based workflow diffs, and reliable hosting. n8n Business is designed precisely for that pivot from experimentation to governed, enterprise-grade operations.

Why It Matters:

  • Impact 1: Reduced operational risk
    • You replace “pets” containers with a platform that has SOC2, GDPR alignment, EU hosting, and enterprise-grade observability—backed by a team whose job is to keep it running.
  • Impact 2: Faster, safer iteration at scale
    • Teams can move quickly (re-run single steps, inspect inputs/outputs, evaluate AI nodes) while staying inside guardrails (RBAC, environments, Git workflows, audit logs) that your security and compliance teams can live with.

Quick Recap

A self-hosted n8n POC with Docker Compose is a fast, realistic way to validate workflows: you spin up n8n and a database, build flows using visual nodes plus optional JavaScript/Python, and test with real data while inspecting execution history step by step. When those workflows become essential—or you need SSO, RBAC, audit logs, environments, Git-based version control, and managed, compliant hosting—that’s the point to move to n8n Business and treat automation as production infrastructure, not a side project container.

Next Step

Get Started