Kestra vs n8n

Kestra and n8n share the Workflow automation hub and almost nothing else. Kestra calls itself "an open-source, event-driven orchestration platform for data, AI, and infrastructure workflows": flows are YAML files run by a Java server beside PostgreSQL, the shape of a data-engineering scheduler. n8n is a "Fair-code platform to build and deploy AI agents and workflows" where you "Combine a visual canvas with custom code" and "connect to 1500+ integrations", the shape of a Zapier replacement. Licence, install and footprint all follow that split.

What each one orchestrates

Kestra's unit is the flow: "A flow is a container for tasks and their orchestration logic." A flow needs an id, a namespace and a list of tasks; around them sit triggers, "schedule or event conditions that start executions automatically", inputs, "typed parameters passed at execution time", and outputs, "values or files a flow produces for downstream use". The README promises "hundreds of plugins built in to extract data from any database, cloud storage, or API". The jobs it describes are pipelines: move data, run a script in a container, wait on a file in a bucket, fan out to the next flow when this one finishes.

n8n's unit is the workflow on a canvas, and its nodes are applications. The README leads with its integration catalogue and template library "to connect AI with your existing systems"; code is the garnish ("Combine visual building with JavaScript, Python, and npm packages"). The jobs it describes are glue: a form submission becomes a CRM row and a chat message, a webhook fans out to three SaaS APIs, an AI node sits in the middle.

How you build and trigger

In Kestra, "Flows are defined declaratively in YAML or built using the No Code editor." The YAML is the source of truth either way; the editor writes it. "A trigger starts a flow automatically, either on a schedule or in response to an event", and the six core types are Schedule, Flow, Webhook, Polling, Realtime and MCP Tool, with plugin triggers for S3, SQS, Kafka and a PostgreSQL query among the examples. The Flow trigger is the data-engineering tell: it "runs a flow when one or more upstream flows complete in a matching state", so dependencies between pipelines are a first-class trigger, not a node you wire by hand.

In n8n you drag nodes onto a canvas and connect them; the integration is the node. Where the catalogue runs out, the Code node lets you "write custom JavaScript or Python and run it as a step in your workflow"; our n8n page covers the task-runner setup that isolates those scripts from your credentials.

Scaling and the backend

Kestra is six server roles: Webserver, Executor, Worker Controller, Worker, Scheduler and Indexer. The compose install runs them as one server standalone process, "with all architectural components running in one JVM", but "Server components can run independently from each other" when you want to split them. They coordinate through the backend: "JDBC (default) — backed by any supported relational database (PostgreSQL, MySQL). Available in all editions", while "Kafka — Enterprise Edition. Pairs with Elasticsearch for the search and read model." Open source, then, means a relational database, PostgreSQL or MySQL, as both repository and queue.

n8n starts as one process, and "By default, n8n uses SQLite to save credentials, past executions, and workflows. n8n also supports PostgresDB." To grow, you switch to queue mode, which "provides the best scalability": "Workers are n8n instances that do the actual work", "Redis acts as the message broker, and the database persists data, so access to both is required", and SQLite "isn't supported" for it. Queue mode is absent from the Community edition's list of held-back features; multi-main mode is Enterprise.

Licences and the paid edition

Kestra's repository LICENSE is Apache 2.0, and the architecture page describes the paid tier as "an additive overlay on the open-source core — not a fork" in which "All open-source behavior is preserved"; that Enterprise Edition is a separate image pulled from Kestra's private registry. The pricing page's Open Source card promises "Unlimited Flows & Executions"; the Enterprise card holds "SSO, LDAP & SCIM", "Role-Based Access Control", "Policies", "Audit Logs & Cases", "Multi-Tenant & Storage Isolation", "Worker Groups", "Secrets Manager" and the "Queue: Postgres, MySQL, Kafka, Redis, AMQP" options. A single team on one instance gets the whole engine; a company that needs roles or tenants pays.

n8n is "fair-code distributed under the Sustainable Use License and n8n Enterprise License". The licence's Limitations are short: "You may use or modify the software only for your own internal business purposes or for non-commercial or personal use", and "You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes." Files whose names contain .ee. "are NOT licensed under" it and need "a valid n8n Enterprise License". The Community edition "includes almost the complete feature set of n8n" minus custom variables, environments, external secrets, external binary storage, log streaming, multi-main mode, projects, SSO, sharing and Git version control. Running n8n for yourself is permitted; selling access to your instance is not, the line Windmill vs n8n keeps coming back to.

Footprint and setup

Kestra is the heavy one, by design and by measurement. Upstream states that "Kestra requires at least 2 vCPUs and 4 GiB of memory to run correctly", which is the 4 GB documented floor on our Kestra page. Our snippet is upstream's compose file with the image pinned to v2.0.6 and the database password generated: a server standalone container beside PostgreSQL, with the Docker socket mounted so script tasks can run containers, and the management port left unexposed because upstream says it "is unauthenticated and intended for internal use only". In our install check (GCP e2-standard-2, Ubuntu 26.04, October 2026), Kestra idled at ~1.2 GB of RAM and ~8.3 GB of disk; the pinned image bundles every plugin (the -slim tag ships none). n8n publishes no RAM minimum; the 1 GB on our n8n page is our estimate. Its install is one container with SQLite under /home/node/.n8n; in our check (GCP e2-standard-2, Ubuntu 26.04, September 2026) it idled at ~396 MB of RAM and ~1.7 GB of disk. Both are plain HTTP on 8080 and 5678, so a reverse proxy with TLS comes first; Kestra's sample also leaves basic-auth unconfigured, so turn it on before the port faces the internet, where n8n asks you to create an owner account on first visit. We rate both 3 out of 5.

Which to choose

Choose Kestra if your automations are pipelines: scheduled and event-driven flows declared in YAML, dependencies between flows as triggers, scripts in any language, and an Apache-2.0 core you can split into services over PostgreSQL, on a box with the 4 GB upstream requires.

Choose n8n if your automations are glue between applications: a visual canvas of integration nodes, a Code node for the gaps, and one container that idled under 400 MB, under a Sustainable Use License that permits internal and personal use but not selling access to your instance.

Running Kestra or n8n on a VPS

Both installs are verified on Ubuntu 26.04; the compose file and the single docker run are on the Kestra and n8n pages, with the caveats that matter: Kestra's root user, which upstream marks "meant for development only", and its Docker socket mount, and n8n's encryption key and task-runner mode. Size the server for Kestra's 4 GB floor if that is the pick; n8n fits the smallest plan most providers sell. If the real question is code-first scripts versus a visual builder, see Windmill vs n8n, linked above.