When is the open-source Kestra edition enough, and when do you need Enterprise?
For most teams, the Apache-2.0 Kestra edition is fully functional for production, according to Kestra's own edition comparison, so the Enterprise decision is about specific controls, not about whether the engine works. If you run Kestra in your own cloud account, data center or air-gapped network and can accept basic authentication, a single-server default deployment and manual secret and access management, the open-source edition can carry production workflows. Kestra open source vs Kestra Enterprise is a decision you make per requirement: list the controls your auditors, security team and tenant owners expect, then check each one against the edition comparison at Kestra open source vs paid editions.
Enterprise becomes necessary when a specific requirement cannot be met with the open-source edition's built-in features. The usual triggers are identity federation (SSO, SCIM provisioning and RBAC), audit logging of who changed a flow or accessed a secret, centralized secrets in an external manager such as HashiCorp Vault or Azure Key Vault, separation of tenants with worker isolation, and a high availability architecture using Kafka with Elasticsearch and a supported queue backend. Each trigger has a different cost profile. A team that only needs an audit trail can often add logging around its deployment, while a team that needs tenant separation or HA is likely buying the Enterprise architecture itself. Ask Kestra to confirm which of these capabilities each edition includes at your version, and ask whether the license terms cover your deployment model.
Before you decide, run a short test against your own requirements. Write down which people will change flows, which secrets your flows read, and whether any team must be isolated from another. Then check how the open-source deployment handles each item today, including who rotates secrets by hand and where access reviews are recorded. A quote for Enterprise should follow from a written scope that names the identity provider, secrets manager, number of tenants and HA targets, since those inputs drive implementation and support effort. The open-source edition stays a valid choice as long as its gaps are ones you can document, accept and monitor.
Which Kestra capabilities are free and which are paid?
This table sets Kestra's open-source edition against Kestra Enterprise Edition, capability by capability, using the split Kestra documents. Read the open-source column as the baseline for production, then check whether each Enterprise item is a control your team must have in place before go-live. The main takeaway is that identity, secrets, audit logging and high availability are where the two editions diverge most.
| Capability | Open source (Apache-2.0) | Enterprise Edition |
|---|---|---|
| Authentication | Basic authentication only | SSO, plus SCIM and RBAC for user provisioning and roles |
| Deployment topology | Single-server default deployment | High availability architecture with Kafka plus Elasticsearch, or other queue backends |
| Secrets management | Manual secret and access management | External secrets managers such as HashiCorp Vault and Azure Key Vault |
| Audit logging | No audit logging | Audit logs, so confirm the recorded events with Kestra |
| Service accounts and API tokens | Not listed in the edition comparison, so confirm with Kestra | Included, so confirm token scope in Kestra's comparison |
| Multi-tenancy and worker isolation | Not listed, so confirm before relying on it | Included, with worker groups and task runners for Kubernetes and cloud batch services |
| Queue backends | Not part of the documented open-source split | Kafka plus Elasticsearch, Redis, AMQP or GCP Pub/Sub |
| Licensing | Apache License 2.0, described as fully functional for production | Paid edition, with pricing quoted by Kestra |
How licensing, support and updates differ between the two editions
The open-source and Enterprise editions differ in licence terms, vendor support and how contracts are written, not only in feature lists. These cards cover what the Apache-2.0 licence grants, how release lines are moving, what Enterprise adds on the commercial side, and which terms you must confirm directly with Kestra before you commit.
Apache-2.0 open-source licence
The open-source edition is licensed under the Apache License 2.0, as stated in the LICENSE file of the kestra-io/kestra repository. That licence lets you run, modify and redistribute the code without a per-seat or per-node fee from the licence itself. Check the licence text against your legal team's approved list, and confirm with Kestra whether any Enterprise-only code or plugins sit under different terms before you assume the whole stack is Apache-2.0.
Current and maintained release lines
Kestra v2.0.6 was published on October 13, 2026, and the 1.3 line continued to receive patch releases such as v1.3.43 on the same day. Version 2.0 contains breaking changes and has its own migration guide, so an upgrade from 1.3 is a planned project, not a routine patch. Decide which line you will run, and how long you will stay on it, before you build flows against either one.
Patch cadence on the 1.3 line
Continued patch releases on 1.3 help teams that cannot yet move to 2.0, but they do not tell you how long the line will be supported. Ask Kestra for the end-of-life date for 1.3, the window for security fixes and whether critical patches are backported. Without those written commitments, a stable-looking release page is not a support commitment.
Vendor-backed support in Enterprise
The open-source edition runs in production with community support and your own operating team. Enterprise adds vendor-backed support, which is the main reason regulated buyers pay for it. Ask Kestra what response times, escalation paths, named contacts and support hours the contract covers, and whether those terms apply to the self-hosted deployment in your own environment.
Enterprise contract and edition terms
Enterprise is a commercial edition, so its features, usage limits and terms of use come from a signed agreement rather than an open licence. Ask for the full licence and order form, including what counts as a licensed unit, whether HA components and worker groups are included, how the agreement treats upgrades between 1.x and 2.x, and what happens to your deployment if the subscription ends.
Support windows and SLAs to confirm
No supplied source states Kestra's support windows, service-level agreements or upgrade commitments for either edition. Put these questions in writing before procurement: how long each release line receives fixes, the severity definitions and response targets, and the notice period for breaking changes. Treat any verbal answer as unconfirmed until it appears in the contract.
What the free edition is missing for typical enterprise needs
The free edition's gaps matter most where many people touch production flows. Kestra's edition comparison says the open-source edition has basic authentication only, so there is no SSO federation with your identity provider. Every operator account is a local credential that someone must create, rotate and remove by hand. Without SCIM provisioning, offboarding does not follow from HR or directory changes, and without RBAC, you cannot split who may edit flows from who may only view executions or trigger runs. If your regulated environment requires documented least privilege and timely deprovisioning, these gaps are the first to close, and the Enterprise Edition is where SSO, SCIM and RBAC are listed. Confirm the exact role model and SCIM behavior with Kestra's documentation before you design around it.
Secrets and audit evidence are the second cluster. The open-source edition relies on manual secret and access management, so credentials for databases, cloud accounts and APIs used by flows live wherever your team puts them. Enterprise adds external secrets managers such as HashiCorp Vault and Azure Key Vault, which move secret storage and rotation under the controls you already audit. The open-source edition also has no audit logging, so there is no built-in record of who changed a flow, who ran it or who viewed a secret-backed execution. A team that must show evidence to an assessor will need either the Enterprise audit logs or a compensating log pipeline outside Kestra that you have tested for completeness. Ask Kestra to show the audit events it records before you rely on them.
A small internal team with one trusted operator can reasonably accept these gaps, provided the compensating controls are written down and enforced. Illustratively, a team of two engineers running internal reporting flows on a single server, with secrets held in a dedicated store, network access limited to the operators, and change control through Git version control, may judge that the risk is low. The gaps become unacceptable when more people or systems need different permissions, when customer or regulated data flows through the platform, or when an auditor asks for proof of access decisions. Decide that threshold before go-live, not after the first audit request.
Which team profiles should pay for Enterprise
A single team running Kestra on one server, with a small set of flows and a known set of operators, is the profile where the open-source edition fits most naturally. Kestra's edition comparison describes the open-source edition as fully functional for production, so the question is less about whether flows run and more about how access and secrets are handled. Basic authentication, a single-server default deployment and manual secret and access management are the trade-offs a pilot accepts by design.
- Access model: Basic authentication is sufficient when a handful of people administer flows and nobody needs federated sign-in or role-based separation.
- Deployment: A single-server default keeps operations simple, but the host becomes the one place to patch, back up and restore.
- Secrets: Manual secret management is workable at pilot scale, provided the team documents where each credential lives and who rotates it.
- Audit trail: Without audit logging, change history depends on Git version control of flows, which the README lists as an integration, rather than on a platform record.
- Exit path: Flows authored in declarative YAML remain portable, so a pilot can be promoted to a larger deployment later without rewriting them.
Before paying for anything, confirm with the vendor which edition features the pilot actually needs, and record the point at which a second team or a compliance review would change that answer.
A platform team serving several business units usually needs each unit to see only its own flows, runs and credentials, and it needs administrators to delegate access without handing out global rights. This is where the Enterprise Edition's identity and tenancy features are designed to matter. Kestra's edition comparison lists SSO, SCIM and RBAC, service accounts and API tokens, multi-tenancy and worker isolation as Enterprise features, so the open-source edition should not be assumed to cover shared-platform separation.
- Identity: SSO and SCIM let the platform team tie access to the corporate directory instead of maintaining local accounts for every unit.
- Role separation: RBAC is the mechanism for limiting which unit can edit, trigger or view a given namespace of flows.
- Automation access: Service accounts and API tokens let CI pipelines and other systems call Kestra without sharing a personal login.
- Isolation: Multi-tenancy and worker isolation reduce the chance that one unit's heavy or misconfigured job affects another unit's runs.
- Operating model: Someone must own tenant onboarding, offboarding and quota decisions, which is ongoing work whatever the license.
Ask the vendor to demonstrate tenant boundaries and worker isolation in a test environment that mirrors your directory setup, not only to confirm that the features exist.
A regulated organization typically needs to show who changed a workflow, who accessed a credential and how secrets were stored and rotated. The open-source edition is documented as having no audit logging and manual secret and access management, so an auditor will expect those controls to be supplied elsewhere or added through the Enterprise Edition. Readiness work is still required either way: a platform record only becomes evidence when the surrounding policies, reviews and retention rules are in place.
- Audit logs: Enterprise adds audit logging, which is the record most assessors will ask to see for administrative and flow changes.
- External secrets managers: Integration with HashiCorp Vault or Azure Key Vault moves credentials out of the platform and into a store your security team already governs.
- Access governance: SSO, SCIM and RBAC support joiner, mover and leaver processes that map to your identity controls.
- Compliance mapping: Confirm with your assessor which controls they expect to see from the platform and which from surrounding processes.
- Evidence: DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors do.
Before committing, ask the vendor for its current audit log schema and retention behavior, and confirm with your assessor which framework applies and what evidence it requires.
A workload that cannot tolerate a single-server outage, or that processes high event volumes across many workers, is the profile for the Enterprise high availability architecture. Kestra's edition comparison describes it as built on Kafka plus Elasticsearch, with Redis, AMQP or GCP Pub/Sub as alternative queue backends, plus worker groups and task runners for Kubernetes and cloud batch services. The architecture is a platform in its own right, so the decision carries operational weight beyond the license fee.
- Backend choice: Kafka with Elasticsearch is the documented HA pairing, while Redis, AMQP or GCP Pub/Sub are alternatives whose fit depends on your existing messaging estate.
- Worker groups: Task runners for Kubernetes and cloud batch services let heavy jobs run where their resources live.
- Operating load: Each backend adds components to patch, monitor, scale and back up, and that effort recurs.
- Skills: Running Kafka and Elasticsearch well requires staff who already operate them, or a plan to hire or contract that skill.
- Sizing: Throughput and failover targets should come from your own load tests, not from general guidance.
Ask the vendor for a reference architecture matching your queue backend and cloud, and ask your platform team which of those backends it already runs.
How to move from the open-source edition to Enterprise, and back
The sequence below takes a team from an inventory of what runs on Kestra open source to a validated Enterprise cutover, with the reverse path covered at each decision point. Each step names an output so the team can confirm progress before moving on.
Inventory flows, plugins and secrets
Start by listing every flow, namespace, plugin and secret the current open-source deployment uses, including where each secret is stored today and which flows call it. Ask the platform owner to export or review flow definitions from the source repository, since Kestra supports Git version control integration, and record which flows are scheduled and which are event-driven. The step is done when the team holds a written inventory that maps each flow to its owners, triggers, plugins and secret references, and when every flow has a confirmed source of truth outside the running server.
Confirm the Kestra version and breaking changes
Before any edition change, align the Kestra version the team will run on the target edition with the release line in use today. Kestra 2.0 is a major release with breaking changes, and the dedicated 2.0 migration guide replaces ForEach and ForEachItem with a single Loop task, so flows built on the older constructs need rewriting and testing. Compare the current 1.3 patch line with the 2.x line in the kestra-io/kestra releases page, and decide which version is the baseline for both the open-source and Enterprise environments. The step closes when every affected flow has been listed, rewritten where needed, and run in a non-production environment on the chosen version.
Decide identity federation and tenant model
Decide how users will sign in and how access will be divided. The open-source edition offers basic authentication only, while Enterprise adds SSO, SCIM and RBAC, service accounts, API tokens and multi-tenancy. Map your identity provider groups to Kestra roles, decide which teams need separate tenants or isolation, and document which automation identities will use service accounts instead of personal accounts. The step is complete when the team has an approved role matrix and tenant layout, and the identity owner has confirmed the group mapping in writing. Confirm with Kestra how SCIM provisioning and SSO are configured in your edition.
Plan the move of secrets to an external manager
Open-source Kestra relies on manual secret and access management, so this is the point where secrets move to an external manager such as HashiCorp Vault or Azure Key Vault, both named in the Enterprise feature set. For each secret in the inventory, decide the target path, the owning team and the rotation process, then update flow references so no plaintext value remains in flow definitions or configuration. Test one flow end to end against the external manager before moving the rest. The step is done when every secret has a documented owner, a tested retrieval path and a rotation procedure, and a scan of flow definitions shows no embedded credentials.
Schedule the switch to HA queue backends
The open-source default is a single-server deployment, while Enterprise adds a high availability architecture with Kafka plus Elasticsearch, Redis, AMQP or GCP Pub/Sub queue backends, worker groups and task runners. Choose one backend combination, size the supporting infrastructure with the platform team, and plan the cutover window with operations, since the queue backend change affects how executions are dispatched. Ask Kestra to confirm the supported configuration and the upgrade path from the single-server default. The step is complete when the target architecture diagram is approved, the infrastructure is provisioned in a staging environment, and a failover test has been run and recorded.
Run a staged cutover with validation
Move flows in stages, starting with a low-risk namespace, and run each group against its scheduled and event-driven triggers in the target environment. Compare execution outputs, logs and downstream results with the open-source baseline recorded in the inventory, and confirm that audit logs are being written for the actions that matter to your controls. Keep the open-source environment available until each stage passes, because that is the practical route back if a stage fails. The step closes when every stage has a signed-off comparison and the audit log sample has been reviewed by the security owner.
Document the reverse path and decommission
Write a rollback procedure that states which flows, secrets and identities must be restored if the team moves back to the open-source edition, and which Enterprise-only features (such as SSO, RBAC, audit logs and HA backends) will stop working on that path. Record the export of flow definitions and configuration taken from Enterprise, and confirm which components can be safely retired. Retire the old environment only after the rollback procedure has been tested in staging. The step is done when the rollback runbook is signed off by the platform owner and the security owner, and the decommission record lists every component removed.
What drives the cost of each Kestra edition
This table lists the cost components of running Kestra open source and Kestra Enterprise, who is paid for each one, and whether it is one-time or recurring. Use it to build the questions you put to Kestra and to your own team before comparing totals, since the Enterprise license fee is not published and must come from a written quote.
| Cost component | Open source edition | Enterprise edition | One-time or recurring |
|---|---|---|---|
| Software license | None under Apache License 2.0 | Paid Enterprise license, quoted by Kestra on request | Enterprise: recurring, term to confirm in quote |
| Queue and search backends | Not required in the default single-server deployment | Kafka plus Elasticsearch, or Redis, AMQP or GCP Pub/Sub, plus hosting and operations | Recurring infrastructure, sized to load |
| Secrets manager subscriptions | Manual secret management in your own tooling | External managers such as HashiCorp Vault or Azure Key Vault, billed by their vendors | Recurring, paid to the secrets vendor |
| Identity and access integration | Basic authentication only, so SSO work is not needed | SSO, SCIM and RBAC setup against your identity provider, by your team or a services partner | One-time build, then ongoing maintenance |
| Internal engineering time | Hardening, backups, access control and audit evidence built by your team | Worker groups, task runners and HA topology design and operation | Recurring staff effort for operations |
| Upgrades under 2.0 breaking changes | Migration from 1.x to 2.0 planned and tested by your team, guided by the 2.0 migration guide | Same migration work, plus Enterprise feature configuration to verify | One-time per major release, recurring over the product life |
| Audit logging and evidence | No audit logging in the edition, so you build and retain logs externally | Audit logs included, with retention and export to confirm | Recurring storage and review effort |
| Services and support | Optional, scoped in writing with a provider such as DeployOpen | Vendor support and any included services, to confirm in the quote | Mix of one-time project fees and recurring retainers |
Questions buyers ask before choosing Kestra Enterprise
Is the open-source Kestra edition ready for production?
Yes, according to Kestra's own edition comparison, the open-source edition is fully functional for production, but it comes with basic authentication only, a single-server default deployment, manual secret and access management, and no audit logging. Whether that is enough depends on your identity model, how many teams share the platform, and whether your auditors expect logged access changes. Confirm each of those gaps against your control requirements before you commit to the open-source edition for a regulated workload. The Apache-2.0 license itself places no restriction on running it in production.
What does the Kestra Enterprise upgrade cost, and what drives the price?
Kestra does not publish its Enterprise pricing in the material this page relies on, so the figure has to come from Kestra's commercial team and your own quote. The main drivers are the number of users and environments, whether you need the high availability architecture, and the size of the worker fleet. Ask Kestra which features are licensed per instance and which per user, whether support is included, and how renewals are priced. Separately, DeployOpen is paid for the scoped work to install, configure and document the platform, which is a different line item from the license.
How long does a move to a high availability Kestra setup take?
The duration depends on your target architecture and what already exists in your environment, and no fixed timeline is supplied for this change. The high availability design adds Kafka plus Elasticsearch, or a Redis, AMQP or GCP Pub/Sub queue backend, along with worker groups and task runners for Kubernetes or cloud batch services. Each backend you add needs its own hosting, sizing, monitoring and backup decisions. Ask for a written scope that lists each component, the environments involved and the test plan before setting a date.
Can our team set up SSO, SCIM and RBAC without outside help?
A team with strong identity engineering can do it, but the work spans your identity provider, Kestra's Enterprise configuration and your access review process. Kestra Enterprise adds SSO, SCIM and RBAC, service accounts and API tokens, so the design questions are which groups map to which roles, how deprovisioning flows from the directory, and who owns service account credentials. Plan for a test tenant, document the role model, and have someone other than the builder verify that revoked users lose access. If your identity team is already stretched, treat this as the first candidate for a fixed-scope engagement.
Who should own external secrets management in a Kestra deployment?
Ownership should sit with the team that already controls secret rotation for your other platforms, because Kestra only reads from the store you point it at. Enterprise adds integration with external secrets managers such as HashiCorp Vault and Azure Key Vault, which removes the manual secret handling of the open-source edition. Decide who can create flows that reference secrets, how rotation is tested against running flows, and how access to the vault path is audited. Confirm the exact integration steps for your chosen vault with Kestra before you rely on them.
When is outside help worth scoping as a fixed-scope engagement?
Outside help makes the most sense when the work has a clear end state, such as an Enterprise rollout, an HA build, or evidence preparation for an assessment. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ongoing upgrades and support run as retainers. Choose a fixed scope when your team lacks capacity or experience for one defined change, and a retainer when you need continuing upgrades, for example across Kestra 2.x releases.
What should we verify about audit logs before relying on them for compliance?
Start by confirming which events the Enterprise audit log records, where the log is stored, how long it is retained, and whether it can be exported to your existing monitoring stack. The open-source edition has no audit logging, so any evidence of access changes depends on the Enterprise feature being in place from day one. Test the log by making a permission change and confirming the entry appears with the actor and time. DeployOpen prepares systems and evidence for compliance assessments, but auditors and certification bodies issue the actual conclusions.
Deciding between the free edition and Enterprise for your environment
Start with the threat model and audit evidence your auditors will actually request. If the Apache-2.0 edition meets those needs through compensating controls, it is a sound production choice. The open-source edition is described by Kestra as fully functional for production, with basic authentication, a single-server default deployment, manual secret and access management and no audit logging. Those gaps can be closed with your own controls: a reverse proxy or identity layer in front of the UI, secrets injected from your existing vault, access reviews run by hand, and infrastructure logs shipped to your SIEM as an audit substitute. Document each compensating control and confirm with your assessor that it satisfies the requirement.
Move to Enterprise when a gap can no longer be covered by a control you own. Typical triggers are federated sign-in through SSO with SCIM provisioning and RBAC, audit logs that must be produced as evidence, tenant isolation between business units, worker isolation for sensitive job execution, or a high availability design with Kafka and Elasticsearch plus a Redis, AMQP or GCP Pub/Sub queue backend. Each of these adds operating components, so ask Kestra to confirm the supported architecture for your region, the upgrade path from the 1.3 line to 2.x, and the exact Enterprise terms in writing. Pricing and license scope are not published in the sources used here, so request a quote tied to your deployment model and user count.
Do not treat this as a platform choice. If the real question is whether a YAML-declared orchestrator fits your team at all, compare the platforms first and then return to the edition question. For a team weighing a code-first, script-driven alternative, Kestra vs Windmill covers authoring model, licensing and the features each reserves for its paid edition. DeployOpen can plan the architecture, compensating controls and evidence for either path under a fixed written scope.
How DeployOpen scopes and delivers Kestra deployments
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kestra, that means working out which Enterprise capabilities your environment actually needs before any build starts, then delivering them in a written, fixed-scope engagement.
How we scope
- Start with your identity, secrets, audit and tenancy requirements, mapped to the edition features they depend on
- Agree in writing which Kestra edition, deployment topology and backend stack the engagement covers
- Confirm current Kestra edition terms and feature availability with Kestra before fixing scope
- Set deliverables and timelines in the written scope, with no work starting before agreement
How we build
- Configure the chosen edition, including basic authentication or SSO, RBAC and service accounts as scoped
- Integrate external secrets managers and cloud storage, and wire Git-based flow version control
- Test scheduled and event-driven triggers, worker isolation and failover behavior against the agreed design
- Harden the deployment and run security testing on the flows, APIs and access paths it exposes
How we hand over
- Document the architecture, configuration, access model and any high availability components delivered
- Provide the runbooks for backup, restore, upgrades and migration between Kestra 1.x and 2.x
- Map controls and evidence to your compliance program, noting that independent auditors issue any formal assessment
- Walk your operations and security teams through handover before the engagement closes
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan upgrades against Kestra release notes and breaking changes, including the 2.0 migration guide
- Review the Enterprise feature set and backend dependencies when your requirements or scale change
- Request a quote from the written scope, since DeployOpen does not publish a price list
