Skip to main content
A stack is the infrastructure-as-code state behind a module instance. If a module’s definition includes a stack block, every instance of that module gets exactly one stack. Modules without infrastructure — or whose definitions only configure build and deploy behavior — have no stack. The stack tracks:
  • Resources — every Terraform resource the module manages, with its type, address, and the change it went through in each run (create, update, delete, replace).
  • Change history — every plan and apply, with resource-change counts and full output.
  • Outputs — the stack’s Terraform outputs. Other modules consume these through references like << ref.stack.output.vpc_id >>, which is how a web service module finds its cluster and network.

​
Stacks change through pipelines

You never run terraform apply against a stack by hand. Every stack has two pipelines attached: A run of one of these is what the docs call a stack change pipeline run. It is an ordinary pipeline run — you inspect it under Pipelines with steps, logs, and Terraform results like any other run. The flow within a change run:
  • The plan and apply steps run on temporary EC2 instances in your cloud account, so your Terraform code and secrets never enter the Ravion control plane. The plan file is uploaded to S3 and the apply consumes exactly that plan.
  • The approval step is skipped when the plan has no changes, or when the run was started with autoapprove (for example --autoapprove on ravion project config apply or ravion stack trigger-pipeline). Autoapprove applies to change runs only — destroy runs always require manual approval.
  • Runs are locked per stack, so two runs can’t apply to the same state concurrently.

​
System pipelines and customization

By default, every stack runs through Ravion-managed system pipelines: System pipelines are global and read-only — Ravion manages them, and you can’t edit them. They give every organization a working plan → approval → apply workflow with zero setup. To customize the workflow — add policy checks, notifications, or different approval rules — create your own pipeline in your account and point stacks at it instead:
1

Create your pipeline

Start from the system pipeline’s config, or from scratch:
See Pipeline config file.
2

Point stacks at it

Stacks resolve their pipelines through default values with the definition given IDs change_pipeline_id and destroy_pipeline_id. Set a value at the organization, project, or environment level — the most specific scope wins:
A module definition can also pin explicit pipeline IDs through its stack.pipelines config, which takes precedence over the default values — but only if the definition exposes that config. See the module definition schema.

​
Initial run when creating a module

When you create a stack-backed module instance you choose the initial stack run behavior:
  • NONE (default) — create the instance without running Terraform yet.
  • PLAN — start a change run that stops at the approval gate.
  • APPLY — start a change run with autoapprove enabled.
With the CLI this is ravion module create --initial-stack-run.

​
Inspecting stack configuration

A module version defines the source code and input mapping used by its stack. Get the module version ID from the module instance, then inspect the version:
The version’s stack config includes repo, ref, and base_path for the Terraform or OpenTofu source. Its terraform_variables mapping shows how module inputs and references become Terraform input variables. Use this metadata to debug plans, trace unexpected values, or prepare an import.

​
State storage

Ravion can act as your managed Terraform state backend: set ravion_state_backend_workspace in the module definition’s stack config and Ravion stores versioned state for you, with locking. By default, the workspace is named {project}-{environment}-{module}-{stackId} using given IDs plus the stack ID. Alternatively, use your own remote backend such as S3 and DynamoDB. Local state backends are not supported.
ravion terraform state pull, list, and show return a 404 for a managed workspace until the first state version is written. A module created with --initial-stack-run NONE has no state version until an operation such as terraform apply or terraform import writes one.

​
Inspecting stacks

See the ravion stack and ravion terraform CLI references.