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

SEE IT RUN

Deploying an app with Talos1:45

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 whose lifecycle Talos then manages.

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, in one searchable list.

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
Cloud
Kubernetes
Docker
Databases
Frappe
Pipelines
Monitoring
MLOps
Proxy
DNS & SSL
MCP
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
Queueapproval if required
Job runnerbackground worker
ExecutionSSH · 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 currently 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 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 →