Self-Hosting n8n: What the Free Tier Limits

n8n Cloud stops every workflow the moment you cross the monthly execution cap — no warning, no grace period, no overage option, just silence until the next billing cycle. If a workflow already fires every five minutes, that's roughly 8,640 executions a month, enough to blow past the €24/month Starter plan's 2,500-execution limit in about nine days. The obvious next question is whether self-hosting it yourself is actually a downgrade, or just a different set of tradeoffs.

What self-hosting n8n actually gets you

The self-hosted Community Edition runs the same underlying software as n8n Cloud, free, with no cap on executions and access to the entire node/integration catalog. The tradeoff isn't the software — it's that infrastructure, uptime, backups, and updates become your responsibility instead of n8n's.

For anyone already running a homelab, that responsibility is smaller than it sounds. n8n is just another container that fits into the same layout used for everything else in the stack: Proxmox creates the VM, Docker runs inside it, and n8n is one more service in that Docker Compose file rather than a special case requiring its own infrastructure decisions.

What the Community edition genuinely doesn't include

Feature	Community (self-hosted)	Enterprise (Cloud or self-hosted)
SSO / LDAP	No — local accounts only	Yes
Environments (staging/prod separation)	No	Yes
External secrets management	No	Yes
Log streaming	No	Yes
Git-based version control	No	Yes
Multi-main mode (HA)	No	Yes
Executions	Unlimited	Plan-dependent

Every row above except the last one is a feature that matters mainly at team or organization scale — single-sign-on, environment separation, and workflow versioning solve coordination problems a solo homelab automation setup doesn't have. For one person automating their own infrastructure, the Community edition's gaps rarely bite; for a team of five sharing workflows, they do.

Running it: Docker Compose on a homelab box

Consistent with running Docker services inside a dedicated VM rather than directly on a Proxmox host, n8n and its database drop in as two services:

services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres
    restart: unless-stopped

  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  n8n_data:
  postgres_data:

A reverse proxy handling TLS (Caddy or Nginx) in front of this is not optional — webhook-triggered workflows, which are most of what makes n8n useful, need a real HTTPS endpoint to receive callbacks from external services.

What it actually costs in resources

n8n's official minimum is 1 vCPU and 2GB RAM, which is enough to boot it with SQLite in test mode but not much more. In practice, expect the container to idle around 300–500MB RAM and spike to 1–2GB during workflow runs that process larger payloads — a Code node handling a 100MB payload alone can temporarily hold roughly 300MB in memory. On the N100-class mini PC hardware this site's homelab guides already assume, 4GB of RAM is the realistic floor for running n8n reliably alongside a handful of other containers, not the bare 2GB minimum.

Whether that container belongs in a VM or an LXC container is the same question that comes up for every Docker workload on Proxmox — n8n has no special requirement here, so the general VM-vs-container tradeoffs apply unchanged: a VM costs a bit more RAM overhead but isolates n8n's kernel fully from the host, which matters more once webhook endpoints are exposed to the internet through a reverse proxy.

The kind of workflows that make this worth running

Three patterns cover most of what a homelab n8n instance ends up doing:

• Backup-failure alerts — a scheduled workflow pings a healthcheck endpoint on success; if the check-in doesn't arrive on schedule, a separate monitor fires a notification. Cheap insurance against a backup job that silently stopped running weeks ago.
• RSS-to-notification — watch an RSS feed node and forward new items to Discord, a chat app, or email, replacing a paid "if this then that" service with a self-hosted equivalent.
• Uptime checks — a scheduled HTTP request node pings self-hosted services on an interval and raises an alert on a failed response, a lightweight complement to a dedicated monitoring stack rather than a replacement for one.

None of these need Enterprise features — they're single-user, single-environment automations, which is exactly the workload Community edition is built for.

Self-hosted vs Cloud: the actual dollar math

Cloud's Starter plan runs about €24/month for 2,500 executions. A single workflow polling every 5 minutes generates roughly 8,640 executions a month on its own — enough to exhaust that cap in about 9 days even before adding a second workflow. Self-hosting removes the execution ceiling entirely; the only ongoing cost is hardware and electricity already sunk into a homelab box that's likely running other services anyway.

When self-hosting is the wrong call

If a team genuinely needs SSO tied to a company identity provider, separate staging/production environments, or Git-based review of workflow changes before they go live, Enterprise Cloud (or self-hosted Enterprise) is the correct tool, not a self-hosted Community instance stretched past what it's designed for. For a single person automating their own Proxmox homelab, that's a feature set that solves problems you don't have yet.

Frequently asked questions

Is self-hosted n8n really free?

The software is free under Community edition, with unlimited workflow executions. The only real cost is the server it runs on — for a homelab box already running other services, that's typically a marginal amount of shared RAM and electricity, not a new expense.

Do I need a domain and SSL to self-host n8n?

For webhook-triggered workflows, yes — external services need a real HTTPS endpoint to call back to. A reverse proxy like Caddy or Nginx handling TLS in front of n8n, as shown in the Compose example above, is the standard setup.

Can self-hosted n8n use all the same integrations as Cloud?

Yes. Community edition ships with the same node and integration catalog as Cloud. The features it's missing are account/team-management features (SSO, environments, external secrets), not integrations.

What features does n8n Community edition not have?

SSO/LDAP authentication, environments (staging/production separation), external secrets management, log streaming, multi-main high-availability mode, and Git-based version control are all Enterprise-only, per n8n's own documentation.