---
title: "Applications & Components"
canonical: "https://admiral.io/docs/concepts/applications-and-components"
description: "Admiral's ownership hierarchy: applications group environments like dev and prod, and each component is the per-environment desired state you own and change."
---

# Applications & Components

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 [#the-ownership-hierarchy]

<Mermaid
  chart="`
flowchart LR
A[&#x22;<b>Application</b>&#x22;] --> E[&#x22;<b>Environment</b>&#x22;] --> C[&#x22;<b>Component</b>&#x22;]
`"
/>

* 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.

```bash
admiral app create --name checkout
admiral env create --app checkout --name prod
```

## Component [#component]

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** (`infrastructure` or `workload`)
* 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 [#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](https://admiral.io/docs/concepts/agents-and-execution.md).

### Dependencies and the graph [#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](https://admiral.io/docs/concepts/variables-and-outputs.md).

## You never edit a Component directly [#you-never-edit-a-component-directly]

This is the most important rule in the model. A Component is mutated **only** through a [Changeset](https://admiral.io/docs/concepts/changesets-and-runs.md). 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.

> **Note:** 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 [#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 [#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.

- [Changesets & Runs](https://admiral.io/docs/concepts/changesets-and-runs.md): How staged changes plan, apply, and become history

- [Variables & Outputs](https://admiral.io/docs/concepts/variables-and-outputs.md): How values and cross-component data feed rendering