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

{/*
  OUTLINE / DRAFT. Step 4 = AHA 1a: two components wired together, one's output feeds
  the other's input automatically, and the dependency graph is visible.

  KEY DESIGN DECISION (capture before writing): infrastructure = terraform, which runs
  on a Terraform agent. To keep this step cloud-free (no IAM cliff during onboarding),
  use a Terraform example that needs no cloud account - e.g. the `random` provider to
  generate a value, or `local`/`null`, or kreuzwerker/docker. The infra component emits
  an OUTPUT (e.g. a generated token / config value) that the podinfo workload consumes
  as an input via `.component.<name>.<output>`. This demonstrates the dependency graph
  and output flow WITHOUT a cloud onboarding cliff. Confirm the chosen example, then
  write. See docs/backlog/plg-onboarding.md (the cloud-credentials cliff).

  This step needs a Terraform agent in addition to the Kubernetes agent from step 1.
  Decide: register the Terraform agent here (extra friction) or fold its registration
  into step 1. Leaning: register it here, scoped to "infrastructure needs a Terraform agent."
  */}

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 [#1-register-a-terraform-agent]

Infrastructure components run on a **Terraform agent** rather than the Kubernetes agent. {/* TODO: cloud-free Terraform example means the Terraform agent needs no cloud creds for the walkthrough. */}

<Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
  ### CLI

```bash
    admiral agent register --kind terraform --name local-tf
    # TODO: run/install the Terraform agent (local process or container)
    ```
  
### Web

Register a second agent of kind **Terraform**, then run it where it has what it needs.
  

## 2. Add an infrastructure component [#2-add-an-infrastructure-component]

{/* TODO: a Source pointing at a small public Terraform example (cloud-free), then a
   component of kind infrastructure / engine terraform that emits one output. */}

<Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
  ### 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 <changeset> \
--name config \
--kind infrastructure \
--engine terraform \
--target local-tf
    ```
  
### Web

Add a change of kind **infrastructure**, engine **terraform**, bound to the Terraform agent.
  

## 3. Declare the dependency [#3-declare-the-dependency]

Make the workload consume the infra component's output. The workload reads it as `.component.config.<output>`; Admiral defers the workload until the infra component has applied and its output exists. See [Variables & Outputs](https://admiral.io/docs/concepts/variables-and-outputs.md).

<Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
  ### CLI

```bash
    # TODO: how a dependency + output reference is expressed on the workload change
    #       (values template referencing .component.config.<output>).
    ```
  
### Web

On the workload component, reference the infra component's output in its values; the dependency is recorded automatically.
  

## 4. See the dependency graph [#4-see-the-dependency-graph]

{/* TODO: show the env's dependency graph (web graph view + CLI `env describe`),
   highlighting config -> web. This is a core thing the user asked to highlight. */}

<Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
  ### CLI

```bash
    admiral env describe demo/dev
    ```
  
### Web

The environment view renders the graph: `config` upstream of `web`.
  

## 5. Plan and apply the wavefront [#5-plan-and-apply-the-wavefront]

Plan and apply the changeset. The run applies `config` first, captures its output, renders `web` against that concrete value, then applies `web` - one approval, the rest cascades.

{/* TODO: show the deferred -> applied progression so the wavefront is visible. */}

## Next [#next]

- [5. Promote to production](https://admiral.io/docs/get-started/promote-to-production.md): Copy this tested setup from dev to prod