Best Self-Hosted n8n Alternatives for VPS Compared

Wetin to use instead of n8n

The self-hosted n8n alternatives wey worth your time for VPS (virtual private server) na Activepieces, Windmill, Node-RED, Automatisch and Huginn. Activepieces na the closest replacement for how most people dey use n8n, and e core get MIT license. Windmill fit team wey prefer to write Python or TypeScript instead of dragging boxes around canvas. Node-RED na the smaller one, and e no need database at all.

Plenty readers suppose remain where dem dey. The n8n license allow internal business use, so if you dey run flows for your own company, license no be your problem. Migration no free too. Nothing for this list fit read n8n export, so you go rebuild every flow by hand and enter every credential again. Installing n8n itself na separate job, wey this n8n install for VPS with Docker and HTTPS cover, and n8n against Zapier and Make explain how this whole category compare with hosted services.

Why people dey look for self-hosted n8n alternatives

Two reasons dey come up again and again.

The first one na licence. n8n dey release under Sustainable Use License v1.0, wey the project dey call fair-code instead of open source. The licence give you right to "use or modify the software only for your own internal business purposes or for non-commercial or personal use", but e no allow you provide the software commercially to other people. Files and folders wey get .ee for their name dey under separate n8n Enterprise License. If you wan run automations for paying clients, na hard stop be that. If you be internal operations team, e no change anything for your daily work. Licence and price na two different questions, and which n8n features need a paid key na the question to answer before you comot because of paywall wey you never actually reach.

The second one na memory. n8n na Node.js process, and workflow data dey memory while the run dey happen. n8n documentation list the causes: the amount of JSON data, the size of binary data, the number of nodes for workflow, the Code node, manual executions (wey copy the data again for the editor), and other workflows wey dey run at the same time. The documented fix no be another product. Na queue mode with separate worker processes, plus Postgres instead of the default SQLite file for ~/.n8n/database.sqlite. Large jobs also need batching, because Loop Over Items node wey dey feed sub-workflow keeps only one slice of the data for memory at one time. Try this one first before you rebuild sixty flows somewhere else.

Which self-hosted n8n alternatives still dey maintained

Licence text easy to read, so everybody dey compare licences. Project health easy to ignore. These na the 6 projects for this comparison, with the newest tagged release wey each one get on 11 October 2026.

[
  {
    "tool": "n8n",
    "licence": "Sustainable Use License",
    "latest_release": "2.42.6",
    "released": "2026-10-09",
    "days_since_release": 2
  },
  {
    "tool": "Activepieces",
    "licence": "MIT core, commercial ee",
    "latest_release": "0.92.2",
    "released": "2026-10-07",
    "days_since_release": 4
  },
  {
    "tool": "Windmill",
    "licence": "AGPLv3 source, CE image",
    "latest_release": "v1.830.0",
    "released": "2026-10-09",
    "days_since_release": 2
  },
  {
    "tool": "Node-RED",
    "licence": "Apache 2.0",
    "latest_release": "5.0.8",
    "released": "2026-10-08",
    "days_since_release": 3
  },
  {
    "tool": "Automatisch",
    "licence": "AGPL-3.0, commercial ee",
    "latest_release": "v0.15.0",
    "released": "2025-08-08",
    "days_since_release": 429
  },
  {
    "tool": "Huginn",
    "licence": "MIT",
    "latest_release": "v2026.10.04",
    "released": "2026-10-04",
    "days_since_release": 7
  }
]

One row dey change the shortlist. Automatisch last tagged v0.15.0, wey be 429 days old, and e default branch never get commit since 15 January 2026. Huginn bin be the second warning before. Its code dey still move even though e spend four years without release after v2022.08.18. This change on 27 August 2026, and e don cut several releases since then. The newest one na v2026.10.04, from 7 days ago.

Check this thing by yourself before you trust any comparison, including this one. Open the project releases page for GitHub, then open the commit list for its default branch. Project wey get fresh release but quiet commit log dey coast. Project wey get fresh commits but never get release for years dey ask you to run code wey nobody don cut version for.

Activepieces: na di closest match, and MIT dey for the core

Activepieces na the like-for-like choice. E be visual builder wey get triggers and steps, wey e dey call pieces, and the README claim say dem pass 280. Every piece dey also exposed as MCP (model context protocol) server, so LLM (large language model) client fit call the same connectors as tools. The core get MIT license. Two directories, packages/ee/ and packages/server/api/src/app/ee, get commercial license, and to use wetin dey inside dem for production on your own server need paid agreement. The same license allow you copy and modify that code for development and testing without subscription.

Read that separation before you migrate, because e wider pass wetin dey most MIT projects. The Activepieces pricing page describe Community Edition as "the automation core on its own". E say payment adds access control, change tracking, separation between teams and clients, safe releases, and Agents and Chat. The plan comparison list Projects, Releases and Git Sync, branding, single sign-on, audit logs and secret managers as paid-tier features. The commercial directory for the repository hold modules for agents, API keys, audit logs, secret managers and authentication. So Community Edition na complete automation engine without the team and governance layer. But generating flows programmatically no need license. Activepieces ships built-in MCP server wey get tools to create, duplicate, rename and publish flows, and add, update and delete steps and triggers (ap_create_flow, ap_build_flow, ap_add_step and others). Its code dey inside packages/server/api/src/app/mcp, outside both commercial directories, the MCP documentation no name any edition or plan requirement, and the pricing page list "MCPs and API access" for its $0 Free plan. The docs add say "MCP tools are free, except ap_run_action, which costs 1 credit per call". The API key module still dey inside the commercial directory.

The runtime setup na one app container, one or more worker containers, Postgres and Redis. AP_DB_TYPE=POSTGRES and AP_REDIS_TYPE=STANDALONE na the defaults. E get single-container mode with embedded database and in-process queue (AP_DB_TYPE=PGLITE with AP_REDIS_TYPE=MEMORY), and the documentation describe am as "for personal use on one machine". Take this statement as e be. The in-memory queue support one instance for one machine, so to grow beyond am na migration, no be flag.

Windmill: code first, and e heavy pass wetin e look

Windmill dey run scripts for Python, TypeScript, Go, Bash and SQL, then e join dem together into flows. If na mostly code dey make up your automations, with small glue around dem, e fit you pass any node canvas.

You need handle the licence carefully. The source na AGPLv3 when you compile am without the enterprise feature flag. The images wey dem publish for ghcr.io/windmill-labs/windmill na Community Edition. E include code wey no be open source, and you fit use am free inside the quotas. Windmill pricing page set the quotas at 50 users, 3 workspaces and 10 GiB of workspace object storage, with unlimited executions. For one person or one small team, that limit still far. So the practical question no be the quota. Na say the binary wey you run no be the AGPL build.

Weight na another thing to consider. Windmill own docker-compose.yml dey ship with Postgres 18 database, one server, three default workers with 2048M memory limit each, one native worker and one Caddy proxy. The documented rule of thumb na "1 worker per 1vCPU and 1-2 GB RAM". You fit reduce the replica count for small box. But know say na you dey reduce am, because na the workers dey actually run your jobs.

Windmill AI features come for two kinds. The first one na help while you dey build: code generation, flow building, chat and form filling. First, you need add a model provider resource for workspace settings. The second one na AI agent steps, wey dey run inside flows. Dem fit call inline, workspace and Hub scripts or MCP servers as tools, and dem work with providers including OpenAI, Anthropic, Mistral and Google AI. So if you want one agent step wey go run on schedule and call tools, Windmill fit do am just like n8n AI Agent node. Build one AI agent for n8n dey cover the n8n version.

Node-RED: di lightweight one, wey no get database at all

Node-RED dey under Apache 2.0, na permissive licence wey no get copyleft. MIT licence wey Huginn and Activepieces core dey use ask even less from you. Na one Node.js process wey get a /data volume. No Postgres. No Redis. Pin am as nodered/node-red:5.0.8, wey be the current release as of 11 October 2026.

E start from IoT (internet of things) wiring, so e dey arranged around events instead of connectors. Nodes for third-party services dey come from community library, and their quality no dey the same. Na this trade-off you accept for the small footprint. E no get first-class AI agent step. For small VPS wey dey handle webhooks and message-queue traffic, na the lightest option here wey dey work, and e fit start within seconds.

Huginn and Automatisch: first check the commit log

Huginn na MIT software, dem write am for Ruby on Rails, and e need MySQL or PostgreSQL. E dey use agents wey dey watch source and send events, and this model different from flow canvas. E LLM support recent. Dem add OpenAI LLM Agent for March 2026. E dey send one chat completion for each event go any OpenAI-compatible API, including Ollama. Then e dey send the reply as new event. Other related agents fit generate images, speech and video. None of dem dey call tools, so treat dem as text steps, no be agent loop. After four years without tagged release, e don publish several releases since August 2026, starting with security releases. The ghcr.io/huginn/huginn registry now get release tags like v2026.10.04 together with the latest and commit tags. Pin release tag instead of running anything wey default branch build last. Choose am when the agent model match your problem, no be as general replacement for n8n.

Automatisch na AGPL-3.0 apart from its .ee files, and e look like simpler n8n: Postgres, Redis, and small catalogue of apps. Na the tool wey single-deploy tutorials dey recommend often. The release history say make you wait. More than one year without release and almost one year without commit no be reason to panic if you already dey run am. But e be reason not to start new production deployment with am.

Wetin Activepieces stack really cost for RAM

Nobody fit publish the exact idle and working memory figure for you, because e depend on your own flows and how much data dem carry. Wetin you fit read na the amount each vendor tell you to budget. Activepieces document the setup below, and the sentence beside am matter pass the numbers: "A concurrency-1 worker dey busy for the whole duration of a flow (up to 10 min), so size by concurrent flows, no be trigger rate."

[
  {
    "label": "App container",
    "vcpu": 1,
    "ram_gb": 1
  },
  {
    "label": "Worker (each)",
    "vcpu": 0.5,
    "ram_gb": 1
  },
  {
    "label": "Postgres",
    "vcpu": 2,
    "ram_gb": 4
  },
  {
    "label": "Redis",
    "vcpu": 1,
    "ram_gb": 1
  }
]

One worker na 0.5 vCPU and 1 GB. E run exactly one flow at a time when AP_WORKER_CONCURRENCY=1, the setting wey the documentation recommend. The shipped default na 5, wey dey run several flows inside one container, and for that case the docs say make you give each worker about five times the memory. Postgres get 4 GB. The project's own compose file ship five worker replicas, so even for concurrency 1, the stack for the repository dey ask for roughly 11 GB before your flows do anything serious. Tutorials wey cover only one tool dey copy that file and call am small deployment.

For 4 GB VPS, run two workers for concurrency 1, keep Postgres for the same compose project, and measure am. docker stats --no-stream dey print one line for each container with its real resident memory, and that better pass any figure wey vendor or blog publish. If container dey grow without limit, cap am, and memory limits for Docker Compose show the syntax.

A compose file for Activepieces on one VPS

Tag pin am important. latest mean the next docker compose pull fit change the database schema under you without warning. Version 0.92.2 na the version wey the project pin for its own compose file as of 11 October 2026.

Generate the two secrets first, using the lengths wey the documentation specify.

openssl rand -hex 16    # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32    # AP_JWT_SECRET, signs session tokens

Write .env beside the compose file:

AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_WORKER_CONCURRENCY=1
AP_TELEMETRY_ENABLED=false

AP_FRONTEND_URL must be the public HTTPS address, because Activepieces otherwise go try use your public IP address when e dey build webhook URLs. Every webhook wey you give third party dey build from that value, so if e still point to localhost, the URL wey you paste into another service no go reach your server. AP_WORKER_CONCURRENCY=1 limit each worker to one flow, so the sizing above still hold.

services:
  app:
    image: ghcr.io/activepieces/activepieces:0.92.2
    restart: unless-stopped
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - postgres
      - redis
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=APP
    volumes:
      - ./cache:/usr/src/app/cache
  worker:
    image: ghcr.io/activepieces/activepieces:0.92.2
    restart: unless-stopped
    depends_on:
      - app
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=WORKER
    deploy:
      replicas: 2
    volumes:
      - ./cache:/usr/src/app/cache
  postgres:
    image: pgvector/pgvector:0.8.0-pg14
    restart: unless-stopped
    env_file: .env
    environment:
      - POSTGRES_DB=${AP_POSTGRES_DATABASE}
      - POSTGRES_USER=${AP_POSTGRES_USERNAME}
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7.0.7
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

That file na the project's own compose with four changes: worker count drop from five to two, the published port dey bind to 127.0.0.1 instead of every interface, the fixed container names don comot because service wey get replicas no fit use dem, and the explicit network block don comot because compose dey create one anyway.

docker compose up -d
docker compose ps

Every service suppose show Up, including two worker containers. Container wey dey restart in a loop go print the reason inside docker compose logs worker, so read am before you change anything. The port binding mean say nothing fit reach the app from outside until you put reverse proxy with TLS (transport layer security) in front. Running Traefik in front of several compose apps explain this. Keep .env for mode 600 and comot am from git, as e dey for Handling secrets in compose env files.

The backup wey every guide dey leave out

All these tools dey encrypt credentials wey dem store, so database dump by itself no be backup. You need the dump and the key wey go decrypt am. The trap be say most of these tools dey generate that key for you quietly, then store am for somewhere wey you no dey back up.

n8n na the clearest example. If you never set N8N_ENCRYPTION_KEY, n8n "dey create one random encryption key automatically for the first launch and save am inside the ~/.n8n folder", then e dey use that key encrypt credentials before dem enter the database. Dump Postgres, restore am into fresh container with fresh volume, and the workflows go come back, but every credential go be ciphertext wey nobody fit read. n8n own backup guide cover this matter. E tell you make you back up the .n8n folder even when you dey use PostgreSQL, because "the folder hold the config file, and that file store the credential encryption key." Set the variable explicitly, and use the same value for every worker when you run queue mode.

Node-RED get the same arrangement. Credentials dey inside their own encrypted file, and the key na credentialSecret for settings.js. When you no set one, the runtime go generate random key and save am under _credentialSecret inside its own settings store for /data. The default settings file explain the consequence: "once you set this property, no change am again - if you change am, node-red no go fit decrypt your existing credentials and dem go lost." Back up the whole /data volume, no be only the flows file.

Activepieces dey keep AP_ENCRYPTION_KEY inside your .env, and documentation describe am as a "32-character (16-byte) hexadecimal key used to encrypt connections". Huginn dey keep APP_SECRET_TOKEN inside its environment. Automatisch get three of them: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY and APP_SECRET_KEY. For each case, the secret dey inside an environment file, so that environment file na part of the backup.

Windmill na the exception wey you need know. Its secrets dey encrypted with workspace-specific symmetric key wey Windmill dey store inside its own database, so one Postgres dump carry both parts. This make restore easier, but e also mean say the dump alone enough to read every secret. Protect the file as if na the secrets themselves.

For the Activepieces stack above, the backup na two files:

cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bak

Then prove say the backup dey work, because backup wey you never test na just guess. Restore the dump into scratch compose project wey dey use deliberately different AP_ENCRYPTION_KEY, then run one flow wey dey use saved connection. E go fail, because the ciphertext inside the database come from the other key. Repeat the restore with the real key from .env, and the same flow go run. Those two runs na the only evidence say your backup really be backup. Send both files away from the server on a schedule with restic backups from a VPS, because backup wey dey on the same disk go die together with the disk.

When you suppose remain on n8n

Remain if the work dey inside your own company, because na exactly wetin Sustainable Use License allow. Remain if you depend on wide range of integrations, since n8n integrations directory list more than 2,000 integrations, or if you use the AI Agent node wey build on LangChain. Among the free self-hosted builds for here, Windmill and Huginn both come with ready-made AI steps, but na only Windmill agent steps dey call tools. Huginn OpenAI agents dey send prompt and produce the result, but dem no dey call any tool. How to drive n8n workflows with Claude show how e dey work for practice.

Move go Activepieces if you want permissive licence for the automation core and stack wey you fit read from beginning to end. Move go Windmill if your flows na really code wey just wear user interface. Move go Node-RED if the box small and the work dey based on events. No move because benchmark tell you say n8n heavy. Measure your own instance first, then read wetin worth self-hosting for 2026 and choose once, because the second migration cost as much as the first one.

FAQ

Which self-hosted n8n alternative dey closest to n8n?

Activepieces. Na the same idea: visual builder wey trigger dey start flow, and every step dey call service, with plenty connectors for catalogue. Its core get MIT licence, e dey run on Postgres and Redis under Docker, and its pieces fit also work as MCP servers for LLM clients. The main gap wey you need watch be say API keys and the agent module dey inside commercial enterprise directories. The built-in MCP server no dey there, so assistant still fit create and edit flows for Community Edition instance without licence.

Activepieces really be open source?

The core be open source under MIT licence. Two directories, packages/ee/ and packages/server/api/src/app/ee, get commercial licence. If you wan use those features for production on your own server, you need paid licence, although you fit copy and modify the code for development and testing without subscription. The vendor pricing page call Community Edition "the automation core on its own" and talk say payment adds Agents and Chat. Its plan list put Projects, single sign-on, audit logs, secret managers, branding and Git sync for paid tiers, while "MCPs and API access" dey for the $0 Free plan. So e genuinely be open source for building and running automations, but e no be open source for team and governance layer.

How much RAM Activepieces need for VPS?

Activepieces document 0.5 vCPU and 1 GB for each worker, 1 vCPU and 1 GB for app container, 4 GB for Postgres and 1 GB for Redis. The worker figure assume AP_WORKER_CONCURRENCY=1. For that setting, one worker handle one flow at a time for the full duration of that flow, so you size based on peak concurrent flows, no be how often triggers dey fire. The default wey ship with am na 5 concurrent flows per worker, and that need about five times the memory per worker. The compose file for the repository ship five workers, wey be around 11 GB of published sizing even for concurrency 1. Two workers at concurrency 1 for 4 GB VPS na reasonable start, and docker stats --no-stream go confirm the real number for your flows while dem dey run.

Wetin I need back up so restore go actually work?

The database dump and the encryption key, both together. For Activepieces, na a pg_dump of the activepieces database plus the .env file wey dey hold AP_ENCRYPTION_KEY. For n8n, na the database plus N8N_ENCRYPTION_KEY, wey n8n generate inside the ~/.n8n folder if you never set am. For Node-RED, back up the whole /data volume, because the credentials file and the key wey decrypt am both dey there. Windmill na the exception: its workspace key dey inside its own Postgres database, so the dump carry everything and you must protect am as if na the secrets themselves.

I fit import my n8n workflows into another tool?

No. These projects import and export their own flow formats, not n8n format. Migration mean say you go rebuild each flow for the new builder and create each credential again from the original service. That work na the real cost of switching, so count your flows before you decide. Twelve flows na afternoon work. Two hundred flows na project, and e usually cheaper to fix n8n memory use with queue mode and Postgres than to rebuild everything.