Getting Started

Create your first MicroStax environment in 5 minutes. One YAML file, one command, an isolated environment on Kubernetes.

MicroStax gives your team on-demand dev environments. Write a short YAML file describing your services, run one command, and get a fully isolated, production-like environment running on Kubernetes.

This page walks the fastest path. The full workflow — shared baselines, sparse overlays for PRs, seeded data, replay — is at the bottom.

What You Need

  • Node.js 20+
  • A running MicroStax API (or a managed account)
  • A Blueprint file in YAML or JSON (we'll use one below)

Your First Environment

1. Validate your Blueprint

microstax env validate --file ./microstax.yaml

This catches mistakes before anything touches the cluster.

2. Create the environment

microstax env create --file ./microstax.yaml

MicroStax reads your Blueprint, creates an isolated Kubernetes namespace, and deploys your services.

3. Check status and get your URLs

microstax env list
microstax env get <env-id>
microstax env status <env-id>

4. Work with the running environment

microstax env logs <env-id>
microstax env traces <env-id>
microstax env share <env-id>

5. Stop, resume, or delete

microstax env stop <env-id>
microstax env resume <env-id>
microstax env delete <env-id>

That's the basic loop. If your stack is small, you can stop here.

Don't Run a Full Stack Per Developer

The setup above gives every developer a complete copy of the stack. That works fine for a few services. It gets expensive fast once you have twenty, and slow once you have forty.

The cheaper default is: keep one stable baseline the whole team shares, then create lightweight overlays that only run the services each PR actually changed. Everything else is inherited from the baseline. That's where the 70% infrastructure savings come from.

Promote a baseline once

When you have an environment that works, promote it so the team can build on it:

microstax env promote <env-id>
microstax baseline list

You only do this when the baseline meaningfully changes — typically on a main merge, not per PR.

Create an overlay per PR

microstax overlay create --baseline <baseline-id> --file ./overlay.yaml
microstax overlay list --baseline <baseline-id>

The overlay deploys only the services your PR touched. Routing inherits the rest from the baseline automatically. Spinning one up is seconds, not minutes.

Realistic Data and Replay

Test data drift is the second-most-common reason an environment "looks right but breaks." Treat seeds as a first-class artifact:

microstax env seed <env-id> --script ./examples/seed/dev.sql
microstax env snapshot create <env-id>

Snapshots also unlock replay — capture a failed environment state and re-run it in an isolated sandbox to debug deterministically. See the time-travel debugging guide.

Diagnose problems fast

microstax env diagnose <env-id>
microstax env diffs <env-id>
microstax env cost <env-id>

Core Concepts

ConceptWhat it means
EnvironmentA running workspace for your app — isolated in its own Kubernetes namespace.
BlueprintA YAML file that describes the services, data, and config your app needs.
BaselineA stable environment that other developers build on top of.
OverlayA lightweight environment that runs only what you changed.
SnapshotA saved copy of your data that can be restored later.
SeedA reusable script that fills your database with test data.

Agentic Automation

MicroStax is built for both humans and AI. You can operate your environments using our MCP Server for interactive chat-based devops, or use our LangGraph Tools for building autonomous, stateful SRE agents.

Next Steps

Getting Started | MicroStax Documentation