AWS Step Functions alternative for multicloud and on-premises workloads

Why an AWS Step Functions alternative must run outside AWS

If your workflows must run in another cloud, in an on-premises data center or in a network AWS cannot reach, AWS Step Functions is not an option because it runs only as an AWS-managed service. Self-hosted Temporal or Kestra can meet that constraint, but the operations load moves from AWS to your team, including the orchestration servers, databases, upgrades, access control and on-call coverage. Step Functions executes state machines inside AWS accounts and Regions and integrates with AWS services through its own service integrations and IAM roles. The constraint you are solving usually comes from one of four places: data residency rules that keep processing in a specific facility, latency or connectivity to systems that sit outside AWS, contractual or sovereignty requirements, or a multicloud strategy that cannot depend on one provider's control plane. Each one changes what the orchestrator must do. It must start and resume workflows where the data lives, call internal APIs and databases directly, and keep execution history inside your boundary.

Before choosing a platform, write down which steps must stay local, which may call AWS, and who may read execution history and payloads. Then confirm with your compliance and security owners what they will accept for retained history and where it is stored. Confirm your own Step Functions usage, quotas and pricing in your AWS account and billing console rather than relying on figures from this page, since those values can change and depend on your contract. Treat the orchestrator as production infrastructure from day one, with the same change control, backup and access review you apply to your other critical systems.

What a multicloud or on-premises orchestration layer must provide

Once workflows leave AWS, the orchestration layer becomes a service your team must secure, connect and keep running. The cards below cover the decisions that follow from that move: where the control plane runs, who can call it, how payloads are protected, and which databases hold its state.

Run the control plane outside AWS

Step Functions gives you a managed control plane inside AWS. A self-hosted Temporal or Kestra deployment moves that responsibility into your clusters or data center, so you choose the hosts, the upgrade windows and the failure domains. Before committing, list which AWS service integrations your state machines call and decide how each one will be reached from outside AWS, including credentials and network paths.

Isolate services from the public internet

The Temporal deployment documentation says its services should run on hosts that the public internet cannot reach, with network access limited to trusted internal networks. Treat the frontend, the internode traffic and the persistence database as internal-only components. Confirm with your network team how workers in other clouds or sites will reach the frontend, and whether that path crosses a boundary you already monitor.

Replace the default open access

If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. Plan the Authorizer, a ClaimMapper that maps JWT or certificate claims to namespace roles, and mTLS between internal components before the first production namespace is created. Kestra's open-source edition offers basic authentication only, so review its access model against the same requirement.

Encrypt payloads end to end

Workflow inputs, outputs and activity results are stored in the cluster's history, so they can contain customer or financial data. Temporal supports payload encryption through custom codecs and a codec server, which lets you encrypt data before it reaches persistence. Decide which key store will hold the codec keys, who may decrypt payloads in the Web UI, and how keys rotate without breaking in-flight executions.

Choose supported persistence and visibility

Temporal persistence is tested on PostgreSQL 13 to 16, MySQL 5.7 and 8.0.19 or later, and Cassandra, while SQLite is meant only for development and testing. Advanced visibility supports Elasticsearch 7 and 8 and OpenSearch 2 or later from Temporal Server 1.30.1, and Cassandra visibility was removed in 1.24. Elasticsearch or OpenSearch is recommended for anything beyond a few workflow executions, so budget for that cluster and its backups alongside the database.

Fix the upgrade sequence

Temporal guarantees backward compatibility only between two successive minor versions, so upgrades should move one minor line at a time, starting from the latest patch of the current minor. Schema upgrades must run before server upgrades when release notes call for them. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so pin chart and server versions together and test each step in a non-production environment first.

Temporal or Kestra for workflows outside AWS

Self-hosted Temporal is the closer match when Step Functions workflows contain complex branching, long-running logic and custom retry behavior that your engineers want to express in ordinary code. The Temporal server is MIT licensed, so the server itself carries no license fee, and it can run through Docker Compose, Go binaries or Helm charts on Kubernetes. Persistence is the main infrastructure decision: the persistence docs list Cassandra, PostgreSQL 13 to 16 and MySQL as tested backends, while SQLite is meant only for development.

Security defaults: If no Authorizer is configured, the default noopAuthorizer allows every API request with no authentication, so access control must be set before any shared use.
Identity features: mTLS with separate internode and frontend settings, a ClaimMapper for namespace roles and OIDC single sign-on for the Web UI are available in the open-source server.
Visibility store: Advanced visibility needs Elasticsearch, OpenSearch or a supported SQL store, and Elasticsearch or OpenSearch is recommended beyond a few workflow executions.
Not covered: Payload encryption requires your own custom codec and codec server, and you own their design and key handling.
Upgrades: Upgrade one minor version at a time and run schema changes before server changes when release notes call for them.

Confirm with Temporal which persistence and visibility combinations it supports for your server version, and whether your Helm chart version matches your server image.

What changes for AWS service integrations after the move

Once a workflow leaves AWS, every call that Step Functions made to S3, SQS, Lambda, DynamoDB or another AWS API becomes an ordinary activity or Temporal task that your own code performs. Step Functions handled those calls for you, including the request signing, the IAM role attached to the state machine and the retry behavior of the service integration. After the move, your team owns the credentials the worker uses, the network route from the worker to each AWS endpoint and the retry and timeout policy around every call. Map each Task state to a named activity and record, for each one, which AWS API it calls, which identity it uses and what happens when that call fails halfway through.

The IAM execution role does not carry over. Each worker process needs its own identity, and the cleanest pattern for a worker outside AWS is a dedicated IAM role assumed through federation, such as OIDC federation from your identity provider or a workload identity from the other cloud, scoped to the exact actions and resource ARNs the activity needs. Long-lived access keys stored in environment variables are the common shortcut, and they become the weakest point in a multicloud setup because they must be rotated and revoked by hand. Decide where the secrets for each cloud live, who may read them and how a compromised worker is cut off. Confirm the exact federation options with AWS documentation and your identity provider, since the supported trust configurations depend on where the workers run.

Native Step Functions service integrations, such as direct optimized calls to DynamoDB or the .sync patterns for Batch and ECS, do not transfer automatically. Temporal and Kestra each ship their own plugin or SDK ecosystem, and whether an AWS service has an maintained connector in that ecosystem varies by service and version. Build an integration inventory that lists each AWS service call, the library or plugin that will make it, the version you have tested and the failure behavior you expect. Confirm each entry against the vendor's current SDK or plugin list in the Temporal or Kestra documentation rather than assuming parity, and plan a test for every callback or wait-for-completion pattern, because those usually need an explicit polling or signal design in the new engine.

How to deploy Temporal or Kestra under a multicloud constraint

This sequence takes a team from a confirmed network boundary to a self-hosted orchestration layer that runs outside AWS, with workers in each environment, security controls in place and a tested upgrade path. It is written for platform and security teams who own the cluster after handover.

Confirm the network boundary and ownership
Before choosing software, the platform team writes down which networks, clouds and data centers the orchestration layer must reach, and which ones may only be reached outbound. Temporal's deployment guidance says its services should run on hosts that are not reachable from the public internet, with access restricted to trusted internal networks. Security and platform leads also record who operates the cluster, who is on call and who approves changes. Done means a signed network diagram and a named owner for the orchestration layer, so later decisions about where workers run rest on agreed boundaries.
Choose the deployment method
Select how the server will be installed: Docker Compose, Go binaries, Helm charts that run each Temporal Server service in its own Kubernetes pod, or a custom Go build that imports the server package. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so teams that standardize on Helm must pin a compatible chart before deploying. Kestra's open-source edition is typically deployed as a single server by default, so a Kestra team should decide early whether that matches its availability needs. Done means a written choice of method and pinned chart or image versions stored in version control.
Select supported persistence and visibility stores
Pick a persistence database from the combinations Temporal tests: Cassandra 3.11, 4.0 or 5.0.4 and later, PostgreSQL 13 to 16, or MySQL 5.7 and 8.0.19 or later. SQLite is for development and testing only. For visibility, Elasticsearch 7 or 8, or OpenSearch 2 or later from Temporal Server 1.30.1, is recommended once executions grow beyond a few. Cassandra visibility was removed in 1.24. Managed database services from AWS, GCP or Azure can host the persistence layer if the team confirms they are supported for the chosen version. Done means a compatibility matrix signed off by the database and search owners.
Configure mTLS, authorizer and OIDC
Harden the cluster before any workflow runs. If no Authorizer is configured, self-hosted Temporal defaults to a noopAuthorizer that allows every API request without authentication or access control, so the team must configure one. Enable mTLS with separate settings for internode and frontend traffic, map JWT or certificate claims to namespace roles with the ClaimMapper, and connect the Web UI to the corporate identity provider over OIDC single sign-on. Plan payload encryption through a custom codec and codec server if workflow data is sensitive. Done means an automated check confirms unauthenticated calls are rejected and that each namespace grants roles only to the intended groups.
Deploy workers in each environment
Install worker processes in every cloud account and data center that holds systems the workflows must call. Workers poll the orchestration service, so each environment needs outbound network paths to the server endpoint and its own credentials for local systems. For Kestra, worker groups and task runners can be placed close to the data they process, and the Enterprise edition adds worker isolation for teams that need it. AWS service integrations need an explicit decision: calls to AWS APIs from workers use IAM credentials that the team manages, not the Step Functions service role. Done means each environment runs a worker that completes a test workflow end to end.
Test failover and recovery
Exercise the cluster the way it will fail in production. Stop a server node, a worker group and the persistence endpoint in a staging environment, then record how long workflows take to resume and whether any were lost. Confirm that backups of the persistence database restore to a working cluster. For Kestra, test the restart behavior of the single-server default and of any high availability setup the Enterprise edition provides. Done means a written test report with observed recovery behavior, reviewed by the team that will carry the pager.
Upgrade one minor version at a time
Plan every upgrade so that the server moves one minor version at a time, first to the latest patch of the current minor line. Temporal guarantees backward compatibility only between two successive minor versions. When release notes call for schema changes, run the schema upgrade before the server upgrade. Kestra 2.0 is a major release with breaking changes, so it requires its dedicated migration guide, including replacing ForEach and ForEachItem with a Loop task. Done means a rehearsed upgrade in staging, a rollback plan and a change record that names the release notes used.

Questions buyers ask before moving off Step Functions

Who runs the orchestration layer once Step Functions is replaced?

Your own platform or operations team runs it, or a partner runs it under contract. Step Functions is a managed AWS service, so AWS operates the control plane today. Self-hosted Temporal or Kestra moves that responsibility into your environment: you own upgrades, database capacity, backups, certificates, monitoring and on-call for the orchestrator itself. Staff time recurs every month, and it grows with the number of workflows, regions and environments. Ask any partner to put the operating model, the on-call rota and the named responsibilities in writing before the engagement starts.

Can our team deploy Temporal or Kestra without outside help?

A team with Kubernetes or container operations experience can deploy either platform, but the first production setup is where most of the learning happens. Temporal can be deployed with Docker Compose, Go binaries, Helm charts that run each server service in its own Kubernetes pod, or a custom Go build. Kestra's open-source edition is designed for a single-server default deployment. Self-assessment should cover security hardening, persistence design and upgrade procedures, not only the first successful install.

What infrastructure and database work does self-hosting require?

You need compute for the orchestration services, a supported persistence database, and a visibility store if you want to search workflow executions. Temporal's persistence is tested on Cassandra, PostgreSQL 13 to 16 and MySQL, and SQLite is for development only. Advanced visibility runs on Elasticsearch 7 or 8, OpenSearch 2 or later, or a SQL store, and Temporal recommends Elasticsearch or OpenSearch for anything beyond a few workflow executions. Temporal services should sit on hosts that are not reachable from the public internet. Cost drivers are the database and visibility tiers, the number of executions and the retention period you choose.

What does the Temporal server cost to run compared with per-transition pricing?

Step Functions bills per state transition or per request, so its cost scales with each step a workflow takes. A self-hosted Temporal cluster has no per-action fee from Temporal, but you pay for servers, the persistence database, the visibility store, storage, backups, and the engineering and on-call time that keep them running. Temporal's own published Cloud pricing starts at 50 US dollars per million actions, according to the Temporal pricing page, which gives you a comparison point for a managed option. Build your break-even model from your real transition counts and your own staffing cost, and ask for each component to be priced separately in any quote.

Is Temporal Cloud an option for a multicloud setup?

Yes, Temporal Technologies sells Temporal Cloud as a managed service alongside the open-source server, so it is one option to evaluate. Its published pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to the Temporal pricing page. The same page lists a 99.9% SLA, or 99.99% with high availability, and SAML SSO. Confirm where the managed service runs relative to your data residency requirements, and compare its ongoing cost with the staffing cost of running the server yourself.

Does Kestra open source include SSO and audit logs?

No. Kestra's open-source edition, licensed under Apache License 2.0, has basic authentication only, manual secret and access management, and no audit logging, according to Kestra's edition comparison. SSO, SCIM, RBAC, service accounts, external secrets managers such as HashiCorp Vault and Azure Key Vault, audit logs and multi-tenancy are part of Kestra Enterprise Edition, which also adds a high availability architecture. If your controls require SSO or audit trails, factor the enterprise license into the cost model, or plan to build and operate those controls yourself. Confirm the current feature list with Kestra before deciding.

Can we keep our AWS service integrations after leaving Step Functions?

Yes, but the integrations become your code instead of AWS-managed service integrations. Step Functions calls many AWS services directly and handles IAM roles, retries and callback patterns for you. After migration, each Task becomes an activity or workflow step that calls the AWS SDK with credentials you manage, and callbacks become signals or polling logic. Inventory every service integration, IAM role and encryption key during planning. Each one adds build, testing and secret-handling work, and it is the main reason migrations to Temporal or Kestra take longer than the workflow count suggests.

Evidence auditors and regulators ask for in a self-hosted orchestration layer

Once Temporal or Kestra runs inside your own network, the orchestration layer becomes part of your control environment. The cards below list the evidence that assessors typically request, and each one maps to a setting or record you own. DeployOpen prepares this evidence, but independent auditors and certification bodies issue the assessment.

Network and access configuration

Record where every Temporal service and Kestra component runs, which subnets reach the frontend and Web UI, and which ports are open between internal hosts. The Temporal deployment docs say its services should run on hosts not reachable from the public internet, so keep that as a testable statement. Capture firewall rules, load balancer and ingress settings, and a dated review showing that no service is exposed publicly.

Authentication and role mappings

Self-hosted Temporal uses the noopAuthorizer by default, which allows every API request. Evidence must show that an Authorizer, a ClaimMapper, mTLS and OIDC single sign-on are configured and tested. For Kestra Open Source, document that only basic authentication is available, then show how the Enterprise Edition controls for SSO, SCIM and RBAC would be used if your assessor requires them. Keep the mapping from identity groups to namespace or tenant roles under change control.

Encryption settings and key management

Record TLS settings for internode and frontend traffic, the database connection encryption, and the storage encryption for PostgreSQL, MySQL or Cassandra. Temporal supports custom payload codecs and a codec server, so document which data is encrypted at the payload level and who holds the keys. For Kestra, record how secrets are stored, since the open-source edition relies on manual secret management while the Enterprise Edition adds external secrets managers such as HashiCorp Vault and Azure Key Vault.

Upgrade and patch records

Keep a dated log of every server, schema and Helm chart change. Temporal's upgrade guidance says to move one minor version at a time, to run schema upgrades before server upgrades when release notes require them, and that Helm chart versions below 0.73.1 do not work with server images 1.30 and later. Also record Kestra major upgrades, since Kestra 2.0 introduced breaking changes covered by its migration guide.

Backup and restore tests for persistence stores

Backups of the persistence database and the visibility store are only evidence once a restore has been tested. Document the backup schedule, retention, encryption, and the date and outcome of each restore test into a separate environment. Confirm that the database engine and version are on Temporal's supported list, since persistence is tested on PostgreSQL 13 to 16 and MySQL 5.7 and 8.0.19 or later, and that SQLite is for development only.

Logs of workflow executions

Auditors often ask who started a workflow, what it changed, and whether the history was kept. Plan where workflow event histories, the visibility index and service logs are stored, and for how long. Kestra's open-source edition has no audit logging, so you will need to add it through the logging pipeline or confirm the Enterprise Edition covers it. Confirm the retention period with your compliance team before the first assessment.

When Step Functions is still the better fit

Step Functions remains the stronger choice when a workflow runs entirely inside AWS and its steps are mostly calls to AWS services. Native integrations with Lambda, ECS, Batch, SQS, SNS, DynamoDB and EventBridge mean the orchestration layer sits next to the resources it drives, uses IAM roles for access and needs no network path from your own servers. If your state machines are already defined in Amazon States Language, are reviewed through your existing AWS change process and are monitored in CloudWatch, moving them off AWS adds migration effort without removing a dependency you need. Before deciding, list every workflow and confirm which steps call non-AWS systems. Workflows with only a few such calls can often keep a hybrid design with a Step Functions state calling an HTTPS endpoint.

The managed service also suits teams that cannot staff a stateful cluster. A self-hosted Temporal deployment needs a persistence database, a visibility store such as Elasticsearch or OpenSearch, upgrades performed one minor version at a time, and someone on call for the Temporal services. Kestra's open-source edition removes the cluster-level Temporal work but still runs its own server, database and queue, and the open-source edition has basic authentication only, a single-server default deployment and no audit logging. If your platform team cannot take on those duties, ask whether a managed Temporal Cloud subscription or a DeployOpen retainer for upgrades and monitoring would cover the gap, and compare that quote with the internal cost of on-call.

Short, event-driven flows are the third case. A workflow that reacts to an S3 upload or an SQS message, runs a few steps and finishes in minutes gains little from a durable workflow engine, and the per-transition billing of Standard workflows or the request-based billing of Express workflows may cost less than a cluster that sits mostly idle. Estimate transitions per month from your own execution logs before comparing. Keep Step Functions for these flows unless a multicloud or data residency requirement applies to them, and document the boundary so that teams know which orchestrator owns each workflow.

How DeployOpen deploys orchestration under a multicloud constraint

DeployOpen plans, implements, hardens and supports self-hosted orchestration inside your own cloud accounts, data centers or air-gapped networks. For multicloud and on-premises workloads, we start by writing down which AWS service integrations must survive the move and which runtime owns each workflow.

How we scope

Engagements are fixed-scope, with the orchestration platform, workflows and AWS integrations agreed in writing before work starts
The written scope lists each Step Functions state machine, its AWS service calls and the target runtime for it
Scope also names who operates the Temporal or Kestra cluster after handover, and which team owns on-call

How we build

We deploy the chosen platform on your infrastructure using the documented install methods that fit your environment
Persistence and visibility stores are configured to the versions the platform documents as supported, with network access limited to trusted internal networks
Authentication, mTLS, role mapping and payload encryption are configured and tested rather than left at defaults

How we hand over

Deliverables include architecture documentation, runbooks for upgrades in one minor version steps, and backup and restore procedures
We document how AWS credentials, secrets and cross-cloud network paths are managed for each workflow
Handover covers operator training and a written list of controls and evidence prepared for your compliance assessors

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover
Upgrades follow the vendor's documented order, including schema changes before server changes where release notes require them
Compliance readiness work prepares evidence for independent auditors, who issue any audit reports or certifications