06 · RELEASE MANAGER

You approve the exact change that goes to production.

Heimdall doesn't deploy: it commits to your manifest repository, and the Argo CD you already run applies it. Who asked, who approved, when it was allowed and the exact commit are all on record.

Talk to engineering

Opens a WhatsApp chat. Prefer email? [email protected]

What it does

Where versions come from

A release published in the code repository becomes a version of the Component, by webhook or by periodic polling. The image reference is built and frozen when the release is recorded.

Where each version is written

For each Component and environment, a target names the file, the YAML document and the value's path. A list item is chosen by name, never by position — a sidecar added at the top doesn't shift the version into the wrong container. Outside the value that changes, nothing in the file moves.

The diff is what's approved

Approvers see the one-line change, and the decision is bound to a fingerprint of it. At deploy, the Agent reads the file again and the change is rebuilt; if the fingerprint doesn't match, the commit is refused, naming what changed.

Who approves, and for how long

Per environment: named people or groups, and a quorum. "Staging doesn't ask, production does" is configuration. The decision has a deadline to be made and a deadline to be used — 4 hours by default. Nobody approves their own request.

The gate, asked twice

A deploy window in an IANA time zone, a freeze with a mandatory reason, and the image in the registry: the gate answers every condition, including the ones that allow. It is asked when the deploy starts and again the instant before the commit — a window that closes in between stops the commit.

Rollback, with no destination to choose

One command, with a reason, restores the version that Component had in that environment before the last deploy — always a version that already went through approval. It doesn't wait for approval or a window, goes through a freeze, notifies the approvers and opens the incident. It undoes one step.

What Heimdall never claims

There is no "in production" state. committed means the commit exists. What Argo CD did with it, heimdall release drift asks Argo CD — and refuses to answer about an Application that doesn't watch the file Heimdall writes.

How it works

One deploy, from approval to commit:

The API asks the gate.
The Agent reads the manifest in your repository.
The change is rebuilt from the file read and compared with the approved one. A file that changed in between is refused.
The API asks the gate again, because the window may have closed while the Agent was reading.
The Agent commits, fenced by the version of the file it read. Your Argo CD applies it, at its own pace.

TERMINALheimdall release plan

$ heimdall release plan 2a5e9fa9-e606-4306-883e-842f4082901d --env 99f09f2c-e1ed-8cea-8a5d-4e3fe36507fc --release 394f1285-e26f-4f00-ab60-d50e7e5a0d09 --manifest ./deployment.yaml
✓ Deploying 6.7.0 would change one line of apps/checkout/deployment.yaml

Release:     6.7.0 (394f1285-e26f-4f00-ab60-d50e7e5a0d09)
Branch:      (the connection's default branch)
Value path:  spec.template.spec.containers[name=checkout-api].image (image_reference, document 0)
Line 22:      ghcr.io/stefanprodan/podinfo:6.6.0 -> ghcr.io/stefanprodan/podinfo:6.7.0
Blob:        dced867f50e738f55f2bd19fc54a8d1fce203765
Fingerprint: c7056bc6c5d849686a8c79e2433bfe70a54656ffe6f5aca369298cd8d9781417

--- a/apps/checkout/deployment.yaml
+++ b/apps/checkout/deployment.yaml
@@ -19,7 +19,7 @@
         - name: istio-proxy
           image: docker.io/istio/proxyv2:1.23.0
         - name: checkout-api
-          image: ghcr.io/stefanprodan/podinfo:6.6.0   # versão atual
+          image: ghcr.io/stefanprodan/podinfo:6.7.0   # versão atual
           ports:
             - containerPort: 9898
           readinessProbe:

Real output of heimdall release plan: the change the approver will see.

Where the data lives

Everything runs in your infrastructure. The split below matters inside your company: it says who on your team can reach what.

Release Manager: where the data lives
IN THE AGENT	IN THE API, WHICH IS YOURS
Reading and committing to the manifest repository, with a token of about one hour, scoped to one repository, never stored. Your Argo CD's address, certificate and token.	Sources, targets, approvers, windows and freezes. Every request, every vote and the fingerprint of what was approved. The history of deploys and rollbacks. The manifest that was read passes through the API, which rebuilds the change.

See security

Who approves what

Release Manager: who approves what
ACTION	WHO
See releases and ask the gate	every member
Configure source, target, approvers and window; request a deploy; deploy and roll back	`owner` and `admin`, by default. A `policy` extends it to whoever your team decides
Approve	the Component's named approvers in that `environment` — never the requester
Waive a request's window	a named approver, with a reason — never the requester. The freeze and the image check still apply
Declare and end a freeze; change the approval deadline	`owner`

With the other modules

01

Catalog

Target, approvers, window and freeze are set per Component and per environment.
07

Incident Manager

Every rollback opens an incident, dated from when the undone version landed — repair time starts when the problem got in, not when someone reacted.
03

Secret Manager

The Argo CD token is a secret in the Agent.

Talk to the people who build Heimdall.

Tell us how your engineers store secrets and reach the database today. We'll answer with what Heimdall would put under rules first, and how the deployment would get there.