Architecture

MicroStax is a control plane for ephemeral development environments. It accepts a Blueprint, validates it, computes the right environment shape, provisions Kubernetes resources, and keeps environment state observable through CLI, dashboard, VS Code, and MCP clients.

System Overview

Click top-right to expand

Core Components

Control Plane API

The API is responsible for:

• authentication, org scoping, and RBAC
• Blueprint validation
• environment lifecycle routes
• baseline, overlay, seed, snapshot, diagnosis, telemetry, and share-link workflows
• progress, status, and audit event publication

Orchestrator Layer

The orchestrator converts a Blueprint into Kubernetes resources:

• namespaces
• deployments and services
• ingress and routing middleware
• config maps and secrets
• network policies
• seed and snapshot restore jobs
• tee or mirror resources for shadow workflows

Store Layer

The store persists:

• environment metadata
• status and endpoints
• share tokens and expiration
• organization scope
• audit and governance artifacts
• runtime graph state used for replay and derived-environment workflows

Clients

MicroStax exposes the same platform through several interfaces:

• CLI for automation and CI
• dashboard for visual operations
• VS Code extension for Blueprint authoring and environment inspection
• MCP server for agent workflows

Runtime Modes

MicroStax supports several environment shapes.

Mode	Description
Isolated	Full environment provisioned in its own namespace.
Baseline	Shared provider environment used as the parent for overlays.
Overlay	Sparse derived environment that deploys changed services and bridges the rest.
Shadow	Mirrored or comparison-oriented environment for behavioral validation.

Graph-Driven Provisioning

The newer orchestration flow is not just "deploy everything in the YAML".

Differential provisioning

When an environment references a baseline, the control plane can compute a difference graph:

• identify added and modified services
• detect impacted dependencies
• deploy only the necessary service set
• bridge unchanged services to the provider environment

How MicroStax decides where to route traffic

When you create an overlay, each service call needs to go to the right place. MicroStax resolves this automatically:

• If you changed the service → routes to your overlay's version
• If you didn't change it → routes back to the baseline or parent environment
• If a policy override exists → uses the explicitly configured target

This is what makes overlays predictable instead of "it works when I test it locally."

Replay

Execution state can be replayed so operators can rerun environment realization from persisted graph context and compare outcomes over time.

Data Initialization Path

MicroStax supports several data bootstrapping modes:

• init scripts for one-off local setup
• seed packages for reusable shared fixtures
• snapshot restore for sanitized production-like data
• snapshot refresh schedules for keeping artifacts current

These data workflows are part of provisioning rather than separate undocumented cluster procedures.

Networking

Networking is handled as a first-class platform concern.

• every environment gets namespace isolation
• exposed services receive ingress
• overlay routing uses request headers for targeting
• propagation can continue the overlay context downstream
• mirror and tee flows support shadow validation and behavior comparison

Security And Governance

The architecture enforces:

• organization-scoped access to environments and metadata
• role checks for destructive or privileged operations
• share links with token and optional PIN-based access
• audit logging for lifecycle and administrative events
• governance-gated actions such as promotion or policy-sensitive changes
• default-deny network policy and controlled ingress exposure

Observability

The platform exposes:

• environment logs
• distributed traces
• Prometheus-style metrics
• topology and routing views
• diagnostic output and remediation hints
• governance and audit records

Provider Strategy

The default target is Kubernetes-compatible orchestration. MicroStax keeps the control plane stable while the provider implementation varies by runtime.

• k3s for lightweight local and MVP deployments
• GKE, EKS, and AKS providers for managed clusters
• no-op provider for tests and dry-run validation

Why This Matters

The architectural shift is that Blueprints are not passive config files. They are active control artifacts used to:

• validate environment intent
• decide sparse versus full realization
• resolve service lineage
• restore realistic data
• mirror and compare runtime behavior
• preserve enough state for replay, audit, and governance