# Kestra: Declarative YAML Orchestration for Data, AI and Infrastructure Workflows

> Kestra is an Apache-2.0 Java orchestration platform that keeps every workflow as YAML, whether you edit it in the UI, an API call or Git. This review covers how to install it, how the plugin and task-runner model works, and where it stops being the right tool.

**kestra-io/kestra** — Event Driven Orchestration & Scheduling Platform for Mission Critical Applications

- Repository: https://github.com/kestra-io/kestra
- Website: https://go.kestra.io/home
- Stars: 28,499 · Forks: 3,071
- Language: Java
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/kestra-io-kestra

## What Kestra actually orchestrates, and who ends up using it

Kestra describes itself as an open-source, event-driven orchestration platform for data, AI, and infrastructure workflows. The practical reading of that sentence is narrower than it sounds. Kestra is a scheduler and a dependency engine for units of work that can be expressed as a task: a SQL query, a Python script, an HTTP call, a container run. It does not process your data and it does not host your models. It decides what runs, in what order, with what inputs, and it records what happened.

The intended user is the team that already has cron jobs, Airflow DAGs or a pile of shell scripts and wants them declared in one file format. The README's key features list points at that audience directly: namespaces, labels, subflows, retries, timeouts, error handling, inputs, outputs, variables, conditional branching, backfills and dynamic tasks. Those are the concerns of someone maintaining a pipeline that other people depend on, not someone running a one-off script.

The second audience is less obvious. Because the README states that the YAML definition gets automatically adjusted whenever you change a workflow from the UI or via an API call, Kestra also targets teams where not everyone writes code. An analyst can assemble a flow in the editor and the same flow lands in Git as YAML. Whether that is a benefit or a governance problem depends entirely on your review process.

## The YAML flow, triggers and the plugin model behind them

A Kestra flow is a YAML document with an id, a namespace and a list of tasks. Each task carries a type, and that type is the fully qualified name of a plugin class. The README's hello world example uses io.kestra.plugin.core.log.Log, which is the built-in logging task. Everything else, from database extraction to cloud storage to shell execution, arrives as a plugin with its own type string.

That naming scheme is the whole extensibility story. Plugins are resolved by class name at runtime, so adding a capability means adding a plugin JAR, not changing the core. The README states that plugins let you run tasks anywhere and code in any language, including Python, Node.js, R, Go and Shell, and that execution can be local, over SSH, or scaled out to serverless containers using Task Runners.

Triggers are declared the same way, as a trigger definition inside the flow. The README frames this as unifying scheduled and event-driven automation behind one interface, which in practice means a cron-style schedule and an event listener are both just YAML blocks attached to the same flow. Subflows, retries, timeouts and error handling are likewise declared rather than coded. The trade-off is that anything the plugin set does not model has to be pushed into a script task, where Kestra can no longer see inside it.

## Installing Kestra with Docker and running a first flow

The README's five-minute path is a single docker run against kestra/kestra:latest with the server local command. It binds port 8080, mounts a named volume for storage, and mounts the Docker socket so that container-based tasks can be launched. The socket mount is the part to think about: it gives the Kestra process control over the host's Docker daemon, which is why the README notes the root user setup is intended for development.

```bash
docker run --pull=always -it -p 8080:8080 --user=root \
  --name kestra --restart=always \
  -v kestra_data:/app/storage \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp:/tmp \
  kestra/kestra:latest server local
```

The README gives PowerShell, CMD and WSL variants of the same command for Windows, differing only in line continuation characters and the host path mapped to /tmp. After the container starts, the UI is at http://localhost:8080. That is where you create the first flow.

```yaml
id: hello_world
namespace: dev

tasks:
  - id: say_hello
    type: io.kestra.plugin.core.log.Log
    message: "Hello, World!"
```

Paste that into the editor, save, and run it. The README says to run the flow and see the output in the UI, which is the point of the exercise: the log message appears as a task output rather than on a terminal. For anything beyond a local trial, the repository ships a docker-compose.yml with Postgres 18, a kestra service running server standalone, and a KESTRA_CONFIGURATION block that sets the datasource to jdbc:postgresql://postgres:5432/kestra and switches the repository and queue types to postgres. The README also points to a separate installation guide for Docker Compose, Podman, Kubernetes, AWS, GCP and Azure. The compose file comments that the root user is for development and that the base image runs without root, but the Compose implementation needs root to reach the Docker socket.

## Where the operational weight shows up

The repository layout is the honest description of what you are running. Alongside core, model and plugins there are separate modules for jdbc, jdbc-h2, jdbc-mysql and jdbc-postgres, plus queue and queue-jdbc, repository-memory, storage-local, runner-memory, scheduler, executor, indexer, worker and worker-controller. That is a distributed system with swappable backends, and the local server command hides it by running everything in one process.

The docker-compose.yml makes the dependencies explicit: Postgres for the repository and the queue, local storage under /app/storage, and a stop_grace_period of 6m because Kestra's default termination grace period is 5m and the compose file wants to be sure no active tasks are running. A six-minute shutdown window is a design decision you inherit. If your deployment platform kills pods faster than that, you will lose in-flight tasks, and the compose file's own comment is the evidence that this was considered.

The second constraint is the Docker socket. Running container tasks the way the quickstart does means the orchestrator holds effective root on the host. The README does not present an alternative in the quickstart; Task Runners and Kubernetes execution are mentioned as plugin capabilities, and evaluating them is your job, not something the README walks through.

## Kestra against Airflow, Temporal and n8n

The comparison people actually search for is Kestra versus Airflow. Both are DAG-oriented schedulers, and the difference in approach is where the definition lives. Airflow DAGs are Python files, so the pipeline is code that imports an SDK and runs on a scheduler. Kestra flows are YAML documents interpreted by a Java engine, so the pipeline is data. That changes who can edit it and what a code review looks like, and it also means anything Airflow can express in Python but Kestra has no plugin for becomes a script task inside Kestra.

Against Temporal, the split is different again. Temporal is a workflow-as-code SDK for durable execution inside your own services, where the workflow logic is written in your application's language and the server tracks state. Kestra sits outside your services and calls into them through plugins and HTTP. If you need long-running, stateful coordination inside a service, Temporal's model fits; if you need to stitch together existing systems on a schedule or an event, Kestra's does.

Against n8n, the difference is the interface. n8n is a node-based automation tool where the workflow is primarily a visual graph, aimed at integration and automation work. Kestra offers a visual editor too, but the README is explicit that the orchestration logic is always managed declaratively in code, even when you modify workflows through the UI, CI/CD, Terraform or API calls. That commitment to YAML as the source of truth is the line between the two.

## Licence, maintenance and what an upgrade costs

Kestra is licensed under Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. The repository also carries an owasp-dependency-suppressions.xml and a SECURITY.md, which tells you the project runs dependency scanning and has a stated vulnerability reporting path. Nothing here is legal advice; if you redistribute Kestra inside a product, read the LICENSE file at the repository root rather than a summary.

The last push to the develop branch was on 2026-08-25, the same day as the v1.3.35 release. The recent release list shows two maintained lines at once: v1.3.x and v1.0.x, both receiving releases in August 2026. Running two lines is a real commitment from the maintainers and also a signal that you should know which line you are on before you upgrade, because a fix may land on one and not the other.

Upgrade cost is dominated by the plugin surface, not the core. Because tasks reference plugin classes by fully qualified name, a plugin rename or removal is a breaking change in your YAML. The repository ships a Makefile for building and deploying locally, with targets including build, buildSkipTests, build-frontend and install, and it reads the version from gradle.properties. That is a development path, not an upgrade path: the Makefile's own header says it is intended for development purposes only. The README does not document a rollback procedure for a failed upgrade.

## Conclusion

Adopt Kestra if your team wants scheduled and event-driven pipelines expressed as YAML files that live in Git, and you accept running a Java service with Postgres, a queue and storage behind it. Do not adopt it if you need a managed control plane with no operational surface, or if your workflows are short-lived scripts where a cron entry and a container would do. Before committing, verify three things in your own environment: that the plugin you need exists and is maintained, that your executor choice (Docker socket, Kubernetes or Task Runners) matches your security model, and that the JDBC-backed queue and repository hold up under your concurrency. The docker-compose.yml in the repository is the fastest way to answer all three.

## FAQ

### What does Kestra do?

It is an open-source, event-driven orchestration platform for data, AI and infrastructure workflows. It unifies scheduled and event-driven automation behind a declarative YAML interface, and it runs tasks through plugins that can execute scripts in Python, Node.js, R, Go, Shell and other languages.

### What is Kestra used for?

The README frames it as a way to build reliable workflows from a declarative YAML interface, covering both scheduled and event-driven automation. Typical uses are extracting data from databases, cloud storage or APIs, running scripts in any language, and stitching existing systems together with retries, timeouts and error handling.

### How to install Kestra?

The README's quickstart runs a single docker run command against kestra/kestra:latest with the server local argument, publishing port 8080 and mounting a storage volume plus the Docker socket. The repository also provides a docker-compose.yml with Postgres, and the README links to an installation guide covering Docker Compose, Podman, Kubernetes, AWS, GCP and Azure.

### How to use Kestra?

You create a flow as a YAML document with an id, a namespace and a list of tasks, each task identified by a plugin type such as io.kestra.plugin.core.log.Log. You can build and run the flow from the UI at http://localhost:8080, and the README states the YAML definition is adjusted automatically whenever you change a workflow through the UI or an API call.

### Is Kestra open source?

Yes. The repository is licensed under Apache-2.0, and the README describes Kestra as an open-source orchestration platform. The licence permits commercial use and modification as long as the licence and notices are preserved.

### Is Kestra free?

The software is published under Apache-2.0, so there is no licence fee for the open-source distribution. The README does not describe pricing for any hosted or enterprise offering, and running it yourself still carries the infrastructure cost of the Postgres database, queue and storage it depends on.

## Sources

- [Official documentation](https://go.kestra.io/home)
- [Official README](https://github.com/kestra-io/kestra#readme)
- [Project repository](https://github.com/kestra-io/kestra)
- [Release notes](https://github.com/kestra-io/kestra/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kestra-io-kestra