Applications & Components
The ownership hierarchy and the per-environment desired state you own
An Application groups related work into Environments like dev and prod, and a Component is a single thing you deploy into one environment. The Component is the per-environment desired state you own and change.
The ownership hierarchy
- An Application groups related work: a service, a stack, or a product area.
- An Environment is a deployment target within an application: dev, staging, prod. Each is independent and carries its own variables.
- A Component is a single deployable unit within one environment.
Deploy the same thing to dev and prod and you get two independent components, each with its own per-environment values. A change to one does not touch the other.
admiral app create --name checkout
admiral env create --app checkout --name prodComponent
A Component is the per-environment desired state. It is the unit a deployment acts on, and it is self-contained: it carries its own definition instead of linking back to a shared template.
A component carries:
- the Source to fetch from, with the ref and path within it
- the engine that deploys it
- its kind (
infrastructureorworkload) - its per-environment values
- its dependencies on other components
- its declared inputs and outputs
- its target, the agent that executes it
Because the component carries its own definition, "what will this environment deploy?" is answerable from the environment's own data, with no chase to a shared template that might have moved.
Component kinds
A component's kind determines which execution path deploys it:
| Kind | Engines | Executes via |
|---|---|---|
infrastructure | terraform | Terraform agent |
workload | helm / kustomize / manifest | Kubernetes agent |
This is covered in depth in Agents & Execution.
Dependencies and the graph
Components in an environment form a dependency graph. A component declares the components it depends on, and a deployment uses that graph to order work: upstream components apply first, their outputs are captured, and downstream components render against those outputs before they apply.
This is how a database component can hand a connection string to an application component without you wiring it by hand. See Variables & Outputs.
You never edit a Component directly
This is the most important rule in the model. A Component is mutated only through a Changeset. There is no "edit this component" action that takes effect immediately.
Every change (creating a component, changing its values, destroying it) is staged as a reviewable Change, planned, and applied. The live state of an environment only ever moves forward through that gate.
A Change that creates a component has three possible sources for its content: authored inline, prefilled from a Catalog Item, or copied from another environment's changeset (promotion). All three produce the same self-contained component; the catalog is just the convenient one.
Lifecycle: destroy and orphan
Removing a component from an environment is itself a staged Change, with two distinct intents:
- destroy: tear down the real resources, then remove the component
- orphan: stop managing the component but leave the real resources in place
Both flow through the same changeset-plan-apply cycle as any other change, so a teardown is as reviewable as a rollout.
Where to go next
A Component is the target of change. The next page covers the mechanism: how a staged Change becomes a live deployment.