Introduction
Overview
Admiral ships an application and the infrastructure it depends on in one reviewed change, and agents on your own infrastructure do the work.
The database, the network, and the IAM role have to exist before the workload can start. A change to the database is a change to the application that uses it.
Today you ship those through two products. Tools like Atlantis, Terraform Cloud, and Spacelift plan and apply the infrastructure. Tools like Argo CD and Flux deploy the application. You review each on its own. A database address reaches the application only if you copy it, or if a pipeline you maintain copies it for you.
Admiral puts both in one changeset, a reviewed batch of changes to one environment. The Terraform component applies, Admiral records its outputs, and the workload renders against those values before it applies.
Admiral plans, applies, and deploys the components you add to it. Anything you have not added keeps running in the tools you use today, so you can move one component at a time.
What does Admiral do?
- You stage infrastructure and workloads in one changeset, plan them, and apply them in waves. Each component applies only after the components it depends on have applied. A change made outside Admiral shows up as drift.
- Agents pull their work and run it on infrastructure you operate. A Terraform agent pulls a Terraform module and runs plan and apply. A Kubernetes agent pulls manifests and reconciles them. Admiral renders a Helm chart into manifests before that pull, and passes raw manifests through as written. Admiral needs no inbound access to your clouds or clusters.
- A component declares what it depends on and passes outputs to the next one. The upstream apply finishes, and the downstream renders against the real values.
- A Terraform component is a module you publish as it is. You do not wrap modules in a root module that wires them together, because Admiral does that wiring. One module serves many environments and applications unchanged.
- Each Terraform component keeps its own state, without the
terraform_remote_statewiring that split states usually need. Plans for different components run side by side instead of queuing on one state lock. Admiral hosts that state, or the component keeps the backend it already uses. - Agents use workload identity. A Kubernetes agent proves who it is with its cluster's service-account token, and a Terraform agent deploys with the identity of the machine it runs on, such as an IAM role. Admiral and an agent share no long-lived secret, so there is nothing in Admiral to store or rotate.
Where should I start?
Architecture
Where your code runs, what the control plane keeps, and what your network must allow.
Get Started
The walkthrough, from a local cluster to production. Still being written.
Concepts Overview
The resources, who owns them, and how a change becomes a deploy.
How are the docs organized?
- Get Started is the walkthrough, from connecting your first cluster to promoting to production.
- Concepts is the resource model, including applications, the registry, state, changesets, and drift.
- Agents covers where a Terraform agent and a Kubernetes agent run, how each proves who it is, and what each pulls.
- Access covers how people and machines authenticate.
- Security covers how secrets are referenced and resolved.
- Tools & SDKs covers the CLI, the Terraform provider, and the Go SDK.
- API Reference is the REST API contract.