Project reference ↗

Kestra helps teams describe and operate workflows made of connected tasks, such as moving data between services or running a sequence of automation steps. It provides a central place to trigger the work and inspect its progress instead of coordinating it through unrelated scripts. It is useful when those tasks need shared operation and recovery. The chosen execution environment still determines where code runs and which credentials or infrastructure it can reach.

Chart ownership

Kestra's Kubernetes documentation identifies two charts published through helm.kestra.io. The kestra chart expects external database and object-storage services. The kestra-starter chart bundles PostgreSQL and Versity for evaluation; upstream explicitly says those bundled dependencies are unsuitable for production. Choose the chart and edition deliberately rather than treating the starter deployment as an availability blueprint.

Before adoption

Define persistent storage, database recovery, secrets and the permissions available to each task. Review runner behavior: Docker-in-Docker and Kubernetes task execution have different isolation and host requirements. Set resource limits and concurrency controls for jobs that invoke expensive services. Test retries and cancellation against real side effects, plus recovery after a worker or database interruption. Verify edition-specific features and registry credentials before deciding how the service will be deployed.

Sources & further reading

  1. Kestra Kubernetes chart documentation
  2. Kestra installation options

Spotted something that needs another look?

Help improve this page →