When Step Functions fits and when Kestra fits better
Step Functions fits AWS-centric orchestration where the team wants managed operations, while Kestra fits teams that want declarative YAML flows, a broad plugin catalog and control over where the orchestrator runs. Consider a data or platform team facing a growing Step Functions bill, a residency rule that requires pipelines to run inside its own cluster, or a wish to operate workflows alongside the rest of its platform. The right answer depends on four drivers, and the team should score each one before comparing features.
The first driver is AWS service coupling. If most steps call Lambda, Glue, ECS or other AWS services through Step Functions' service integrations, the managed model removes much of the glue code, and IAM roles carry the permissions. The second is where data must run. Kestra's open-source edition can be deployed inside your own infrastructure, which matters when residency rules rule out a managed control plane. The third is who operates the platform. Kestra self-hosting adds work for patching, backups, upgrades and worker capacity, and the team should confirm that it has an owner for those tasks.
The fourth driver is whether the open-source edition's security limits are acceptable. Kestra's edition comparison describes basic authentication only, a single-server default deployment, manual secret and access management and no audit logging. Kestra's open-source edition is licensed under Apache License 2.0 and is described as fully functional for production, so the licensing question is simple. The operating question is whether your controls can accept those limits or whether you need the Enterprise Edition's SSO, RBAC, audit logs and external secrets managers. Confirm that answer with your security and compliance leads before you commit to a migration.
Which platform fits which scenario
This table maps common scenarios to the platform that fits better, with reasons tied to Kestra's documented editions and features. Read each row against your own AWS footprint, network and identity requirements. The main takeaway is that Kestra's strongest open-source fit is data and file-driven pipelines outside AWS, while SSO, audit logs and high availability sit in the Enterprise Edition.
| Scenario | Better fit | Reason |
|---|---|---|
| Workflows that call mostly AWS services | AWS Step Functions | Native AWS service integrations. Kestra reaches AWS through plugins and credentials you must manage. |
| Batch data pipelines with schedules and file triggers | Kestra | Scheduled and event-driven triggers are built in, and declarative YAML flows can be kept in Git. |
| Multi-cloud or on-premises data | Kestra | Self-hosted in your network, with hundreds of built-in plugins for databases, cloud storage and APIs. Confirm connectivity to each source. |
| SSO, SCIM and audit logs on day one | Kestra Enterprise Edition | Open-source Kestra has basic authentication and no audit logging. SSO, SCIM, RBAC and audit logs require the Enterprise Edition. |
| No platform engineers to run a cluster | AWS Step Functions | Kestra open source defaults to a single server, with manual secrets and access management. High availability is Enterprise only. |
| Teams that want AI agents or MCP access to flows | Kestra | The README lists AI agent and RAG task types and a built-in MCP server. Confirm the fit with your own model and data controls. |
| Open-source licensing for internal platforms | Kestra | The open-source edition is licensed under Apache License 2.0. Confirm license terms for any Enterprise components you plan to use. |
Where the data runs and who controls identity
These four cards cover the decisions that most often change when a team moves from Step Functions to Kestra: where execution data lives, who signs in, where secrets are kept and what evidence an assessor can review. Most of them depend on which Kestra edition you run, so read each card against the edition comparison before you size the platform.
Data location
Step Functions runs state machines in the AWS regions you select, so execution history, inputs and outputs are stored within AWS. Kestra runs wherever you deploy it: your AWS accounts, your data centers or an air-gapped network. Check which backend stores execution state, task logs and outputs, and which plugins call external APIs, because those calls leave your network whatever the host. Document each location before you pick a region or a cluster.
Identity and sign-in
Kestra's open-source edition offers basic authentication only. SSO, SCIM and role-based access control come with Enterprise Edition, so a team that stays on open source needs an identity gateway or reverse proxy in front of the UI and API, with its own logging and session policy. Step Functions access is governed by IAM roles and policies in your AWS account. Map each of those permissions to a specific Kestra role before cutover so no operator keeps access they used to have only through IAM.
Secrets handling
Open-source Kestra relies on manual secret and access management. Enterprise Edition adds external secrets managers such as HashiCorp Vault and Azure Key Vault. Step Functions workflows usually read credentials through AWS services such as Secrets Manager or Systems Manager Parameter Store, with IAM controlling each call. Before migration, decide who creates, rotates and revokes each secret, and how a rotation reaches flows that are already running. Confirm whether your secrets backend is supported on the edition you plan to run.
Compliance evidence
DeployOpen prepares controls, configurations and evidence for a compliance assessment. Independent auditors and certification bodies assess them and issue any report. Kestra's open-source edition has no audit logging, so evidence of who changed a flow or ran a task must come from elsewhere, such as Git history for flow definitions and your platform's own logs. Enterprise Edition adds audit logs. Confirm with your assessor which evidence they accept before you design the logging.
What self-hosting Kestra adds to the operations load
Self-hosting Kestra moves operations work that AWS Step Functions handles as a managed service onto your team: server hosting, upgrades, backups, patching, monitoring, and secret and access management. Step Functions has no servers to size, patch or back up. With Kestra, someone owns each of those duties, and the open-source edition, licensed under the Apache License 2.0, gives you the software but not the operating model around it. Before committing, map each duty to a named owner and confirm how it will be covered during business hours and out of hours.
Upgrades deserve specific planning. Kestra 2.0 is a major release with breaking changes, and the project publishes a dedicated 2.0 migration guide. One example of the kind of change to expect is the replacement of ForEach and ForEachItem with a single Loop task, so every flow that uses those tasks needs review and testing before cutover. Patch releases on the 1.3 line continue separately, so decide which line your environment will run and who signs off on moving between them. Ask your team to test upgrades in a staging copy of production flows, and keep a rollback path for the database and configuration.
Availability is the other gap. The open-source default is a single-server deployment, and the edition comparison lists basic authentication only, manual secret and access management, and no audit logging. High availability with Kafka plus Elasticsearch, Redis, AMQP or GCP Pub/Sub queue backends, along with SSO, SCIM, RBAC, audit logs and external secrets managers such as HashiCorp Vault, is part of the Enterprise Edition. Confirm your uptime and recovery requirements against the single-server model and against what a commercial license would cover. If a flow feeds a time-sensitive business process, decide whether a single node is acceptable before you rely on it.
What drives the cost of each option
This table compares what you pay for each option by component, separating one-time work from recurring spend. Read it as a checklist for building a quote: the Step Functions column is usage-based, while the Kestra column depends on whether you run the open-source edition or buy Enterprise.
| Cost component | AWS Step Functions | Self-hosted Kestra open-source edition | Kestra Enterprise Edition |
|---|---|---|---|
| License | No license fee. Billed by AWS per state transition (Standard) or per request and duration (Express) | No license fee under Apache License 2.0. Confirm the terms with your legal team before production use | Quoted separately by Kestra. Ask for the license scope, term and what it covers |
| Compute and infrastructure | Included in the service. Costs scale with the number of state transitions and executions | Your servers or cloud instances for the Kestra server and workers. Sizing depends on flow concurrency and task types | Higher footprint for high availability, worker groups and task runners on Kubernetes or cloud batch services |
| Database, queue and storage | Managed by AWS. Execution history retention is a service setting | Backend database and storage you operate, plus backup. Choose and size these with your platform team | Adds Kafka with Elasticsearch, or Redis, AMQP or GCP Pub/Sub queue backends, each run and monitored by you |
| Secrets and access controls | Uses AWS IAM and service integrations already in your account | Manual secret and access management under basic authentication. Budget time to build your own controls | SSO, SCIM, RBAC and external secrets managers such as HashiCorp Vault are included in the edition. Confirm licensing for each |
| Migration and flow translation (one-time) | Not applicable, this is the current state | Translating state machines into YAML flows, rebuilding IAM-based integrations and testing. Scope it per workflow | Same translation work, plus configuration for SSO, audit logs and multi-tenancy if you need them |
| Engineering and on-call (recurring) | Lower operations load for AWS-managed components. Ongoing work is mainly flow changes and IAM | Patching, scaling, backups, monitoring and incident response for the platform itself. This is usually the largest recurring cost | Same platform duties, with more components to operate, such as queues and search indexes |
| Upgrades and support (recurring) | Covered by AWS service changes. Your work is updating your definitions | Major releases can include breaking changes, such as the 2.0 migration with a dedicated guide. Plan testing time for each upgrade | Vendor support is part of the license terms. Ask what response commitments are included in writing |
| Quote request checklist | Current state transition and request volumes from your AWS bill | Written scope: workflow count, integrations, environments, backup and upgrade cadence | Edition features needed, HA requirements, support level, term and renewal price basis |
What moving state machines to Kestra involves
This sequence takes Amazon States Language definitions and their AWS integrations, rebuilds them as Kestra flows with credentials and triggers, and cuts over only after both platforms have run in parallel and produced matching results.
Inventory state machines and service integrations
Export every state machine definition and list each Task state, the AWS service it calls, its retry and catch configuration, and the triggers that start it, including EventBridge rules, schedules and API calls. Record which executions depend on the 90-day execution history window and which teams own each workflow. Done means a single inventory sheet where every state machine has an owner, a trigger and a list of AWS calls, and nothing is left unassigned. Your platform engineers and workflow owners do this work, and it is the input for every later step.
Map Task, Choice, Parallel, Map and Wait states
Translate each state into a Kestra task type in YAML. Task states become plugin tasks or script tasks, Choice states become conditional logic with switch-style branching, Parallel states become parallel task groups, and Wait states become pauses or time-based triggers. Confirm the exact task types and their parameters against the plugin documentation for your Kestra line, since plugin names and options differ between versions. Done means every state in the inventory has a documented Kestra equivalent, with gaps marked for redesign.
Replace iterate patterns with the 2.0 Loop task
Where a Map state or an iterative pattern processes items, rebuild it using the Loop task. Kestra 2.0 replaces the earlier ForEach and ForEachItem tasks with this single Loop task, so flows written against the older syntax need changes. Decide first which Kestra line you will run. Kestra 2.0 has a dedicated migration guide with breaking changes, and the 1.3 line continues to receive patch releases. Confirm the choice of line with Kestra and your own compliance and upgrade policy before you rewrite any loops. Done means each iterative flow is written against the chosen line and tested with representative item counts.
Recreate IAM access as Kestra credentials
Step Functions uses the IAM role attached to each state machine. In Kestra, define credentials and secrets for each AWS integration, scoped to the minimum actions each flow needs. On the open-source edition, secret and access management is manual, so store secrets in your own vault and reference them from flows, and confirm that your AWS roles are not reused across unrelated flows. If you need SSO, RBAC, service accounts or external secrets managers such as HashiCorp Vault, check whether they fall within the Enterprise Edition scope. Done means each flow authenticates with its own scoped identity and a reviewer has checked the permissions against the original IAM policies.
Build flows in Git and test them
Store the Kestra YAML flows in Git so that changes go through review, and use the Git integration that Kestra describes for version control. Run each flow against test data and compare its outputs, retries and failure paths with the original state machine's execution history. Document every intentional difference. Done means each flow passes its test cases, the repository holds the approved versions, and the differences list has been signed off by the workflow owner.
Run both platforms side by side
Keep the Step Functions state machines active while Kestra flows run the same work against non-production or shadow targets, or on a mirrored schedule where the business allows it. Compare run outcomes, timings, error handling and downstream data. Confirm how your observability tooling captures Kestra execution logs and failures, because the open-source edition has no audit logging. Done means a defined comparison period has produced results that the owners accept, and every discrepancy is closed or explained.
Cut over triggers and retire state machines
Move each trigger in turn, starting with the lowest-risk workflows. Redirect EventBridge rules, schedules or API calls to the Kestra flow, then disable the matching state machine so it cannot start a duplicate run. Keep the exported definitions and execution records in your archive for audit and rollback. Done means each trigger points to Kestra, no state machine receives production traffic, and the rollback path has been tested for each workflow.
Questions buyers ask before switching from Step Functions
How much effort does moving from Step Functions to Kestra take?
The effort depends mainly on how many state machines you run, how many AWS service integrations they call, and how much logic sits in Choice, Map and Parallel states. Step Functions definitions are JSON written in Amazon States Language, while Kestra flows are declarative YAML, so each state machine is rewritten rather than converted line by line. Teams usually start with an inventory that lists every workflow, its triggers, its IAM roles and its failure paths, then migrate the simplest flows first and run both systems side by side until outputs match. Ask any partner to size the work from that inventory in a written scope before you commit to a timeline.
Can an internal team migrate Step Functions to Kestra without outside help?
A capable internal team can migrate, provided it has people who know Kestra's YAML flows, its plugins and its deployment model, and who can operate the platform afterward. Outside help is most useful for the parts that are easy to get wrong: designing the cutover, hardening the self-hosted installation, and documenting controls for an assessment. DeployOpen plans, implements and hands over self-hosted platforms in the client's own cloud accounts or data centers under a fixed scope agreed in writing, so you can choose between doing it internally, doing it with a partner, or a mix of both.
What does the migration need from platform, AWS and workflow owners?
Each group has a distinct job. Platform engineers own the Kestra installation, the database and storage it depends on, networking, backups and upgrades. AWS owners confirm which IAM roles, service integrations and KMS-encrypted definitions the state machines use, and they decide how Kestra will authenticate to AWS. Workflow owners validate that each migrated flow produces the same business results, including retries, timeouts and alerts. Agreeing on who signs off each flow before cutover prevents most delays.
Can Kestra call AWS services the same way Step Functions does?
Kestra can run tasks that interact with AWS and other cloud services through its plugin library, but it does not replicate Step Functions' native service integrations one for one. Step Functions connects directly to many AWS services from state definitions and manages their optimized integration patterns, while Kestra uses plugins and scripts that your team configures and tests. Confirm the exact plugins, authentication method and error handling for each AWS service your workflows use, and test them against your own accounts before you retire the originals.
How do I handle SSO and audit logs on the open-source edition?
The open-source edition provides basic authentication, manual secret and access management, and no audit logging. If your policy requires SSO, SCIM, role-based access control, external secrets managers or audit logs, those features are part of Kestra Enterprise Edition, which you should price and scope separately. Without them, you need compensating controls: a reverse proxy or identity layer in front of Kestra, a secrets store managed outside the platform, and logs captured from the infrastructure around it. Check these requirements with your security and compliance owners before choosing the edition.
Is the open-source edition of Kestra safe for production?
Kestra's edition comparison describes the open-source edition as fully functional for production, but with a single-server default deployment and no high availability. Whether it is safe for your workloads depends on your recovery targets, your tolerance for downtime, and how you secure access and secrets. Kestra Enterprise Edition adds a high availability architecture with queue backends, worker groups and task runners for Kubernetes and cloud batch services. Test failover, backups and restores in your own environment, and ask any implementation partner to document those tests as part of the scope.
What does an upgrade to the Kestra 2.0 line involve?
Kestra 2.0 is a major release with breaking changes, and Kestra publishes a dedicated 2.0 migration guide. One documented change is that the ForEach and ForEachItem tasks are replaced by a single Loop task, so existing flows that use them must be edited. Because the 1.3 line still receives patch releases, you can plan the move on your own schedule. A safe upgrade covers a test environment, a review of every flow against the migration guide, plugin version checks, backups before the change, and a rollback plan.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For AWS Step Functions vs Kestra, we start by agreeing in writing what is in scope, then build and hand over a Kestra deployment that fits how your state machines and AWS integrations actually run.
How we scope
- Inventory existing state machines, their AWS service integrations, IAM roles and execution volumes before any design work starts.
- Agree in writing which workflows move to Kestra, which stay on Step Functions, and which are retired.
- Define the Kestra edition, deployment topology and operational responsibilities, including who owns upgrades and secrets management.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work begins.
How we build
- Translate selected Amazon States Language flows into declarative Kestra YAML flows with triggers and schedules mapped one by one.
- Configure AWS plugin connections, secret handling and Git version control for flow definitions in your own environment.
- Test each migrated flow against its current Step Functions behavior, including retries, failure paths and timing, and record the results.
- Harden the deployment, including authentication, network placement and backup of the Kestra metadata store.
How we hand over
- Deliver written documentation covering architecture, flow inventory, runbooks and the operational differences from Step Functions.
- Walk your platform and data teams through deployment, flow authoring, troubleshooting and upgrade procedures.
- Provide the evidence and configuration records your internal or external auditors may ask for, without issuing any audit opinion ourselves.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Retainers can cover Kestra version upgrades, including breaking changes in major releases, after your team approves each change.
- Ask us to confirm which features, such as SSO, audit logging or high availability, need the Enterprise Edition before you commit to a design.
