Pillar Guide
Environment as Code
Environment as Code (EaC) is the practice of defining every aspect of your software environments — services, data, networking, policies, TTL — in version-controlled, declarative files. Not scripts. Not wikis. Code.
What is Environment as Code?
Infrastructure as Code (IaC) — think Terraform or Pulumi — manages the infrastructure layer: cloud resources, clusters, networking. Environment as Code goes one level up: it manages the application runtime layer — which services are deployed, how they're connected, what data they start with, and how they behave at runtime.
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 the desired state of an environment in a blueprint file. The control plane reconciles it. Every env is reproducible, reviewable, and governed through the same lifecycle instead of being rebuilt from tribal knowledge.
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.