teknetik

Kestra tutorials

Kestra is an open-source orchestrator. Flows are written as declarative YAML, run on a schedule or a trigger, and keep a run history you can inspect afterwards. These guides use it where work needs a clear route across tools and a visible place for a person to decide.

See the guides All guides
Abstract operations desk with blank workflow cards, navy rails and teal routes ending at a human review point.

Useful when the route matters as much as the result.

01

Work that runs to a schedule or a trigger

Nightly reports, inbound webhooks and queued jobs that currently depend on somebody remembering.

02

Steps that cross more than one system

A route between tools you can point at, with retries and a run history instead of a private script.

03

Handovers that need a named approver

A flow can prepare the work, pause, and wait for a person before anything outside the workflow changes.

If one person runs one task in one system, a scheduled script or a built-in feature is usually the proportionate answer. Reach for an orchestrator when several steps, systems or people are involved.

Build visible workflows before you scale them.

Every Kestra guide follows the same three stages, so a pilot can be stopped or reversed at any point without unpicking a live process.

  1. 01

    Prepare the process

    Define the trigger, approved source, accountable owner and exception route.

  2. 02

    Build the flow

    Connect only the steps needed for a controlled pilot with safe test data.

  3. 03

    Operate safely

    Review run history, handle failures and improve only when evidence supports it.

A row of blank workflow tutorial cards connected by a teal route across a navy operations grid.

Start with one safe route.

Prove the dry-run and approval path on test data before allowing a flow to change an outside system.

Four things to settle first.

Talk through a workflow before building it
  1. 01Use a sandbox project or repository, never live records.
  2. 02Keep a dry-run switch on until the output has been checked by hand.
  3. 03Give each credential the narrowest scope the flow actually needs.
  4. 04Decide who reads the failures before the first scheduled run.