Deploy Terraform and Helm together
Admiral keeps both. What it replaces is the glue between them - the second pipeline, the shared runner, and the review that happens in two places for one change.
A database and the release that reads from it are one change. Terraform plans and applies one half; a reconciler watches a branch for the other. Each review is sound on its own, and nobody reviews the thing that is actually happening. Admiral closes that gap without asking you to give up either tool: it holds the desired state for both halves and the dependencies that cross between them.
Both halves go in the same changeset
The module change and the release that reads from it are staged together, scoped to one environment. Nothing has touched the environment yet, and there is no edit-this-component call to reach for instead, because there is none to write.
The plan resolves what it can and defers the rest
Admiral plans every component it can resolve up front and shows you the effects. Work that depends on an output no run has produced yet is deferred rather than guessed at, so the plan you approve does not contain invented values.
The run walks the dependency graph in waves
You approve once. The run then applies components in dependency order, so the database exists before the release that reads from it. As each wave finishes, Admiral captures the real Terraform outputs and renders the components downstream against them.
A revision per component records what deployed
Each component that applies gets an immutable revision holding exactly what shipped and the values it rendered against. Reverting a deployment replays a prior revision rather than reconstructing it from a branch.
What you keep
Admiral orchestrates your tools rather than replacing them. Adopting it is a change of workflow, not a rewrite, and leaving takes your modules and charts with you.
- HCL, your modules, your providers, and your registry. Admiral runs the Terraform you already have.
- Your Helm charts and raw manifests, in standard formats that still work without Admiral.
- Git, versioning the module and chart source your components point at.
- Your cloud console. Admiral surfaces out-of-band changes as drift rather than preventing them.
What it costs
- An approved changeset is not an atomic apply. It is a planning artifact and an authorization boundary, so a component that fails partway through a dependency chain leaves the components already applied in place, blocks its dependents, and ends the run as partially failed. Recovering means another changeset to fix forward or revert.
- Scoping is per agent rather than per component, so the boundaries you get are the ones you drew at install time. Narrower boundaries mean more agents to install, monitor, and keep running.
- Desired state lives in Admiral, so what an environment should be running is no longer answerable from a repository checkout you already have open.
Read the model, not the pitch
The reasoning behind treating a changeset as the unit, keeping desired state out of Git, and running execution inside your own boundary is argued in full on Why Admiral. The mechanics are in the docs: the run state machine, how a plan defers work it cannot yet resolve, and how a partial failure surfaces and gets recovered.