Hangar

SDLC · Stage 05 of 07

Release and deploy

No cluster holds another cluster's credentials. The only thing that crosses a boundary is a reviewed, merged commit.

Principles: Every change is a reviewed commit, Event-driven by default

Shipping should feel calm. Getting a change in front of customers ought to be a reviewed, reversible step you can explain to anyone, not a moment everyone holds their breath.

Deploy and release answer different questions, so they get different rigor. Deploy is the fast inner loop to a lower environment: did my change work at all? Release is governed promotion: the release stage never touches a cluster. It opens a pull request against the app's GitOps repo, carrying the exact image digest that already passed test and deploy (never rebuilt). Governance gates report as required checks, a human reviews, and ArgoCD's own sync is the only thing that ever changes the target cluster.

Every upper cluster runs its own ArgoCD watching the same GitOps repo, instead of one ArgoCD holding credentials for them all, because a remote-cluster credential is just the dev-to-prod blast radius moved somewhere else. Outcomes come back to dev as events. The first version used ArgoCD Notifications; live testing showed it fired on any sync, including drift correction with no release involved, so it was replaced with sync hooks that fired only when a release really converged. Since October 2026 the Rollout itself posts a small fact on every phase change, and the control plane decides what it means (ADR-0021). When a release is done, Tower writes its outcome into the release record in git.

Workloads roll out as Argo Rollouts with analysis templates from a curated library, and the lower/upper environment split is enforced by a separate AppProject, not just by folder names.

Where Hangar does this

Swimlane · 06 of 07 · Deploy and release Deploy and release: different questions, different rigor Open full page ↗
Deployment · 07 of 07 · Multi-cluster One dev control plane, and an ArgoCD in every cluster Open full page ↗
Layer stack · 05 of 10 · Multi-cloud platform One platform surface across every cloud Open full page ↗

And for AI agents

Durable changes are commits. Ephemeral runs are direct requests.

An agent's durable write is a git write, and it goes through the same release path as everyone else's. Only its run, which is short-lived, stateless and rebuildable from git, is created directly, as a narrowly scoped Crossplane XR on dev clusters. Upper clusters get neither.

Architecture · 02 of 19 · Two planes Durable changes are commits. Ephemeral runs are direct requests. Open full page ↗
Secure paved road · 03 of 19 · The write path The durable path: an agent's write is a git write Open full page ↗

The full Autopilot walkthrough →