Self-Hosting n8n vs Activepieces on Docker (2026): Setup, Resources & Day-2 Ops

June 28, 2026 · By Ken Hayashi · 13 min read

Picking the tool is the easy part. The harder question is what each one costs you to run — the RAM it eats, the database it forces on you, and the 2 a.m. upgrade that takes your webhooks down. This is the deployment guide we wish we'd had: real docker-compose configs, honest resource numbers, and the operational gotchas that don't show up in a feature table.

This article is the hands-on companion to our broader honest comparison of n8n vs Activepieces for B2B teams. There we covered which tool wins on features, integrations, and overall fit. Here we assume you've roughly decided — or you're deciding based on what it takes to operate — and you want to know exactly what landing each one on your own infrastructure looks like.

Deployment at a glance

Before the configs, here's how the two stacks differ on the things that matter once you're the one holding the pager. Everything below is verified against the official Docker docs as of June 2026.

Read this first: the license quietly picks your architecture

Most "how to self-host" guides skip licensing, then readers get surprised in month six. Don't. For a self-hosting decision the license isn't legal trivia — it changes which container you should even start.

n8n ships under the Sustainable Use License, a "fair-code" license. In plain terms: self-hosting n8n to automate your own company's internal work is free, with no execution limits. The restriction only bites if you want to offer n8n itself as a service to others, or embed it inside a commercial product you sell — that needs a paid agreement.

Activepieces licenses its core engine under MIT — about as permissive as open source gets. You can use it, fork it, and ship it inside your own product with no strings on the core. A handful of enterprise features live behind a separate paid edition, but the automation engine is genuinely MIT.

What you need before you start

Identical baseline for both, which keeps this simple:

• A Linux host — a VPS or a box you control. Sizing differs (see below), but Ubuntu 22.04/24.04 LTS is a safe default for either.
• Docker + Docker Compose — the modern docker compose plugin, not the legacy docker-compose binary.
• A domain + reverse proxy — both tools fire and receive webhooks, so they need a publicly reachable HTTPS URL. Caddy, Traefik, or Nginx all work; the configs below assume you'll put one in front.
• Persistent volumes — encryption keys and workflow data live on disk. Lose the volume, lose your credentials.

Deploying Activepieces on Docker

Activepieces wins the "time to first workflow" race, so we'll start here. The single-image design means the fastest possible start is genuinely one command.

The 60-second start (testing only)

# Single container, embedded PGLite DB, in-memory queue
docker run -d -p 8080:80 \
  -v ~/.activepieces:/root/.activepieces \
  -e AP_DB_TYPE=PGLITE \
  -e AP_REDIS_TYPE=MEMORY \
  -e AP_FRONTEND_URL="http://localhost:8080" \
  activepieces/activepieces:latest

Open http://localhost:8080 and you have a working automation platform. That's the headline number behind the "Activepieces is easier" reputation — and it's real.

The production setup (Postgres + Redis)

For anything a team relies on, give it a real database and a real queue. This is the shape of a sane compose.yaml:

services:
  activepieces:
    image: activepieces/activepieces:latest
    restart: unless-stopped
    ports: ["8080:80"]
    environment:
      AP_FRONTEND_URL: "https://automate.yourco.com"
      AP_DB_TYPE: POSTGRES
      AP_POSTGRES_HOST: postgres
      AP_POSTGRES_DATABASE: activepieces
      AP_POSTGRES_USERNAME: activepieces
      AP_POSTGRES_PASSWORD: ${AP_PG_PASSWORD}
      AP_REDIS_TYPE: REDIS
      AP_REDIS_HOST: redis
      AP_ENCRYPTION_KEY: ${AP_ENCRYPTION_KEY}   # 32-char hex, generate once & keep
      AP_JWT_SECRET: ${AP_JWT_SECRET}
    depends_on: [postgres, redis]

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: activepieces
      POSTGRES_USER: activepieces
      POSTGRES_PASSWORD: ${AP_PG_PASSWORD}
    volumes: ["ap_pg:/var/lib/postgresql/data"]

  redis:
    image: redis:7
    restart: unless-stopped

volumes:
  ap_pg:

Two environment variables deserve a sticky note: AP_ENCRYPTION_KEY and AP_JWT_SECRET. Generate them once, store them in your secrets manager, and never let them change — they encrypt stored connections. The other thing teams forget: AP_FRONTEND_URL must be the public HTTPS URL, or inbound webhooks from third-party apps will never reach you.

Deploying n8n on Docker

n8n's philosophy is the opposite: it nudges you toward a "real" stack from the start. There's a SQLite default, but every serious guide (and n8n's own docs) tells you to put Postgres behind it before you trust it with anything.

Single instance with Postgres

services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports: ["5678:5678"]
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${N8N_PG_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: automate.yourco.com
      WEBHOOK_URL: "https://automate.yourco.com/"
      N8N_PROTOCOL: https
    volumes: ["n8n_data:/home/node/.n8n"]
    depends_on: [postgres]

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${N8N_PG_PASSWORD}
    volumes: ["n8n_pg:/var/lib/postgresql/data"]

volumes:
  n8n_data:
  n8n_pg:

The N8N_ENCRYPTION_KEY plays the same role as Activepieces' encryption key — it locks the credentials in the database. Back it up separately from the database itself. The WEBHOOK_URL is the n8n equivalent of the public-URL gotcha; get it wrong and webhook nodes generate URLs that nobody can reach.

Scaling up: queue mode

This is where n8n's deployment story pulls ahead. When one container can't keep up, you switch from the default main mode to queue mode: the main instance stops executing workflows itself and instead drops jobs onto a Redis queue, which any number of dedicated worker containers pull from. Crucially, queue mode is available on the free self-hosted edition — you're not paying to scale.

# add to the n8n + a new worker service
environment:
  EXECUTIONS_MODE: queue
  QUEUE_BULL_REDIS_HOST: redis

n8n-worker:
  image: n8nio/n8n:latest
  command: worker          # run as a worker, not the UI
  environment:
    EXECUTIONS_MODE: queue
    QUEUE_BULL_REDIS_HOST: redis
    # ...same DB + encryption key as main...
  deploy: { replicas: 3 }   # scale workers independently

Want three more workers to absorb a traffic spike? Bump replicas. That clean separation of UI, queue, and execution is the single biggest operational reason teams who expect growth lean n8n. For the integration depth that pairs with this — for example wiring it into your Notion API workflows — see our integrations guides.

Resources & real monthly cost

The numbers below are practical sizing targets, not theoretical minimums. "It boots on 512 MB" is true and useless; these are sizes that survive contact with real workflows.

n8n: pros & cons for self-hosters

Activepieces: pros & cons for self-hosters

Day-2 operations: the part nobody screenshots

Standing the container up is day one. Days two through two-hundred are upgrades, backups, and the occasional 500. Here's the operational reality for each.

Upgrades

Both follow the Docker pattern — pull the new tag, recreate, let migrations run on boot. Always snapshot the database before pulling. The Activepieces caveat returns here: a PGLite instance is awkward to migrate, which is the real reason to start on Postgres if you're at all serious. n8n upgrades are routine, but read the release notes — occasional major versions deprecate node behaviors.

Backups

Three things must be in your backup, and the encryption key is the one people forget:

• The Postgres database — your workflows and execution history (pg_dump on a cron).
• The encryption key (N8N_ENCRYPTION_KEY / AP_ENCRYPTION_KEY) — without it, a restored database has unreadable credentials.
• Your compose + env files — version-control them (secrets excluded).

Scaling

This is the clearest operational split. n8n scales by adding stateless worker containers against a shared Redis queue — a well-trodden path. Activepieces' open-source single instance handles a lot before it strains, but true multi-instance horizontal scaling is an enterprise-edition concern. If you can already see five-figure monthly executions on the horizon, weight that heavily.

Troubleshooting the usual first-deploy failures

Four issues account for most "it won't work" threads:

• Webhooks return 404 or point at localhost. Your public URL env var is wrong — set WEBHOOK_URL (n8n) or AP_FRONTEND_URL (Activepieces) to the real HTTPS address behind your proxy.
• Credentials "disappear" after a redeploy. The encryption key changed or wasn't persisted. It must be identical across restarts and across every worker.
• Workers idle in queue mode. Main and workers must share the same Redis host and the same encryption key, with EXECUTIONS_MODE=queue set on both.
• Database connection refused on first boot. A depends_on only waits for the container to start, not for Postgres to accept connections — add a healthcheck or a short retry.

So which should you self-host?

Reduced to the operational decision:

• Choose Activepieces if you want the fastest, lightest deployment, you're running on modest hardware, or the MIT license matters because you'll embed automation in your own product. Just start on Postgres, not PGLite, if it's more than a toy.
• Choose n8n if you expect meaningful growth and want a proven scaling path, you're comfortable running a Postgres + Redis + workers stack, and you're automating internal work (so the fair-code license never bites).

And if you're still weighing the tools on features and integrations rather than ops, start with the full n8n vs Activepieces comparison — then come back here to plan the deploy.

Frequently asked questions

Methodology

Deployment details, environment variables, database/queue options, and stated system requirements were verified against the official n8n and Activepieces documentation and Docker images in June 2026. Resource and cost figures are practical sizing guidance synthesized from official hosting requirements and common VPS pricing tiers, not benchmarks of a specific workload — your numbers will vary with workflow complexity and execution volume. Licensing summaries reflect the n8n Sustainable Use License and the Activepieces MIT core as published at the time of writing; always confirm current terms before commercial deployment.

Ken Hayashi

Technology consultant with 10+ years in the Japanese tech industry. Specializing in SaaS evaluation, workflow automation, and B2B tool integration.