How pipelines work

Reusable multi-stage delivery definitions, runs, and triggers.

Repository-validated operator guidance View source ↗

#Definitions and runs

A pipeline definition names ordered stages (pull, build, deploy, compose, health_check, notify, approval, sleep, script), each with timeouts, retries with doubling backoff, and continue-on-failure flags. Triggering a run freezes a stage snapshot, so later definition edits cannot rewrite history. Runs report queued, running, completed, failed, cancelled, or awaiting_approval with progress and per-stage logs and artifacts (capped at 64 MiB).

FLOW

Pipeline execution

01Definition savedfreeze snapshot

02Run triggeredrun

03Stages executepause

04Approval gaterecord

05Completed or failed

#Actions

Action	Does
pull	Fetch a repository into a workdir.
build	Build an image from a source (Dockerfile or builder).
deploy	Execute an existing deployment record.
compose	Deploy inline YAML or a repository Compose file to a node.
health_check	Poll a URL or host:port until a threshold passes.
notify	POST to a URL with run variables.
approval	Pause the run until a human approves or rejects.
sleep	Wait a fixed duration.
script	Execute a command inside a node container — never on the control plane.

#Triggers

Manual is the default. Webhook triggers mount a public HMAC-signed endpoint only when PIPELINE_WEBHOOK_SECRET is set. Schedule triggers evaluate cron each minute. Concurrency defaults to 2 workers.

Under /api/v1 (admin)

GET|POST /pipelines            definitions
GET|PUT|DELETE /pipelines/:id
POST /pipelines/:id/runs        trigger
GET  /pipeline-runs            list (?pipelineId&status)
POST /pipeline-runs/:id/cancel|/retry
POST /pipeline-runs/stages/:stageId/approve|/reject