PIPELINES & GATES

Nothing ships without a human.

Multi-stage pipelines that stop mid-flight until a second person approves. Not a checkbox before the run starts — a pause at the step that matters, with the exact change in front of the approver.

Install itSee the security model
BullMQ·SSH·Ansible·Terraform

THE MANUAL WAY

Why approvals usually fail.

THE RUBBER STAMP

Approval happens in a chat message before anyone knows what the change will be. By the time it runs, the approval refers to something that no longer exists.

THE SINGLE OPERATOR

One engineer has the credentials to do the irreversible thing and no technical reason to pause. The control is that they are careful.

THE MISSING RECORD

Six weeks later, nobody can establish who authorised the change — only that it happened.

WHAT TALOS DOES

Control that survives a bad day.

Multi-stage pipelines

Compose build, test, approve and deploy stages. Each stage is a job with its own logs and its own retry.

Gates that pause mid-run

The pipeline stops at the gate with the pending change shown, rather than asking for permission before anything is known.

Two-person verification

The approver must be a different person, and must independently hold the permission for the action they are approving.

Diff at the gate

What will change is rendered against what is currently running, so approving is an informed act.

Retry without rerun

A failed stage is retryable on its own. A four-stage pipeline does not restart because stage three timed out.

Recorded outcomes

Who proposed, who approved, what ran, and what it produced — one entry, permanently attributable.

talos.internal/pipelines/release
Servers
Kubernetes
Frappe
Docker
Databases
Pipelines
Monitoring
Pipeline · releasestage 3 of 4 · awaiting approval
1 · buildPASSED
image 2.9.2 · 1m 48s
2 · testPASSED
412 tests · 0 failures
3 · approveWAITING
requires a second person
4 · deployBLOCKED
blocked by gate
⏸ gate · production deploy
→ proposed by j.pallas
→ diff: image 2.9.1 → 2.9.2, 2 env vars
✕ self-approval refused · same actor
✓ approved by k.minos · resuming

HOW IT RUNS

Every action is a tracked job.

Requestyou, API or schedule
Queuegated if required
the Sentinelbackground worker
AdapterSSH · Ansible · Terraform · API
Your infrastructurelogs stream back live

WHAT MAKES THIS DIFFERENT

The approval refers to the change, not to the intention.

A gate before the pipeline starts approves a plan. A gate inside the pipeline approves a fact. Talos pauses at the stage itself, with the built artefact and the computed diff already in hand, so the approver is looking at what will actually happen rather than at what someone said they were going to do. The pipeline holds its place until they answer.

Approving does not substitute for permission — the approver must independently be allowed to perform the action.
The same actor cannot propose and approve, so a gate is never satisfiable alone.
A rejected gate stops the pipeline in place, leaving everything before it intact and retryable.
gate · production deploy
proposed
j.pallas · release r-422
09:41
diff computed
1 image, 2 env vars, 0 schema
READY
self-approval blocked
proposer cannot approve
REFUSED
approved
k.minos · holds deploy permission
09:44

RELATED CAPABILITIES

Deployments

The releases these pipelines ship.

explore →

Databases

Gated restores over live data.

explore →

AI Engine

AI proposals use the same gate before anything executes.

explore →

Put a gate in front of one thing.

Start with restores or production deploys. Everything else can stay ungated.

Install in one commandSee every capability →