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.

ToolYou write workflows in…Best forOperating cost
KestraDeclarative YAMLData pipelines, scheduled scripts, infra jobs — with a UI to watch themOne container to start
Apache AirflowPython DAGsLarge, Python-centric data engineering teamsMeaningful — scheduler, webserver, metadata DB, workers
n8nVisual node canvas (low-code)API glue and business automations without much codeOne 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:

FlagWhat it doesWhy beginners need it
--pull=alwaysAlways fetches the newest imageYou start on the latest 2.x, not a stale cached image
-p 8080:8080Maps the Kestra web UI to localhost:8080This is where you will build everything
-v kestra_data:/app/storagePersists flow files in a Docker volumeYour flows survive container restarts
-v kestra_db:/app/dataPersists the embedded H2 databaseYour run history and user account survive restarts
-v /var/run/docker.sock:…Shares the host's Docker socketRequired for script and container tasks to run
server localRuns the all-in-one local serverEvaluation 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:

MistakeWhat happensThe fix
Skipping the Docker socket mountScript and container tasks fail to startKeep -v /var/run/docker.sock:/var/run/docker.sock in your run command
Inconsistent YAML indentationValidation errors, flows that will not saveTwo spaces, dash + space for list items, validate before running
Hardcoding secrets in flowsKeys leak into Git and screenshots{{ secret('NAME') }} — SECRET_ env vars in OSS
Running production on the H2 databaseEmbedded DB is not meant for multi-user scaleMove to the Docker Compose setup with PostgreSQL
Rebuilding what a blueprint already doesHours lost on solved problemsSearch 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

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.

Featured on Twelve Tools Launch Llama Tools Launch your MCP