DEPLOYMENTS

Push to deploy, on your own servers.

Application deploys with the ergonomics of a PaaS and none of the hosting bill. Connect a repository, define the build, and ship through a pipeline that pauses where you tell it to.

Install itSee how pipelines work
GitHub·Buildpacks / Dockerfile·Compose·Kubernetes

THE MANUAL WAY

The deploy script that grew.

THE BASH FILE

Deployment is a 200-line shell script one person understands. It has no dry run, no rollback, and its failure mode is stopping halfway.

THE ROLLBACK

A release is bad and needs reverting. The previous image tag is technically still in the registry, and finding out which one it was takes longer than the outage should have.

THE ENVIRONMENT GAP

Staging and production diverged because they are configured in different places, so a release that passed staging fails on config in production.

WHAT TALOS DOES

A release you can reverse.

Repository-connected builds

Build from a connected repository on push or on demand, producing a tagged image Talos then owns the lifecycle of.

Environments as objects

Staging and production are the same definition with different variables, so the difference between them is inspectable.

One-action rollback

Every release records the artefact and configuration it replaced. Reverting selects a previous release rather than reconstructing one.

Deploy to host or cluster

The same application can target a Docker host or a Kubernetes cluster without a second toolchain.

Release history

Who shipped what, when, from which commit, and whether it was approved — as a list rather than an archaeology exercise.

Gated promotion

Promotion to production can require a second person, with the diff between the running release and the candidate shown at the gate.

talos.internal/deployments/web
Servers
Kubernetes
Frappe
Docker
Databases
Pipelines
Monitoring
Releasesweb · 3 environments
productionLIVE
r-418 · 2.9.1 · 4h ago
stagingLIVE
r-421 · 2.9.2 · 12m ago
r-422 candidateGATED
built · awaiting approval
preview · pr-311ACTIVE
ephemeral · expires in 2d
$ deploy web --to production --release r-422
→ diff vs r-418: 1 image, 2 env vars
⏸ awaiting approval · production gate
✓ approved by k.minos
✓ released · rollback target r-418 recorded

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 rollback target is decided before the deploy, not after.

Rollback usually fails because it is improvised during an incident: someone tries to remember which tag was live, whether the config changed with it, and whether reverting the image alone is enough. Talos records the complete previous state — artefact and configuration together — as part of shipping the new one. Reverting selects that record. It is the same mechanism as deploying, pointed backwards.

Configuration is versioned with the release, so a revert does not leave new env vars behind.
The gate shows the diff against what is actually running, not against the last green build.
A rollback is itself a release, so the history stays linear and attributable.
release history · web · production
r-418 · 2.9.1
live · approved by k.minos
CURRENT
r-405 · 2.9.0
superseded · rollback target
REVERT TO
r-410 · 2.9.0-rc
rolled back after 11 minutes
REVERTED
r-422 · 2.9.2
built · gated
PENDING

RELATED CAPABILITIES

Docker

The registries and stacks these releases build on.

explore →

Pipelines & Gates

Where the approval step actually lives.

explore →

Kubernetes

Deploy the same application onto a cluster.

explore →

Ship one service through it.

Start with staging. The production gate is off until you turn it on.

Install in one commandSee every capability →