---
title: "Deploy Terraform and Helm together"
canonical: "https://admiral.io/terraform-and-helm"
description: "One changeset holds the Terraform change and the Helm release that depends on it. Admiral keeps both tools and replaces the glue between them."
---

# Deploy Terraform and Helm together

Admiral keeps both Terraform and Helm. What it replaces is the glue between them - the second pipeline, the shared runner, and the review that happens in two places for one change.

A database and the release that reads from it are one change. Terraform plans and applies one half; a reconciler watches a branch for the other. Each review is sound on its own, and nobody reviews the thing that is actually happening. Admiral holds the desired state for both halves and the dependencies that cross between them.

## How the two halves run as one changeset

1. **Stage.** The module change and the release that reads from it are staged together, scoped to one environment. Nothing has touched the environment yet.
2. **Plan.** Admiral plans every component it can resolve and shows you the effects. Work that depends on an output no run has produced yet is deferred rather than guessed at.
3. **Apply.** You approve once. The run applies components in dependency order, so the database exists before the release that reads from it, capturing the real Terraform outputs as each wave finishes and rendering the components downstream against them.
4. **Record.** Each component that applies gets an immutable revision holding what shipped and the values it rendered against. Reverting replays a prior revision.

## What you keep

- HCL, your modules, your providers, and your registry. Admiral runs the Terraform you already have.
- Your Helm charts and raw manifests, in standard formats that still work without Admiral.
- Git, versioning the module and chart source your components point at.
- Your cloud console. Admiral surfaces out-of-band changes as drift rather than preventing them.

## What it costs

- An approved changeset is not an atomic apply. A component that fails partway through a dependency chain leaves the components already applied in place, blocks its dependents, and ends the run as partially failed. Recovering means another changeset to fix forward or revert.
- Scoping is per agent rather than per component, so the boundaries you get are the ones you drew at install time.
- Desired state lives in Admiral, so what an environment should be running is no longer answerable from a repository checkout you already have open.

The reasoning behind the model is on [Why Admiral](https://admiral.io/why-admiral.md).

- [Join the waitlist](https://admiral.io/waitlist.md)
- [Read the docs](https://admiral.io/docs.md)