Kestra

Last reviewed Aug 26, 2026 · 878 words

Kestra competes with Apache Airflow and Prefect, not with Zapier, whatever the marketing says. It is a scheduler and orchestrator for jobs that run scripts, move data, call APIs, and depend on each other, declared in YAML and executed by a Java server on top of Postgres. If what you actually want is "when a form is submitted, post to Slack and add a row to a sheet", n8n will have you done in 10 minutes and Kestra will have you reading plugin docs. Pick it for pipelines, not for glue.

The YAML is the product

A flow is a namespaced YAML document with tasks and optional triggers, and this is a complete, runnable one:

id: nightly_backup_report
namespace: homelab
tasks:
  - id: dump
    type: io.kestra.plugin.scripts.shell.Commands
    taskRunner:
      type: io.kestra.plugin.core.runner.Process
    commands:
      - df -h /srv/backups | tail -n 1
  - id: notify
    type: io.kestra.plugin.core.log.Log
    message: "Backup volume: {{ outputs.dump.vars }}"
triggers:
  - id: schedule
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "0 6 * * *"

Every task is a plugin class named by its fully qualified type, which looks verbose and turns out to be the thing that makes flows greppable and versionable. The editor in the UI autocompletes those types and validates the document as you type. Flows can be edited in the UI or pushed from Git, and the Git-first mode is the one to use, because the UI edits are otherwise the only copy.

Triggers are where the "event-driven" claim comes from: cron schedules, webhooks, polling a queue or bucket for new objects, or another flow finishing. Outputs from one task feed the next through the {{ }} templating, and subflows let you compose larger pipelines from small ones.

Postgres is the backend, and 1 GB is a floor not a target

The catalogue says 1 GB minimum and Hard difficulty. Both are fair. The standard install is two containers, Kestra itself and Postgres, and the Java process alone settles around 700 MB to 1 GB at rest before you run anything:

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: kestra
      POSTGRES_USER: kestra
      POSTGRES_PASSWORD: change-me
    volumes:
      - ./pg:/var/lib/postgresql/data
  kestra:
    image: kestra/kestra:latest
    command: server standalone
    ports:
      - "8080:8080"
    volumes:
      - ./kestra-data:/app/storage
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      KESTRA_CONFIGURATION: |
        datasources:
          postgres:
            url: jdbc:postgresql://postgres:5432/kestra
            username: kestra
            password: change-me
        kestra:
          repository:
            type: postgres
          queue:
            type: postgres
          storage:
            type: local
            local:
              basePath: /app/storage
    depends_on:
      - postgres

The Docker socket mount is there because the default way to run a script task is inside a fresh container per run, which is a good isolation model and a fair thing to be uneasy about. The Process task runner in the flow above avoids it. On a homelab box give the pair 2 GB and it is comfortable; the catalogue's "heavier resource needs" con is real next to n8n's 300 MB.

Plugins are broad, secrets are the open-source gap

There are several hundred plugin types across databases, cloud storage, message queues, dbt, Docker, Kubernetes, and every scripting language you would want. Coverage of data-engineering tools is where it beats n8n outright; coverage of consumer SaaS is where it loses. Secrets in the open-source edition are environment variables named SECRET_NAME with base64-encoded values, referenced as {{ secret('NAME') }}. That is workable and slightly ugly. Proper secret backends, SSO, RBAC, and audit logs sit in the paid Enterprise edition, which is the usual split and is worth knowing before a team standardises on it.

Where it fits in the self-hosted stack

Kestra earns its RAM in a homelab when you have three or more scheduled jobs that depend on each other and you are tired of cron plus shell scripts plus a Telegram bot for failures. Nightly database dumps that must finish before the offsite sync starts, a media pipeline that transcodes then updates a library, a data pull that loads Postgres then refreshes a dashboard. The UI shows every execution, its logs, and its outputs, retries are a one-line addition to any task, and a failed nightly run sends a notification through whichever plugin you configure, from email to Slack to a plain webhook. That replaces the shell-script-plus-bot arrangement most homelabs grow by accident. For anything smaller, cron is fine, and for anything SaaS-shaped, the automation category is mostly better choices; the Zapier alternatives page walks through them.

Against Apache Airflow specifically, Kestra wins on setup time and on not requiring Python to define a pipeline. Airflow wins on the depth of its operator ecosystem and on the number of engineers who already know it.

What I'd do

If your jobs are data-shaped and you can write YAML: Kestra with Postgres, flows in a Git repo, 2 GB of RAM, and the Process task runner unless you specifically want per-run containers. If your jobs are SaaS-shaped: n8n. If your team already runs Airflow, stay there. Kestra is Apache-2.0, well past 27,000 stars, and the cleanest orchestrator to read six months after you wrote the flows, which is the property that matters most.