Preview every infrastructure change before it ships — without building another pipeline
Platform teams are asked to do two things that pull in opposite directions: let application teams serve themselves, and guarantee that nothing reaches production without oversight. The usual way to bridge that gap is to build it yourself — CI/CD pipelines, plan-review scripts, and a lot of institutional memory about which change is safe to apply.
meshStack now does that work for you. A set of new capabilities lets you preview, approve, and govern infrastructure change from inside your platform — so self-service and control stop competing. Here’s what’s new and why it matters.
Plan approvals: see a change before it happens
meshStack can now run a pre-flight plan before a building block applies. In OpenTofu terms, it runs tofu plan and shows you exactly what would change.
If nothing changed, the building block is confirmed clean and moves on. If something did, meshStack creates an apply run that waits for your approval, showing you the exact plan output. You approve it — using the precise plan the pre-flight produced, so what you reviewed is what gets applied — or you reject it and the change never lands.
Instead of hoping your platform is in the desired state, you can prove that no change is applied without a preview and a decision behind it. For a team accountable to security and auditors, that’s the difference between confidence and crossed fingers.
Drift detection: catch configuration drift on a schedule, not during an incident
The same mechanism handles drift. If someone changes a resource directly in the cloud — say, flipping a storage account to allow public access when your module says it shouldn’t — meshStack detects the difference on its pre-flight run, surfaces it for review, and reconciles it back to the intended state.
You control the behavior. Pre-flight runs can be triggered by version upgrades, input changes, or manual runs. Drift detection can run daily or weekly, either as a silent dry run that only reports, or as a detect-and-resolve loop that brings resources back in line automatically.
Drift becomes a routine, reviewable event instead of a surprise you find while debugging an outage.
Approvals extend to upgrades, too. When you release a new version of a building block definition, meshStack surfaces the upgrade in the building block overview, runs the same pre-flight, and holds the apply run for your review — so the change you reviewed in your pull request is the change you see in the plan.
Landing zones as building blocks: manage a whole reference architecture from your platform
You can now manage an entire landing zone reference architecture from within meshStack, as a building block — with no separate Terraform pipeline to maintain alongside it.
Here’s a video of what that looks like in action.
The first example is built with StackIt. Starting from a bare StackIt organization, an importable reference architecture takes you to self-serving application teams with landing zones — optionally including a hub-and-spoke network — in minutes. You import the reference architecture as a building block, provide a handful of inputs, and deploy. meshStack sets up the platform, creates the landing zone, provisions the underlying project, folder, and service account, and generates the building block definition your application teams consume from the marketplace.
Two details make this operable at scale. Building block definitions created this way are marked managed, and meshStack tells you which building block created them — so your platform’s lineage stays visible instead of something you reverse-engineer later. And when you expand the architecture — for example, enabling hub-and-spoke networking — you do it by editing the reference architecture’s config and running it back through the same plan-and-approve flow, provisioning both the meshStack and the cloud resources in one governed step.
The code that describes your platform, the guardrails around changing it, and the self-service catalog your developers use all live in one place. You’re not maintaining a parallel deployment pipeline for the platform itself.
Evergreen Terraform resources: upgrade the provider without breaking your state
If you drive meshStack through Terraform, keeping up with the API versions underneath the provider has been a recurring source of friction. Evergreen resources remove it: versionless resources that stay current as long as you upgrade the provider, with the provider walking you through the upgrade path.
The migration is deliberately uneventful. Using Terraform move blocks, you move from version-suffixed resources to the evergreen ones without recreating your tenants or building blocks — no backend changes, nothing destroyed, nothing replaced. The only diff is the extra output attributes the provider now records in state.
Provider upgrades stop being a risk you schedule around. Nothing gets destroyed, only changed.
Quality-of-life improvements that save real time
A few smaller additions target everyday friction:
- Errors in your console. When a building block created from the Terraform provider fails, meshStack now surfaces the error message directly in your console — so you diagnose an auth or config mistake without switching context. It also gives any agents you delegate work to a clear signal to act on.
- Ordered inputs. You can set the display order of building block definition inputs, so the form your developers fill out reads the way you intend.
- Markdown in input descriptions. Bold, code formatting, and links — so you can point straight to an internal wiki or runbook from inside an input.
- Redesigned tenant overview. It now matches the building block overview, with unmanaged and deleted tenants in the same view.
Where this is going
The thread through all of it: the plan-review-approve loop you would otherwise build by hand is now part of the platform, and it reaches from a single building block all the way up to a full landing zone architecture. Next on the path are more powerful building block inputs — optional and conditional, with a preview using Common Expression Language — and deeper support for agentic platform engineering, so agents can safely take on more of the routine work.
Less pipeline to maintain, fewer surprises in production, and a platform whose state you can actually vouch for.