Infrastructure Planning and State Management

An infrastructure as code tool that reviews cloud changes before they run and guards the state it records.

This tool puts a review step between editing infrastructure as code and changing live cloud resources. It compares the proposed setup with the recorded state and the real resources, then saves a plan the team can read. Applying that plan is a separate command.

The tool also handles the work around that step. It resolves dependencies, keeps state usable after a stop, and lets the team rearrange the setup files without replacing the resources they describe.

The challenge

A plan has to tell a change in the infrastructure apart from a change in how it is described. Renaming a resource, importing one that already exists and deleting a resource are three different actions. Their config diffs can still look much the same.

Execution raises a second kind of problem. Some resources must wait for others, while independent work can run side by side. A stop can leave only part of the plan applied. The next run needs an accurate state record to make sense of that, and the record itself may hold sensitive values.

What we built

The tool sets up providers and reusable modules, checks the setup and produces a plan that shows what it would create, change or remove. Providers handle the individual cloud services, while the core coordinates their work.

Explicit statements cover the awkward cases. The team can move a resource to a new address, import one that already exists, or stop managing a resource without destroying it. Each choice shows up in the plan beside the infrastructure changes.

Formatting, inspection and state commands support the work around a plan. Module tests can run against mock providers, so a reusable definition gets checked without creating live resources every time.

Build the execution order from dependencies

Resource definitions, references, provider needs and recorded state together form a dependency graph. The tool prepares that graph before the walk begins. It then drops the work it does not need, and a concurrent walker processes the independent nodes while respecting the links between them.

Planning also checks the graph for loops in the dependencies, which gives the team a chance to clear a cycle before anything runs. Providers run as separate processes, which keeps cloud-specific code out of the core program.

Preserve state through changes and interruptions

State can live in local files or in a supported remote backend. A shared backend can lock the state so two writes do not clash. S3 offers conditional writes as one option, with a database-backed choice beside it.

During apply, the tool saves state at intervals and again when a run stops. If the final remote save fails, it writes a local backup instead. That saved progress helps an operator match the interrupted run to the resources that really exist.

Encryption is available for both state and saved plans. Keys can come from a cloud key-management service or from an external program. The tool tries the configured ways to decrypt in a fallback order. That supports key rotation and a move between formats without losing older records. Storage permissions and pipeline credentials still need their own management.

Project success

The team can read a concrete plan before execution, including imports and changes to resource addresses. Dependency ordering decides what can run together, and mock providers support checks of reusable modules.

Locking, encrypted state and recovery files cover what the next operation will need, giving the team ways to review and recover work. The right cloud permissions and a correct state backend still stay part of the operating setup.

Technology stack

Core engine

Go

Configuration

HCL, go-cty

Provider processes

go-plugin

Distribution

OCI, oras-go, go-getter

Backend integrations

AWS, Azure and Google Cloud SDKs

Execution visibility

OpenTelemetry