In Git
One YAML file per workflow.
Review a change in a pull request and roll it back like any other code. The editor in the UI writes the same YAML.
Your Terraform, Ansible and scripts, in one workflow.
Each tool already automates its own step. Kestra runs the chain
between them: one YAML file in Git, with triggers, approvals,
retries and a log of every run.
Open source, self-hosted, and your first flow runs in minutes.
Try it on your own infrastructure
Free and open source. Runs on a laptop, a single VM or Kubernetes.
Trusted in production by:
Request, approve, provision, configure
A request comes in with a hostname. When the change needs sign-off, the owner approves it, then Terraform creates the VM and your playbook configures it. If a step fails, the run stops there with its logs, and you restart it from that step.
Each node is a task in one YAML file, versioned in Git.
request_formcore.trigger.Webhook0.4s
owner_approvalcore.flow.Pause2m 31s
kubernetesterraform_applyterraform.cli.TerraformCLI1 artifact3m 05s
ansible_configansible.cli.AnsibleCLI1m 12s
update_cmdbservicenow.Post0.8s0s6m 49s
- request_form+0s0.4sRunningSuccess
- owner_approval+0.4s2m 31sRunningSuccess
- terraform_apply+2m 31s3m 05sRunningSuccess
- ansible_config+5m 36s1m 12sRunningSuccess
- update_cmdb+6m 48s0.8sRunningSuccess
How it fits your tools
No rewrite
Every tool keeps its job.
Your playbooks, modules and scripts run as they are, each in its own container. Kestra runs the order between them.
Around every step
Triggers, approvals, retries and logs.
A schedule, a webhook or a Git push starts a flow. A failed step retries, a pause waits for approval, and every run keeps its logs.
Plugs into your stack
2,600+ open-source plugins, installed the first time a flow uses them.
What your current setup becomes
Nothing is rewritten up front. Each piece moves when you are ready.
| Today | becomes | Kestra |
|---|---|---|
| Cron jobs and systemd timers on scattered hosts | Schedule triggers that run the same scripts, with logs and alerts in one place | |
| Ansible playbooks run from a laptop, Semaphore or AWX | Ansible tasks with the same playbooks and inventories | |
| Terraform or OpenTofu applied from a laptop or a CI job | Terraform and OpenTofu tasks on your existing modules and state backend | |
| Rundeck or Jenkins jobs stored in a database | Flows stored as YAML files in Git |
Using VMware Cloud Foundation?
Move your vRA and vRO workflows out of the Broadcom lock-in
vRA and vRO are no longer sold on their own. They ship inside VMware Cloud Foundation, licensed per core, so the automation bill follows the size of the hypervisor footprint, not how much you automate. The workflows built on them do not move by themselves.
Read the vRA migration guideMigration Assistant
From vRO package to running flows, in four steps
- Read your vRO packageThe open-source Migration Assistant runs on your machine, sends nothing to Kestra, and lists what each workflow calls and which plugins cover it.
- Map each pieceA catalog item becomes a flow with inputs, a vRO action a task or a script, an approval policy a pause, a day-2 action a triggered flow.
- Run bothNew requests go through Kestra while vRA drains. The same vSphere, the same scripts underneath.
- Switch off at renewalOnce the last catalog item runs in Kestra, vRA is not renewed.
Replace vRA without changing how your team works
The lifecycle of a VM in Kestra, one person at a time: who requests it, who approves it, who runs it, and what each of them sees.
Start free. Add Enterprise when the team needs it.
The same flows run on both editions, so nothing is rewritten when you move.
Open sourceFreeEnterpriseOn a call
Engine, UI and API
Every open-source plugin
Schedules, webhooks and event triggers
Retries, error handlers and approval pauses
Flows synced to and from Git
UsersOne shared loginSSO, SCIM and role-based access
SecretsEnvironment variablesVault, AWS, Azure, Google Cloud and more
Audit logs of every action–
Self-service forms (Apps)–
Worker groups in isolated networks–
SupportCommunity SlackSLAs
Rolling it out
to your team?
- We go through the requests and runbooks your team handles today.
- See them run with individual logins, access per team, approvals and an audit trail.
- Requests come in through forms, and the platform team can require approval before anything runs.
Frequently asked questions
Is Kestra really open source?
Yes. The engine, the UI and the open-source plugins are Apache 2.0 and on GitHub, and the open-source edition runs in production on its own. The Enterprise Edition adds what a shared, multi-team instance needs: individual logins, access control, secret managers and audit logs.
How much memory does it need?
Kestra runs on the JVM and needs at least 2 vCPUs and 4 GiB of memory. A single standalone server with Postgres is enough for a homelab or a small team, and server roles split apart when you need to scale.
Does it need root and the Docker socket?
Only for the quickstart. Script tasks run in containers by default, which is why the one-liner mounts the Docker socket and runs as root. You can run tasks as plain processes with the Process task runner instead, or deploy with rootless Podman.
How does the open-source edition handle secrets?
As base64-encoded environment variables prefixed with SECRET_, read in flows with the secret() function, so values never sit in the YAML. Vault, AWS, Azure, Google Cloud and other secret managers connect in the Enterprise Edition.
Kestra, Semaphore, AWX or Rundeck?
Semaphore and AWX put a UI on running playbooks, and Rundeck runs jobs and runbooks. Kestra chains the steps around them: take a Proxmox snapshot, run the playbook, call a webhook, post to Slack, all in one versioned YAML file. You can also call your existing jobs from a flow and move them across later.
What does it cost?
The open-source edition is free. The Enterprise Edition is not priced per execution: the price depends on how broadly it is deployed and the support tier, and we walk through it on the call.
Apache 2.0, self-hosted on your own machines.