Zordon MCP server

Zordon

The local stack your inner loop runs against — databases, brokers, proxies and services as fast, disposable host processes, declared once and supervised together. No containers.

Zordon is a supervisor for the local stack your code runs against — the databases, brokers, proxies and services that have to be alive for your code to be exercised for real. It runs them as ordinary host processes instead of containers, declared once in an Alphasfile and supervised together, so standing the stack up, duplicating it, and throwing it away are all cheap.

Three goals shape every decision. Low latency — standing the stack up and re-running sit inside the loop, not around it; iteration shouldn't wait on infrastructure. Resourcefulness — per-stack overhead stays small enough that many agents run side by side, each with a stack real enough to evaluate against rather than a wall of mocks. Guardrails — the Alphasfile doubles as a contract, so the MCP server hands an agent only a narrow, declared surface: bring the stack up, inspect it, run a provision you named, and work through that interface instead of improvising against the host.

Why not containers? Code is increasingly written in a loop — change something, run the real stack against it, read the result, go again, hundreds of times an hour. Containers buy isolation by paying full cold-start and idle-overhead cost on every run: right for production, wasteful for a loop. Zordon takes the other side, recovering isolation from per-run workspaces instead of images — so a second stack beside yours, or a tenth, is a non-event.

Declare the whole stack in one Alphasfile:

service "go" "nats" {
  git {
    url = "github.com/nats-io/nats-server"
    tag = "v2.14.0"
  }

  vars = { client = net::pickport() }   # grab a free port, no clashes
  arguments { values = { main = { p = self.vars.client } } }
}

zordon start   # resolve, build, bring it up, stream logs until everything is READY

Features

Shortened. The full README is on GitHub.