Pillar Guide
Environment as Code
Environment as Code (EaC) means describing your full environment — services, data, networking, policies, TTL — in version-controlled YAML. Not scripts. Not wikis. Code.
What is Environment as Code?
Infrastructure as Code (Terraform, Pulumi) sets up your cloud resources: clusters, networks, buckets. Environment as Code sets up what runs inside them — which services boot, how they talk to each other, what data they start with, and how long they live.
In a traditional setup, environments are assembled manually: a developer copies configs, runs init scripts, fixes version mismatches, seeds a database, and prays it matches staging. Environment as Code eliminates all of that.
With EaC, you declare what an environment should look like in a blueprint file. MicroStax reconciles it. Every environment is reproducible, reviewable, and governed — no more setup steps that only one engineer remembers.
The 5 principles of Environment as Code
Declarative definition
Every environment component — services, resources, networking, data seeds, TTL — is declared in a versioned blueprint file. No manual steps, no tribal knowledge.
Version-controlled & reviewable
Environments live in Git alongside your code. Changes go through PRs. Breaking changes are visible before they reach the team, not after.
Reproducible on demand
Any team member, CI job, or AI agent can spin up an identical environment from the same blueprint — same services, same data shape, same network config.
Shared reference environments
Keep one stable reference environment for the team, then launch branch environments that run only the services you are changing.
Controlled by policy
Define governance rules, placement constraints, and resource controls centrally. Environment definitions stay reviewable, and policy checks stay attached to the same workflow.
How MicroStax implements Environment as Code
MicroStax uses Blueprints — declarative YAML files that define your environment: which services to deploy, which team reference environment to use, which data seed to apply, what TTL policy to enforce, and which policy controls apply.
# microstax.yaml
name: payments-feature-env
routing:
mode: overlay
baselineId: stx-main-baseline
overlayId: payments-v2
services:
- name: payments-api
image: ghcr.io/myorg/payments:feature-v2
snapshot:
engine: postgres
database: payments
maxAgeHours: 24
autoShutdownDelayMinutes: 120
Commit that file to Git. Run microstax env create --file ./microstax.yaml. That turns the Blueprint into a concrete environment using the same declared routing, data, and lifecycle settings your team reviewed in code.
Environment as Code vs the alternatives
| Approach | Reproducible | Reviewed in Git | Policy-governed |
|---|---|---|---|
| Shell scripts / wikis | ❌ | ❌ | ❌ |
| Docker Compose | ⚠️ Local only | ✅ | ❌ |
| Helm + manual steps | ⚠️ Partial | ✅ | ❌ |
| Skaffold / Tilt | ⚠️ Partial | ✅ | ❌ |
| MicroStax Blueprints | ✅ Full | ✅ | ✅ |
Ready to try Environment as Code?
Start with a Blueprint, validate it, and create an environment your team can reproduce and review.