---
title: "Overview"
canonical: "https://admiral.io/docs/api"
description: "Reference for the Admiral REST API, generated from the OpenAPI spec. Browse endpoints by resource group, then drill into operations for request and response."
---
# Overview
This section is generated from the Admiral OpenAPI specification.
Browse by resource group in the sidebar, then drill into individual operations for request and response details.
---
title: "Changelog"
canonical: "https://admiral.io/docs/changelog"
description: "What has shipped in Admiral, by month, newest first."
---
# Changelog
## What is not ready yet?
* **Applying a changeset.** You can stage a changeset, have Admiral render it, and plan it. Apply is next.
* **The Terraform agent.** The Kubernetes agent has shipped. The Terraform agent has not.
* **Hosted Terraform state.** The backend at `api.admiral.io`, and the CLI's Terraform credentials helper, come with the Terraform agent.
* **The [Get Started](https://admiral.io/docs/get-started/overview.md) walkthrough.** Steps 1 and 2 work today. Steps 3 to 5 wait on apply and the Terraform agent.
## September 2026
September added the component registry, changesets, and the Kubernetes agent, so a team can publish a component, stage it in an environment, and have its cluster's agent plan it.
* **Component registry.** `admiral component publish` publishes every component a repository declares in `admiral.yaml`. A registry pull copies a module or chart you do not own, using a stored credential when the source is private. Revisions are content-addressed and labeled by tags, and a revision can be deprecated or revoked after it is published. Each revision records its inputs, with each input's validation, whether it accepts null, and a chart's `values.schema.json`.
* **Changesets.** Stage changes to one environment, have Admiral render them, read what it rendered, and plan them with the environment's agent.
* **Kubernetes agent.** Admiral trusts a cluster through its service-account token issuer or keys you upload, with no shared secret. An agent can be granted to an organization, a team, an application, or one environment.
* **Organizations and access.** Environments, invitations, and personal and service account API keys. A key stops working when its owner leaves the organization.
* **Tools.** The CLI covers applications, environments, components, credentials, and changesets. The Terraform provider adds `admiral_environment`.
---
title: "Architecture"
canonical: "https://admiral.io/docs/architecture"
description: "Admiral hosts the control plane, and agents on your infrastructure pull their work, so Admiral needs no path into your cloud or clusters."
---
# Architecture
Admiral hosts the control plane and operates it for you. Agents run on infrastructure you operate and pull their work from it. Admiral never connects into your clusters or runs your Terraform. It connects out only to fetch: a registry pull reads from a source you name, and for a GKE or EKS cluster Admiral reads the issuer's public signing keys.
## Where does my code run?
On an agent. Admiral only renders a Helm chart into manifests, and every plan and apply runs on an agent. You publish each component's code to the [registry](https://admiral.io/docs/concepts/registry.md) with `admiral component publish`, as a **bundle**, the packed bytes of a Terraform module, a Helm chart, or raw manifests. A published bundle is an immutable **revision**, identified by its digest. A Terraform agent pulls the bundle and runs it. A Kubernetes agent pulls the manifests Admiral renders from it.
```mermaid
flowchart LR
subgraph agents[" "]
direction TB
TA["Terraform agent
a machine you operate
that can reach your cloud"]
KA["Kubernetes agent
runs in
the cluster"]
end
S["Admiral
control plane"]
TA -->|pulls the bundle| S
KA -->|pulls manifests| S
style agents fill:none,stroke:none
```
* A **Terraform agent** runs on a machine you operate, wherever that machine can reach your cloud. It pulls the Terraform bundle and runs plan and apply there. The Terraform agent has not shipped yet.
* A **Kubernetes agent** runs in the cluster. Admiral renders a Helm chart into manifests and passes raw manifests through as written. The agent pulls those manifests and plans them, and reconciles them at apply. Today it plans only.
### What happens to a Helm chart's hooks and `lookup`?
Admiral renders a chart the way `helm template` does, without a cluster. Hooks are kept and ordered by `helm.sh/hook-weight`, for the agent to run in their phases at apply. `lookup` returns nothing without a cluster, so Admiral reports every template that calls it when it renders.
## What does my network need to allow?
One outbound path. An agent dials `api.admiral.io`. It needs no inbound rule, no port mapping, and no route from Admiral back to the agent. An agent in a local [kind](https://kind.sigs.k8s.io/) cluster can reach Admiral as long as that cluster has outbound internet.
The cloud credential used to plan and apply stays on the agent. Admiral does not store it. Inside a cluster, the Kubernetes agent can do what its role allows, so [decide its permissions](https://admiral.io/docs/agents.md#what-may-the-kubernetes-agent-do-in-my-cluster) before you install it. [Agents](https://admiral.io/docs/agents.md#who-may-deploy-and-what-may-the-deploy-do) explains how that keeps who may ship apart from what the cloud allows.
## What does the control plane keep?
The resource model: applications, environments, components, changesets, runs, agents, sources, and the registry. The [Concepts overview](https://admiral.io/docs/concepts.md) defines each one.
* Desired state is the set of components in an environment. Each component pins a registry revision and carries its own values. When you add a component from a catalog item, or copy one from another environment, Admiral copies the definition onto it. Editing the catalog item or the other component later does not change it.
* Components declare [inputs and outputs](https://admiral.io/docs/concepts/variables-and-outputs.md) and form a dependency graph. An upstream applies, Admiral records its outputs, and the next component renders against those values.
* You change an environment through a **changeset**, a reviewed batch of changes to one environment. Planning it starts a **run**, which plans each changed component. You approve once. A component whose inputs come from another component's outputs is planned only after that upstream applies, so you approve without seeing its plan. Apply has not shipped yet.
* Admiral hosts [Terraform state](https://admiral.io/docs/concepts/state.md) for a Terraform component, unless the component keeps a backend of its own. The plan runs on the agent, and Admiral records the plan result. For each component it works on, the Terraform agent gets a short-lived token that reaches only that component's state and expires with the run.
* A change made outside Admiral shows up as [drift](https://admiral.io/docs/concepts/drift.md).
### Does Admiral store my secrets?
Yes, if you put one in a value or pass one to a Terraform input. A pointer keeps it out.
* For a Terraform component, a value can be a pointer into GCP Secret Manager, AWS Secrets Manager, or Vault. Admiral stores the pointer, and the Terraform agent resolves it at apply.
* A Helm chart gets no pointer resolution. It keeps the secret handling it already uses, such as Sealed Secrets, External Secrets, or Vault.
* A value you write in plaintext, including one in a Helm chart's values, is stored as you wrote it.
* A secret passed to an ordinary Terraform input lands in Terraform state, which Admiral hosts unless you keep your own backend. An ephemeral input or a write-only argument does not.
[Secrets](https://admiral.io/docs/security/secrets.md) covers each case.
Admiral encrypts what it stores the same way: a value, hosted Terraform state, and a [credential](https://admiral.io/docs/concepts/sources-and-catalog.md#credentials) for fetching from a private source. Every value, every state version, and every credential is encrypted with AES-256-GCM under its own data key. That key is wrapped by a key for your organization, which is wrapped by a root key held in a cloud KMS. Admiral holds those keys, so it can decrypt what it stores. It decrypts values when it renders a component, hosted state when it serves it to an agent or a person, and a credential only during a registry pull. A stored credential is never the cloud credential an agent uses.
## How do I manage Admiral?
In the console or with the `admiral` CLI. The [CLI](https://admiral.io/docs/reference/cli.md), the [Terraform provider](https://admiral.io/docs/reference/terraform-provider.md), and the [Go SDK](https://admiral.io/docs/reference/go-sdk.md) call the API at `api.admiral.io`.
* The console is for day-to-day use in the browser.
* The `admiral` CLI is for a terminal and for CI.
* The Terraform provider manages Admiral resources as code.
* The Go SDK builds automation against the API.
* The OpenAPI document is the REST contract behind the [API reference](https://admiral.io/docs/api.md).
## Why is it split this way?
Admiral hosts the control plane, so scaling, patching, and backups are Admiral's job, not your team's.
The agents run where the access already is. That lets Admiral coordinate many clouds and clusters without a path into any of them, and it lets a team ship without holding the cloud credential. Only the agent holds it.
## Where to go next
* [Concepts Overview](https://admiral.io/docs/concepts.md): Every resource the control plane keeps, and how a change becomes a deploy.
* [Agents](https://admiral.io/docs/agents.md): Where each agent runs, how it proves who it is, and what it pulls.
---
title: "Overview"
canonical: "https://admiral.io/docs"
description: "Admiral ships an application and the infrastructure it depends on in one reviewed change, and agents on your own infrastructure do the work."
---
# Overview
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](https://admiral.io/docs/concepts/state.md), without the `terraform_remote_state` wiring 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](https://admiral.io/docs/architecture.md): Where your code runs, what the control plane keeps, and what your network must allow.
* [Get Started](https://admiral.io/docs/get-started/overview.md): The walkthrough, from a local cluster to production. Still being written.
* [Concepts Overview](https://admiral.io/docs/concepts.md): 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.
---
title: "Applications & environments"
canonical: "https://admiral.io/docs/get-started/applications-and-environments"
description: "Create the resources Admiral deploys into: a source to fetch code from, an application to own it, and the dev and prod environments you promote between."
---
# Applications & environments
Now you create the resources Admiral deploys *into*: a place to fetch code from, an application to own it, and the two environments you'll deploy and promote between.
## 1. Create a source
A [Source](https://admiral.io/docs/concepts/sources-and-catalog.md) is where bytes live. For the walkthrough we point at a public chart repository, so no credentials are needed.
**CLI:**
```bash
# TODO: confirm flags. Public source used so no Credential is required.
admiral source create \
--name podinfo \
--type helm \
--url https://stefanprodan.github.io/podinfo
```
**Console:**
1. Open **Sources**, choose **New source**.
2. Type **helm**, URL of the public chart repo.
3. Save.
## 2. Create an application
**CLI:**
```bash
admiral app create --name demo
```
**Console:** Open **Applications**, choose **New application**, name it `demo`.
## 3. Create dev and prod environments
The same definition added to two environments becomes two independent [Components](https://admiral.io/docs/concepts/applications-and-components.md), each with its own values.
**CLI:**
```bash
admiral env create --app demo --name dev
admiral env create --app demo --name prod
```
**Console:** Inside the `demo` application, add two environments: `dev` and `prod`.
---
title: "Promote to production"
canonical: "https://admiral.io/docs/get-started/promote-to-production"
description: "Promote your tested changeset from dev to prod: Admiral copies changes into a new prod changeset, re-based on prod's own state, with per-env values resolved."
---
# Promote to production
You have a working setup in `dev`: a workload wired to an infrastructure output. Promotion ships that same, tested setup to `prod`. Promotion is a **copy**, not a link: Admiral clones the changes into a new changeset in `prod`, re-based on `prod`'s own state, and the per-environment values resolve against `prod`'s variables.
## 1. Promote the changeset
**CLI:**
```bash
# TODO: confirm the promote/copy verb and target-env flag.
admiral changeset promote --to demo/prod
```
**Console:** Open the applied `dev` changeset and choose **Promote to prod**. Admiral creates a new, open changeset in `prod`.
## 2. Review against prod and apply
The promoted changeset is reviewed against `prod`'s own deployed state, not `dev`'s. Plan it, check the diff, and apply.
**CLI:**
```bash
admiral changeset plan
admiral changeset apply
```
**Console:** Review the diff in the `prod` changeset, then **Apply**.
## You're done
You connected a cluster, deployed a real workload, wired an infrastructure output into it, and promoted the whole thing from dev to prod - the core Admiral loop end to end.
## Where to go next
* [Agent Lifecycle](https://admiral.io/docs/agents/lifecycle.md): Operate agents beyond a local kind cluster
* [CLI Reference](https://admiral.io/docs/reference/cli.md): Every command in depth
---
title: "Wire infrastructure"
canonical: "https://admiral.io/docs/get-started/wire-infrastructure"
description: "Compose components in Admiral: add a Terraform infrastructure component, emit an output, and feed it into your workload through the dependency graph."
---
# Wire infrastructure
So far you deployed one workload. The thing that makes Admiral different is composing components: an upstream component produces an output, and a downstream component consumes it automatically, in the right order. Here you add an [infrastructure](https://admiral.io/docs/concepts/applications-and-components.md#component-kinds) component and feed its output into the workload.
## 1. Register a Terraform agent
Infrastructure components run on a **Terraform agent** rather than the Kubernetes agent.
**CLI:**
```bash
admiral agent register --kind terraform --name local-tf
# TODO: run/install the Terraform agent (local process or container)
```
**Console:** Register a second agent of kind **Terraform**, then run it where it has what it needs.
## 2. Add an infrastructure component
**CLI:**
```bash
# TODO: confirm. Adds an infra change to a new changeset in dev.
admiral changeset create --env demo/dev --name add-config
admiral changeset add-change \
--name config \
--kind infrastructure \
--engine terraform \
--target local-tf
```
**Console:** Add a change of kind **infrastructure**, engine **terraform**, bound to the Terraform agent.
## 3. Declare the dependency
Make the workload consume the infra component's output. The workload reads it as `.component.config.