changeset
Changes through Admiral are staged
Every create, update, and teardown that goes through Admiral is staged in a changeset, planned, and held for approval. A change made in the cloud console still lands, and Admiral reports it as drift.
Deploy infrastructure
and apps together.
Terraform provisions your infrastructure. Helm ships your apps. Admiral is the control plane for both. A self-hosted agent in your account applies the change.
billing-api — zsh
$ admiral app create billing-api
✓ Application created
$ admiral env create billing-api/production
✓ Environment created
$ admiral changeset create billing-api/production --title "Deploy a3f7c21"
✓ Change set cs-3k9x2m7qpl0a opened
$ admiral changeset add cs-3k9x2m7qpl0a billing-db --from cloud-sql:2.1.0
✓ Revision 1 · billing-db (Terraform)
$ admiral changeset add cs-3k9x2m7qpl0a billing-api --from billing-api:1.4.0
✓ Revision 2 · billing-api (Helm)
$ admiral changeset set cs-3k9x2m7qpl0a \
billing-api.image.tag=a3f7c21 \
'billing-api.db.host=!ref billing-db.host' \
'billing-api.db.password_secret=!ref billing-db.password_secret'
✓ Revision 3
$ admiral changeset plan cs-3k9x2m7qpl0a
✓ Run run-4h8k2p9x7m1q planned · 2 components, 5 to create
$ admiral changeset apply cs-3k9x2m7qpl0a
✓ Run run-4h8k2p9x7m1q applied: billing-db, then billing-api (migrations ran first)
Automate the same control plane from CI with the CLI, a GitHub Action, the Terraform provider, the Go and TypeScript SDKs, or the OpenAPI spec, all built on one API.
Terraform stops where Kubernetes starts
Terraform plans and applies. A reconciler watches a branch. The seam between them is yours to own, and it tears in the same three places every time.
Why Admiral is built this wayTwo places to review one change
The Terraform plan lands in one pull request and the chart bump in another. Nothing shows you the combined effect before it reaches an environment.
One runner, every team's permissions
A shared Terraform runner needs the union of what every team provisions. Isolating it means splitting repositories, so most teams live with the union.
Commits invented to trigger a deploy
A reconciler watches a branch, so shipping means editing a file to make it notice. The commit records that a line changed, not that anyone decided to change production.
How it works
Define what should run, stage the change, then approve the plan. Nothing ships before that approval.
1
Define
Your applications, environments, and the components in each. Every environment carries its own values, so dev and prod share a definition without sharing config.
2
Stage
Open a changeset and put the Terraform change and the release that depends on it inside. Nothing has touched the environment yet.
3
Plan, then approve
Admiral plans what it can resolve and shows you the effects. You approve once, and the run applies the graph in dependency order, recording a revision per component.
How Admiral closes the Terraform-to-Kubernetes seam
Admiral sits between your infrastructure code and your deployment tooling, holding the desired state for both halves and the dependencies that cross between them.
graph
Terraform and Helm in one changeset
A database change and the release that depends on it stage together and apply under one approval. The run walks the dependency graph in waves, so you stop reviewing two halves of the same change in two places.
outputs
Outputs wired to values
Workloads reference Terraform outputs directly. As the run applies each wave it captures the real outputs and renders the components downstream against them, so the connection string is never a script you maintain.
desired state
Desired state in a control plane
Git versions the source your components point at. What each environment should run lives in Admiral. Environments stop being overlay folders that drift apart, and a deploy stops being a commit invented to make a reconciler notice.
environments
Define the app once, not per environment
Organized around applications and environments. Define your app once, layer environment-specific config on top, and stop duplicating Kubernetes manifests across dev, staging, and production.
no lock-in
No lock-in
Admiral orchestrates your tools but doesn't replace them. Your Helm charts, Terraform, and raw manifests with templates stay in standard formats that work without Admiral.
Autonomy for app teams. Control for platform teams.
App teams ship their own changes. They take curated components from a catalog and add them to an environment, without knowing every detail underneath. Platform teams own that catalog and the cloud standards those components follow.
For app teams
Ship without filing a ticket
- Create applications and environments and stage your own changes.
- Own the whole stack, from the database to the deployment.
- Revert a deployment by replaying a prior revision.
For platform teams
Curate what teams ship
- Publish a catalog of components application teams add to an environment, starting with Terraform, Helm, Kubernetes manifests, and templated manifests.
- Those components carry the cloud standards you set.
- Scope the self-hosted agent and its credentials.
Take command of your fleet.
No lock-in, no sales calls. Join the waitlist and be first to deploy.