STaurtomation/docs/research/notes/kestra.md

Ported from earlier research (2026-10-29) and sanitized for clean-room use: source-code-derived details removed. Not legal advice.

Kestra as a self-hosted n8n alternative (as of late October 2026)

Research date: 2026-10-29. The current major version is Kestra 2.0, released 8 Sep 2026; the latest patch is v2.0.8 (27 Oct). Anything that describes 1.x is marked as older.

1. License (open-source core, proprietary parts, license changes)

Takeaway

The open-source core (kestra-io/kestra) is Apache-2.0. Enterprise features are closed-source proprietary code (separate Enterprise plugins) sold under a commercial subscription. I found no evidence of a license change in 2023-2026, unlike n8n's Sustainable Use License.

Cited Findings

• The GitHub repo license is Apache-2.0 (30.1k stars, 3.5k forks, about 13,446 commits on the develop branch) — GitHub kestra-io/kestra
• The open-source edition is free under Apache 2.0. Enterprise Edition is an annual per-instance subscription with custom pricing — automationatlas.io pricing explainer; kestra.io/pricing
• EE features ship as separate Enterprise plugins (for example an Enterprise Git plugin). In 2.0, Git dashboard tasks (SyncDashboards/PushDashboards) moved from the OSS Git plugin to the EE Git plugin, and dashboards moved to EE — Kestra 2.0 migration guide; Kestra 2.0 release blog

Inferences

• The model is open-core: an Apache-2.0 core plus proprietary EE add-ons. Nothing I found suggests a "source-available" middle tier like n8n's source-available enterprise code. The EE code does not appear in the public repo.
• Moving dashboards to EE in 2.0 means features can migrate from OSS to paid between majors. That is a mild "open-core creep" risk to keep in mind, even though the license itself has not changed.

Gaps

• I did not find an official statement ruling out past license changes. The "no change" conclusion rests on the repo being Apache-2.0 today and no search results reporting a change.
• I did not verify the exact license text of the EE plugins (EULA or commercial terms).

2. Free vs paid editions and pricing

Takeaway

There are three editions. Open Source is free. Enterprise Edition is self-hosted, priced per instance, with unlimited flows, tasks and executions and no public price. Kestra Cloud is managed and usage-based, with no public price; it was in early or request access through at least mid-2026.

Cited Findings

• Pricing page: Open Source costs 0 USD. Enterprise is "Per instance model, unlimited flows/tasks/executions" (contact sales). Cloud is "pay only for what you use", with no fixed price shown — kestra.io/pricing
• As of July 2026, Kestra Cloud was described as early access with usage-based pricing and no published dollar prices. Another listing (verified March 2026) says "Contact sales". The sources conflict on access mode — automationatlas.io; toolradar
• The Series A funds (March 2026) were earmarked for Kestra 2.0, the Kestra Cloud rollout, and North America and Europe expansion — raising.fi; Axios Pro

Inferences

• EE pricing is per instance rather than per user or per execution, so the cost doesn't grow with user count. Without public numbers, it is likely aimed at mid-market and enterprise budgets (inference only).

Gaps

• No public price exists for EE or Cloud. No source reported a small-team or startup tier.

3. Feature gating (the features the user cares about)

Takeaway

Almost every governance feature on the user's list is EE/Cloud-only: SSO, LDAP, SCIM, RBAC, multiple users, multi-tenancy, audit logs, log shippers, external secrets managers, worker groups, and environment promotion. OSS keeps Git sync tasks, namespaces, execution purge tasks, flow revisions, and the ability to run as a distributed cluster. OSS authentication is a single shared Basic Auth account.

Cited Findings (gating table; OSS = open source, EE = Enterprise and Cloud)

• SSO (OIDC), LDAP, SCIM: EE only. The docs say SSO is "via OpenID Connect (OIDC) or LDAP". SCIM syncs users and groups. 2.0 adds an LDAP group-sync-only mode (EE) — docs: OSS vs paid; pricing; 2.0 blog
  • SAML: these pages mention only OIDC and LDAP. A third-party listing mentions "SSO / SAML" for Cloud — toolradar. Treat SAML support as unverified.
• Multi-user and number of users: OSS has "one shared Basic Authentication account". EE has individual accounts through invitations, plus SCIM — docs: OSS vs paid
• RBAC: EE only. In 2.0, RBAC moved from CRUD to 159 per-action permissions with five managed role presets (Viewer, Launcher, Editor, Developer, Admin), scoped per namespace and assignable to users, groups and service accounts — 2.0 blog; pricing
• Namespaces / tenants / teams: Namespaces are a core concept and exist in OSS. Multi-tenancy, with isolated tenants and per-tenant secrets and storage, is EE. Per-namespace governance of secrets, variables and files is EE — docs: OSS vs paid; pricing
• Audit logs: EE only ("Record every action by every user on every resource"). In 2.0, the Audit Log Shipper can send Syslog CEF events over TCP, UDP or TLS — pricing; 2.0 blog
• Log streaming / log shippers: EE only. The Log Shipper sends logs to Datadog, Splunk, Elasticsearch and others, plus a CEF syslog exporter in 2.0. The External Log Data Store (route logs to a separate JDBC DB or Elasticsearch) is also EE — pricing; docs: OSS vs paid; 2.0 blog
• Execution data retention and purge: OSS has core tasks PurgeExecutions, PurgeLogs and PurgeKV. You schedule them as flows with a date cutoff such as endDate: now() | dateAdd(-1,'MONTHS'), filter by state, and select which data to delete. They replace the legacy storage.Purge. PurgeStorage (orphaned files, dry run by default) arrived in 2.0 for OSS, EE and Cloud. There is no built-in retention setting; retention is done by flows — admin guide: purge; PurgeExecutions plugin; best practices: purging; 2.0 blog
  • 2.0 also adds Quotas, which limit executions per flow, namespace or tenant in a time window. The edition was not stated — 2.0 blog
• Multiple environments: EE-native. Promote (new in 2.0, EE/Cloud) moves flows between environments with diffs, protected-target confirmation, drift status and audit history, and needs no Git. In OSS you build environments yourself: separate instances, or namespace naming (e.g. dev.*, prod.*) plus Git sync — 2.0 blog; docs: git
• Git version control: OSS includes SyncFlows, PushFlows, SyncNamespaceFiles, PushNamespaceFiles, Clone, and TenantSync/NamespaceSync (bidirectional via sourceOfTruth). These run as Kestra flows triggered by schedule or webhook. EE-only: Promote, PushBlueprints/SyncBlueprints, SyncApps, SyncUnitTests, SyncDashboards, and auto-creating namespaces. The pricing page lists "Git integration and versioning" in both editions — docs: git; pricing
  • Caveat: the docs page doesn't explicitly label the first four as OSS. The OSS status is an inference from the missing EE label, consistent with the pricing page.
• External secrets managers: EE/Cloud only ("Available on: Enterprise Edition and Cloud"). Supported: AWS Secrets Manager, AWS SSM Parameter Store, Azure Key Vault, Google Secret Manager, HashiCorp Vault, CyberArk, Doppler, 1Password, BeyondTrust, Delinea, and Bitwarden. Read-only mode is supported and can be set globally, per tenant or per namespace. In OSS, secrets are supplied as (base64) environment variables — docs: secrets manager; docs: OSS vs paid
• Workflow versioning and history: Flows have revisions in the core product. 2.0 adds draft revisions: drafts never run, and triggers use the last published revision (edition not stated). Plugin versioning (pinning plugin versions per task, flow, namespace or instance) is EE, introduced in 0.22 (older) — 2.0 blog; 0.22 release blog; docs: OSS vs paid
• HA, workers and scaling: OSS can run as a standalone server or a distributed cluster with separate components. EE adds Worker Groups (tag-based routing with workerSelector.tags and capacity reservation), tenant-restricted capacity, Maintenance Mode, and cloud VM task runners (EC2, Azure VM, GCE). In 2.0 every worker connects outbound over gRPC and needs no DB access — docs: OSS vs paid; 2.0 blog
• Other EE-only extras: Apps (forms, approvals and dashboards on top of flows), Policies (namespace rules that replace pluginDefaults), Cases (incident management), Reusable Inputs, asset locking, and the agentic AI Copilot — pricing; 2.0 blog

Inferences

• For a multi-user team that needs any access control, OSS Kestra is effectively single-tenant and single-credential, so you would need EE. Even n8n's free Community edition has per-user accounts, so on user management OSS Kestra is more restrictive than n8n Community.
• OSS Kestra is stronger than n8n Community on Git sync and execution purge, which are free in Kestra, and on horizontal scaling.

Gaps

• I could not confirm whether OSS flow revision history is fully visible and restorable in the UI in 2.0, though it was in 1.x from my background knowledge (unverified here).
• SAML support was not confirmed from official docs.
• The edition gating of Quotas and draft revisions was not stated.

4. Product model (definition, editor, users, triggers, integrations, AI)

Takeaway

Kestra is a declarative, YAML-first, event-driven orchestration platform. Its roots and audience are data engineering and platform teams, and it now also markets for infrastructure and AI workflows. A no-code form editor, the YAML editor and the AI Copilot all edit the same flow. There is no free-form node canvas like n8n's; the topology view is mostly for visualization.

Cited Findings

• The project describes itself as "Orchestrate everything, everywhere": an event-driven platform for data, AI and infrastructure workflows, with flows declared in YAML. The YAML editor, no-code editor and AI Copilot all edit the same flow — GitHub
• In 2.0 the no-code editor is form-based with a contextual data panel, kept in sync with YAML and Copilot (OSS, EE, Cloud) — 2.0 blog
• Triggers: schedules, events and webhooks, plus flow triggers (dependsOn with a window) and a single Pebble when expression in 2.0 that replaces conditions — GitHub; 2.0 blog
• Integrations: the plugins page claims "2,400+ plugins". A March 2026 press article said "more than 1,200 plugins". The jump probably reflects counting method or growth — kestra.io/plugins; The Next Web
• AI: the MCP Server and MCP Tool Trigger expose flows as tools to Claude Desktop, Claude Code, Cursor and Codex (OSS, EE, Cloud). Additional MCP servers are EE. AI Agent tasks gain guardrails and metrics. The AI Copilot with Ask, Edit and Plan modes and memory is EE/Cloud (on any LLM). The pricing page lists an OSS "AI Copilot (Gemini)" and AI Agents — 2.0 blog; pricing
• Positioning versus n8n: Kestra is for engineering teams that want declarative, infrastructure-as-code orchestration. Business and app-centric automation is "usually easier in n8n" because of its app canvas — openalternative.co; ZoomInfo comparison
• Other: unit tests for flows (in 2.0, expectedState assertions), the Loop task that replaces ForEach and ForEachItem, a VS Code extension, and OpenTelemetry trace propagation — 2.0 blog

Inferences

• Kestra's plugin catalog leans toward data, cloud and infrastructure (databases, warehouses, dbt, cloud services, VMware/Nutanix). It has comparatively fewer SaaS-app connectors (CRM, marketing) than n8n. This comes from the plugin positioning and the infrastructure plugin lists, not from a full catalog audit.
• The 2,400+ figure likely counts individual tasks and triggers rather than distinct services, so it is not directly comparable to n8n's node count.

Gaps

• I did not get a count of distinct SaaS services or apps.

5. Tech stack and operations

Takeaway

Kestra is Java (JVM, Gradle, Micronaut-based from background knowledge) with a Vue.js UI. The minimal production setup is one PostgreSQL instance as both queue and repository, plus local or S3-compatible storage. Kafka, Redis or AMQP can act as the queue for scale. 2.0 removed the Kafka Streams engine, and Elasticsearch is now an EE external log store. It is deployed with Docker Compose or Helm.

Cited Findings

• The repo is tagged java and uses Gradle — GitHub
• 2.0 architecture: the control plane (Executor, Worker Controller, Scheduler, Webserver, Indexer) is separate from the data plane (Workers). Workers open one outbound gRPC stream with optional TLS, mTLS or JWT and need no database connection. Queue and repository are decoupled. Recommended start: a single PostgreSQL instance as queue and repository, with the option to move the queue to Kafka, Redis or AMQP. The Kafka Streams engine was removed — 2.0 blog
• Elasticsearch and JDBC (H2, PostgreSQL, MySQL) can serve as the EE External Log Data Store — 2.0 blog
• The official Docker Compose runs Kestra plus postgres with repository: type: postgres and queue: type: postgres, local storage at /app/storage, and an S3 / SeaweedFS (minio type) option. It starts a standalone server with "all architectural components running in one JVM". The docs give no CPU or RAM minimums — docs: docker compose
• The Helm chart (EE) exposes gRPC port 50051 by default and adds a controller deployment in 2.0 — migration guide
• *-slim images ship with no plugins. KESTRA_PLUGINS_AUTO_INSTALL_ENABLED=true pulls referenced plugins from Maven Central on first use — 2.0 blog
• Footprint criticism: "Java-based engine has heavier baseline resource footprint than lightweight Python schedulers" (third-party review) — aitoolsatlas pros/cons
• Upgrade burden: 2.0 requires being on the latest 1.3.x first. OSS migrations run automatically, while EE needs manual kestra migrate plan/run. The BasicAuth password rehash can't be rolled back. There are many breaking DSL changes (ForEach removed, conditions replaced by when, pluginDefaults removed, json() replaced by fromJson(), Parallel/Dag fail-fast default) — migration guide

Inferences

• For small self-hosting, a Kestra plus Postgres compose stack is about as simple as n8n plus Postgres. The JVM probably means a higher idle RAM baseline (likely 1-2 GB+, unverified) than n8n's Node.js process.
• Before 2.0 (older info), large deployments used the EE Kafka plus Elasticsearch backend. 2.0 simplifies this considerably.

Gaps

• No official minimum CPU or RAM figures were found.
• The MySQL repository status in 2.0 OSS was not confirmed; the docs only mention it for the log store and secrets backend.

6. Community health

Takeaway

Community health is strong and well funded. The repo has about 30.1k GitHub stars, weekly patch releases on two maintained lines (2.0.x LTS and 1.3.x), and a $25M Series A (Mar 2026, about $36M raised in total). Its community is much smaller than n8n's.

Cited Findings

• 30.1k stars, 3.5k forks, 169 watchers, about 13.4k commits. The contributor count was not shown on the page — GitHub
• Release cadence: roughly weekly. v2.0.4 (29 Sep), v2.0.5 (5 Oct), v2.0.6 (13 Oct), v2.0.7 (20 Oct), v2.0.8 (27 Oct), each shipped alongside a 1.3.x patch (v1.3.41 to v1.3.45) — GitHub releases
• 2.0 is an LTS release with one year of backported fixes. Launch post dated 8 Sep 2026 — 2.0 blog; web search summary of Anna Geller's LinkedIn
• Funding: $25M Series A on 31 Mar 2026, led by RTP Global with Alven, ISAI and Axeleo, about $36M total. Earlier: an $8M seed led by Alven (Sep 2024). Tech.eu lists €22M / €29M total, which is a currency or conversion discrepancy — The Next Web; Alven; tech.eu
• Traction claims (vendor): enterprise revenue up 25x in 18 months, over 2B workflows executed in 2025, and Apple engineers among its users — The Next Web; Pulse 2.0
• Older snapshot comparison: n8n had about 184.8k stars versus Kestra's about 26.7k — openalternative.co
• The company is French; the CTO built the precursor at the game publisher Ankama for distributed cron jobs — Pulse 2.0 interview

Inferences

• Funding and LTS commitments suggest low abandonment risk. The commercial incentive to push governance into EE will remain.

Gaps

• The exact contributor count is unknown; the GitHub page didn't render it.

7. Migration from n8n

Takeaway

There is no n8n importer. Kestra publishes a migration guide for Pipedream but none for n8n. n8n workflows would need a manual rewrite into YAML flows. Code nodes port to script tasks fairly directly, while the many SaaS nodes need equivalent plugins or HTTP Request tasks.

Cited Findings

• No n8n-specific migration path was found. Kestra's Pipedream migration page says "Node.js, Python and Bash steps copy into script tasks; what changes is how they read their input and return their results" — Kestra: migrate from Pipedream
• Comparison sites contrast n8n's visual canvas for app-centric automation with Kestra's declarative, engineering-oriented model — openalternative.co; ZoomInfo

Inferences

• Concept mapping: n8n workflow maps to a Kestra flow (in a namespace), n8n trigger node to a trigger (Schedule, Webhook, polling or realtime trigger), n8n node to a task, n8n credentials to secrets, n8n expressions to Pebble expressions, and n8n sub-workflow to a Subflow task. The mapping is conceptually clean, but data passing differs: Kestra uses explicit outputs and {{ outputs.task.x }} instead of item arrays flowing between nodes.
• Effort: moderate to high for SaaS-heavy n8n workflows, lower for code and API-heavy ones. An LLM could help convert n8n JSON to Kestra YAML, but that is untested.

Gaps

• No community-built n8n-to-Kestra converter was found.

8. Known limitations and criticisms

Takeaway

Independent criticism is thin; I found no substantive Reddit or HN threads. The recurring points are: governance is paywalled with an unpublished EE price, the JVM has a heavier footprint, the plugin ecosystem is smaller than Airflow's, YAML has a learning curve, and the 1.x to 2.0 upgrade breaks things. For n8n users specifically, the bigger issues are the lack of a canvas-style editor and fewer business-SaaS connectors.

Cited Findings

• Third-party pros and cons list heavier Java footprint, unpublished enterprise pricing that "requires a sales conversation for RBAC/audit features", a smaller ecosystem than Airflow (some providers need custom plugins), and a learning curve for Airflow users. Verdict 5.5/10 — aitoolsatlas pros/cons
• Positive community themes (secondhand, reportedly from Reddit): UI plus YAML lowers the barrier for non-Python authors and is simpler than Airflow or Prefect. Formal review-platform evidence is thin — aitoolsatlas; other favorable review (7.8/10): makerstack
• Kestra's own rebuttal of YAML criticisms (vendor marketing) — Kestra blog: YAML pitfalls (2023, older)
• 2.0 brings many breaking changes and requires migrating through 1.3.x first — migration guide
• "Business-process or app-centric automation is usually easier in n8n" — ZoomInfo

Inferences

• The biggest practical limitation for an n8n replacement is that OSS has a single Basic Auth user with no RBAC or SSO. A team would have to buy EE or accept one shared credential.

Gaps

• No primary Reddit or HN threads were retrieved; searches returned none. The criticisms above come from review aggregators and are of medium-low reliability.
• G2 and Gartner reviews were not retrieved.