How to Use Kestra: A Beginner's Guide
CodexFuse Team · 2026-10-31T14:59:20.105Z · 11 min read min read
Install Kestra with one Docker command, write your first declarative YAML flow, store secrets the right way, schedule hourly runs, and pick a Blueprint — the full beginner arc.
Learning how to use Kestra starts with one realization: most automation beginners either drown in cron's limitations or pick up a workflow tool that is far heavier than their problem. Kestra sits in the middle — an open-source, event-driven workflow orchestration platform where every automation is a small, readable YAML file called a flow, and every flow runs, schedules, retries, and shows its logs in one clean web UI. This guide is the complete beginner arc: run Kestra with Docker in about four minutes, write your first flow, store secrets the right way, schedule it, and steal a head start from Blueprints.This guide is your complete Kestra tutorial — a Kestra for beginners arc from your first Docker run to a scheduled, secrets-safe flow, assuming nothing beyond basic Docker.
If you are brand new to containers, keep our Docker beginner guide open in a second tab — Kestra's recommended path is a single Docker command, and that guide covers Docker itself.
What is Kestra?
Kestra is an open-source, event-driven orchestration platform for data pipelines, scheduled jobs, and automation workflows. Instead of gluing cron entries, bash scripts, and ad-hoc schedulers together, you declare each workflow as a YAML flow with three required parts — an id, a namespace, and a list of tasks — and Kestra executes it, retries failures, stores outputs, and shows every run in a visual topology. It is language-agnostic: a task can run a Python script, a SQL query, an HTTP call, a Docker container, or a Terraform apply, and its 600-plus plugins cover databases, cloud services, and messaging systems. The official Quickstart guide gets you from zero to a running instance with one Docker command.
Do I need Kestra, Airflow, or n8n?
Beginners usually arrive at this question after comparing names in the orchestration lane. Airflow is the incumbent: you write pipelines as Python DAGs, which is powerful but means every workflow is a Python project and running Airflow itself is a real operations commitment. n8n is the visual no-code option: you drag nodes on a canvas to wire up API automations, which is wonderful for glue work but less natural when your automation is fundamentally code — data transforms, scripts, infrastructure commands. Kestra is the middle path: workflows are declared in simple YAML instead of Python, yet everything (variables, secrets, plugins, scheduling) stays code-first and versionable, while the UI gives you the visual topology, logs, and execution history that pure cron never could.
| Tool | You write workflows in… | Best for | Operating cost |
|---|---|---|---|
| Kestra | Declarative YAML | Data pipelines, scheduled scripts, infra jobs — with a UI to watch them | One container to start |
| Apache Airflow | Python DAGs | Large, Python-centric data engineering teams | Meaningful — scheduler, webserver, metadata DB, workers |
| n8n | Visual node canvas (low-code) | API glue and business automations without much code | One container to start |
The honest rule on Kestra vs Airflow: if your automations are mostly "when X happens, run this script and tell me the result," Kestra fits. If you want to build automations by clicking rather than coding, the no-code lane is n8n — our best VPS for n8n guide covers where to host that one.
What do I need before starting Kestra?
You need two things: Docker on a machine that can stay running, and about ten minutes. This guide follows the Kestra self-host path — one Docker container on your own laptop or VPS, where your data stays with you. Docker Desktop on a laptop is fine for learning; a small VPS is better if you want scheduled flows to survive your laptop being closed. Our what is VPS hosting explainer covers the server option. Kestra itself ships as containers on Docker Hub (kestra/kestra), and the open-source edition is free to self-host — the official README's quick start is literally a one-liner.
How do I start Kestra with Docker?
Run the official Kestra Docker quickstart command below — it is the current, supported first run for Kestra 2.x (the latest release at the time of writing is v2.0.7, released October 20, 2026, per the official GitHub releases page).
docker run --pull=always --rm -it -p 8080:8080 --user=root \
--name kestra \
-v kestra_data:/app/storage \
-v kestra_db:/app/data \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /tmp:/tmp \
kestra/kestra:latest-slim server local
Every flag earns its place — here is the anatomy:
| Flag | What it does | Why beginners need it |
|---|---|---|
--pull=always | Always fetches the newest image | You start on the latest 2.x, not a stale cached image |
-p 8080:8080 | Maps the Kestra web UI to localhost:8080 | This is where you will build everything |
-v kestra_data:/app/storage | Persists flow files in a Docker volume | Your flows survive container restarts |
-v kestra_db:/app/data | Persists the embedded H2 database | Your run history and user account survive restarts |
-v /var/run/docker.sock:… | Shares the host's Docker socket | Required for script and container tasks to run |
server local | Runs the all-in-one local server | Evaluation mode — no PostgreSQL, no clustering |
Two things beginners misunderstand here. First, --rm only removes the container on exit — the kestra_data and kestra_db volumes are preserved, so re-running the same command restores your flows, executions, and login. Second, the latest-slim image ships with no plugins to keep the download small; Kestra auto-installs any plugin the first time a flow needs it (this is on by default for server local), so you never pre-install anything. Wait for the logs to say Main server is running at http://...:8080, then open http://localhost:8080, create your user, and you are in.
To stop: Ctrl+C. To start completely fresh later: docker volume rm kestra_data kestra_db before re-running. If you stop and restart often, graduate to the official Docker Compose setup, which uses PostgreSQL instead of the embedded H2 database.
How do I write my first Kestra flow?
A flow is one YAML file with three required properties: id (the flow's name — it cannot change after the first execution), namespace (your environment grouping, e.g. company.team), and tasks (the ordered list of work). Kestra flows are plain YAML files you can version in Git, and this one runs as-is. Paste it into the Kestra UI's editor (Flows → Create):
id: hello-world
namespace: company.team
tasks:
- id: hello
type: io.kestra.plugin.core.log.Log
message: "Hello from my first Kestra flow"
Press the run button in the editor, open the execution page, and you will see the task turn green with your message in the logs. Then make it slightly real — add a second task that runs a shell command:
id: hello-world
namespace: company.team
tasks:
- id: hello
type: io.kestra.plugin.core.log.Log
message: "Hello from my first Kestra flow"
- id: disk_check
type: io.kestra.plugin.scripts.shell.Commands
commands:
- df -h / | tail -1
The Kestra YAML lesson that trips every beginner: indentation is the syntax. Lists start with - (dash + space), nested keys are indented with exactly two spaces, and a single misaligned line fails validation. Use the editor's built-in validation — or the official Kestra VS Code extension, which runs the instance's real validator on every keystroke — and fix the red underline before running. That one habit saves more debugging time than anything else in this guide.
What is the one rule for secrets in Kestra?
Never hardcode API keys, passwords, or tokens into flow YAML — flows get committed to Git, screenshared, and copied into forum posts, and a leaked key is a leaked key. Kestra's rule is the secret() function: store the sensitive value outside the flow, reference it at runtime with {{ secret('NAME') }} inside any task property, and the value is injected when the flow executes.
The storage depends on your edition, and this matters for beginners. In Enterprise Edition, you add secrets under Namespaces → [namespace] → Secrets (or Tenant → Secrets) with a key name, description, and tags; the UI even hands you the ready-to-paste Pebble expression like "{{ secret('API_TOKEN') }}", and backends can be AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or Kestra's own store. In the open-source edition there is no secret store: Kestra reads base64-encoded environment variables prefixed with SECRET_ and exposes them through the same secret() function. So if you set SECRET_API_TOKEN (base64-encoded) in the container environment, {{ secret('API_TOKEN') }} resolves it — same YAML, different backing. That keeps secrets out of your flows either way.
How do I schedule a flow to run every hour?
Add a triggers block with a Schedule trigger using cron syntax. This turns the disk-check flow into a self-running hourly monitor:
id: hourly-disk-check
namespace: company.team
tasks:
- id: disk_check
type: io.kestra.plugin.scripts.shell.Commands
commands:
- df -h / | tail -1
triggers:
- id: every_hour
type: io.kestra.plugin.core.trigger.Schedule
cron: "0 * * * *"
The cron string 0 * * * * means "at minute 0 of every hour." Schedules, webhooks, and file-watch triggers are all declared the same way — no separate scheduler service to configure, no cron daemon to babysit. Backfill, pause, and resume all live in the same UI as your executions.
How do blueprints work in Kestra?
Blueprints are the head start most beginners skip: the Kestra blueprints gallery hosts hundreds of community and official flow templates at kestra.io/blueprints covering data ingestion, infrastructure automation, notifications, and ETL. The pattern, confirmed in the official Airbyte integration docs, is: open Blueprints in the Kestra UI, search for your use case (e.g. "Airbyte" for data syncs), select the blueprint, click Use, adjust the connection IDs and names in the editor, save, and trigger. A blueprint is never the finished product — it is a working skeleton that teaches you the plugin's shape while doing something useful. The infrastructure-automation blueprint, for example, wires Docker builds, Terraform runs, and container execution into one flow, which is exactly the shape a DevOps beginner would otherwise spend a week discovering.
What mistakes do beginners make with Kestra?
Five, and they are all avoidable once you know the pattern:
| Mistake | What happens | The fix |
|---|---|---|
| Skipping the Docker socket mount | Script and container tasks fail to start | Keep -v /var/run/docker.sock:/var/run/docker.sock in your run command |
| Inconsistent YAML indentation | Validation errors, flows that will not save | Two spaces, dash + space for list items, validate before running |
| Hardcoding secrets in flows | Keys leak into Git and screenshots | {{ secret('NAME') }} — SECRET_ env vars in OSS |
| Running production on the H2 database | Embedded DB is not meant for multi-user scale | Move to the Docker Compose setup with PostgreSQL |
| Rebuilding what a blueprint already does | Hours lost on solved problems | Search Blueprints first, then customize |
What's next after my first flow?
Follow the official tutorial path to add inputs, outputs, and more task types — inputs turn a static flow into a reusable tool your team can trigger with parameters. If you live in an editor, install the official Kestra VS Code extension: live validation, {{ }} autocompletion, running flows from the editor with streamed logs, topology previews, and namespace-file browsing. Take the guided courses at Kestra Academy when you want structure. And if you use AI coding tools, Kestra ships an MCP server plus Agent Skills and kestractl so Claude Code, Cursor, or Codex can write and deploy flows for you.
Sources
- Kestra Quickstart Guide — official Docker run command, volumes, slim image, plugin auto-install,
server local(accessed 2026-10-31) - Kestra Secrets documentation —
{{ secret('NAME') }}syntax, OSSSECRET_env vars, Enterprise backends (accessed 2026-10-31) - kestra-io/kestra releases — v2.0.7 released 2026-10-20 (accessed 2026-10-31)
- coursedrill.com — What is Kestra — beginner guide with hello-world flow and Kestra-vs-Airflow/Dagster comparison (accessed 2026-10-31)
- Airbyte — Using the Kestra Plugin — official Kestra plugin, blueprint usage pattern (accessed 2026-10-31)
- Railway — Deploy & Host Kestra — Kestra-vs-n8n/Airflow/Dagster/Temporal/Argo comparisons (accessed 2026-10-31)
Frequently asked questions
Is Kestra free?
Yes — Kestra is open source and free to self-host with Docker, and the open-source edition includes the UI, scheduling, plugins, and executions. Enterprise Edition adds features like dedicated secret stores, and there is a managed cloud option, but everything in this beginner guide runs on the free self-hosted edition.
Is Kestra better than Airflow?
It depends on your team. Airflow remains the standard for large Python-centric data engineering teams writing pipelines as code. Kestra is better for teams that want declarative YAML instead of Python, a gentler operations footprint (one container to start), and a UI-first experience for building and monitoring flows. Many beginners find Kestra productive in an afternoon where Airflow takes days to stand up.
Can Kestra replace cron?
For most use cases, yes — and that is its most common beginner win. A Schedule trigger with cron syntax replaces the cron entry, and you gain retries, logs, alerts, backfill, and a visible execution history. Where Kestra goes further is chaining: one flow can run a script, pass its output to the next task, branch on results, and notify you — things cron was never designed to do.
How is Kestra different from n8n?
n8n is visual and no-code-first: you build automations by connecting nodes on a canvas, which is ideal for API glue work. Kestra is declarative-code-first: you write workflows in YAML, which suits engineers whose automations are scripts, SQL, and infrastructure commands. They overlap on scheduling and webhooks, but they optimize for different users — the Kestra vs n8n question is code-first vs click-first, so compare them on your own problem, not on feature lists.
Do I need Kubernetes to run Kestra?
No. Beginners should start with the single Docker command in this guide. Kubernetes becomes relevant only when you outgrow one machine — Kestra supports task runners that offload work to Kubernetes, but the core server runs happily in Docker or Docker Compose on a single VPS.