Infrastructure for Coding Agents

Zerops was built on the idea of environment parity — giving developers the full development lifecycle, from remote development to highly available production, with the observability and developer tools for maximum flexibility, and sensible defaults so the configs stay reasonable. Turns out that's exactly what coding agents need to produce and iterate on production-ready applications.

What is it

An MCP server for your agents — with an optional remote cloud development environment container to run them in — that makes use of the flexibility and processes Zerops provides. There's no "Zerops system prompt" hogging your context window. The MCP server is a thin layer that makes your agent a Zerops platform power user — when needed — so it understands:

how networking, scaling, debugging, build & deployment, environment variables, and service provisioning work on the platform
the development loop: start a dev server → implement → deploy to stage → verify

The depth of the platform underneath is what gives the agent room to actually work. A single agent can scaffold and iterate on projects with multiple runtimes (app, api, worker) backed by multiple managed services (object storage storage, Postgres db, Elasticsearch search, NATS broker, Valkey cache) — just as easily as it can work on a simple Next.js presentational website.

A recipe ecosystem covering the most popular frameworks — pre-prepared for the whole lifecycle — gives the agent a baseline to start from, or a guide for setting up any stack on Zerops.

  ┌─ ZCP MCP ────┐    ┌─ recipes for any stack ────────────────────────────────┐
  │              │    │                                                        │
  │              │    │                                                        │
  │              │    │                                                        │
  │              ├───►│                                                        │
  │              │    │                                                        │
  │              │    │                                                        │
  └───────┬──────┘    │                                                        │
          │           │                                                        │
          │           │                                                        │
          │           └────────────────────────────────────────────────────────┘
          │
          │    zcp with agent has root ssh access to runtime services,
          │      runs dev server on dev, deploys to stage, verifies
          │
          ├───────────────────────────────────────────────────────────────┐
          │                                                               │
┌─ complex project ────────────────────────────────────────┐    ┌─ simple project ───┐
│         │                                                │    │         │          │
│         ▼                                                │    │         ▼          │
│  ┌────────────┐                                          │    │    ┌──────────┐    │
│  │    zcp     │                                          │    │    │   zcp    │    │
│  │   Ubuntu   │                                          │    │    │  Ubuntu  │    │
│  └────────────┘                                          │    │    └──────────┘    │
│                                                          │    │                    │
│  ┌────────────┐      ┌────────────┐      ┌────────────┐  │    │    ┌──────────┐    │
│  │   appdev   │      │   apidev   │      │ workerdev  │  │    │    │  appdev  │    │
│  │    Bun     │      │   Golang   │      │   Python   │  │    │    │ Node.js  │    │
│  └────────────┘      └────────────┘      └────────────┘  │    │    └──────────┘    │
│                                                          │    │                    │
│  ┌────────────┐      ┌────────────┐      ┌────────────┐  │    │    ┌──────────┐    │
│  │  appstage  │      │  apistage  │      │workerstage │  │    │    │ appstage │    │
│  │    Bun     │      │   Golang   │      │   Python   │  │    │    │ Node.js  │    │
│  └────────────┘      └────────────┘      └────────────┘  │    │    └──────────┘    │
│                                                          │    └────────────────────┘
│  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐  │
│  │   db   │ │ search │ │ broker │ │ cache  │ │storage │  │
│  │Postgres│ │Elastic │ │  NATS  │ │ Valkey │ │   S3   │  │
│  └────────┘ └────────┘ └────────┘ └────────┘ └────────┘  │
└──────────────────────────────────────────────────────────┘

Platform-first, not agent-first

Most coding-agent platforms went agent-first, then bolted on infrastructure — where it runs, how it reaches the database, how its output becomes production-ready, which third-party services to wire up. Zerops went platform-first. The complete development lifecycle existed before coding agents did; we taught them to operate it — not just how to call APIs, but how to ship software the way a senior developer would.

Main features

Your agent, your subscription

Bring whichever agent you already use. Claude Code today; Codex, Gemini CLI, opencode, and any MCP-capable client next. The container is a regular Ubuntu — install your own CLI tools, drop in your .claude / .cursor configs, attach your IDE over SSH. Zerops doesn't resell tokens or proxy your model calls — sign in with your own Anthropic / OpenAI / Google subscription and the agent talks to its provider directly.

An ordinary Zerops project underneath

The agent operates inside a normal Zerops project — same shape as production. Managed databases (PostgreSQL, MariaDB, ClickHouse), key-value stores (KeyDB, Valkey), search (Elasticsearch, Meilisearch, Typesense), vector store (Qdrant), message queues (NATS, Kafka), object and shared storage, managed Nginx — all on a private network, addressable by hostname. The same pipeline that deploys here can deploy to a separate HA production project with no zcp service attached. Not a sandbox the work outgrows.

Human ↔ agent handover

The agent and the human share the same workspace — same filesystem, same SSH key, same Cloud IDE in the browser, same remote-dev attach from your local IDE. Take over mid-session, set something up before the agent runs, debug in the same container the agent just left. Nothing reaches production until you merge the PR — the agent opens it, you gate it.

Recipes for any stack

Runtimes for Bun, Deno, Node.js, Go, Python, Rust, Java, .NET, PHP, Elixir, Gleam — with curated recipes for the framework on top: Next.js, Nuxt, Astro, Svelte, React, Vue, Angular, Solid, Qwik, Analog, NestJS, Laravel, and more. Pick a recipe, select the AI Agent environment, and the project comes up with a working dev runtime, a stage runtime, the right managed services wired in, and a coding agent briefed on the Zerops surface.

How it works in practice

The agent reaches your project's private network one of two ways:

Remote — a zcp service deployed into the project runs the agent. You attach to it with Claude Code's IDE extension, with any IDE that supports remote development (Cursor, Windsurf, VS Code Remote), or by running zcli vpn up and ssh-ing into zcp to drive the rest of the project from a shell.
Local — install the zcp MCP on your machine and run zcli vpn up to join the network. From there your IDE, agent, and shell can ssh directly into any container.

Either way, the agent reaches managed services by hostname (db:5432, cache:6379), deploys through the Zerops pipeline, and reads logs and events the same way you would.

                      https://my-app.com
                               │
                               ▼
┌────────────────────────────────────────────────────────────┐
│        Zerops development project (private network)        │
│ ┌─────────────────┐  ┌──────────┐  ┌──────────┐            │
│ │ project ctrl    │  │  stats   │  │  logger  │            │
│ │ + L3 balancer   │  │          │  │          │            │
│ │ + firewall      │  │          │  │          │            │
│ └────────┬────────┘  └──────────┘  └──────────┘            │
│          │                                                 │
│ ┌────────┴────────┐                                        │
│ │   L7 balancer   │                                        │
│ │     (Nginx)     │                    control plane       │
│ └────────┬────────┘               ssh into other services  │
│          │                        dev runtime fs mounted   │
│          ├─────────────────┬─────────────────┐             │
│   ┌──────┴──────┐  ┌───────┴───────┐  ┌──────┴──────┐      │
│   │ appdev:3000 │  │ appstage:3000 │  │ zcp service │      │
│   │ dev runtime │  │ stage runtime │  │ agent + MCP │      │
│   └──────┬──────┘  └───────┬───────┘  └──────┬──────┘      │
│          │                 │                 │             │
│          └─────────────────┼─────────────────┘             │
│                            │                               │
│             ┌──────────────┴────────────┐                  │
│             │                           │                  │
│      ┌──────┴──────┐             ┌──────┴──────┐           │
│      │ db:5432     │             │ cache:6379  │           │
│      │ Postgres    │             │ Valkey      │           │
│      └─────────────┘             └─────────────┘           │
│                                                            │
└────────────────────────────────────────────────────────────┘

The agent runs through two workflows. Bootstrap settles which services and runtime targets the app needs. Develop is the short work loop — edit code on appdev, deploy to appstage, check it's reachable, verify behavior against db:5432 and cache:6379, fix from evidence. A session ends with a URL you can open, or a specific blocker — failure category, attempts, what's still needed. Same hostnames, same managed services, same pipeline as production — just at smaller scale. See Workflows in depth for both.

    zcp (local or remote)
           │
           ▼
  edit code on appdev   ◀────────────────────────┐
     └ dev server, hot reload                    │
           │                                     │
           ▼                                     │
  deploy to appstage                             │
           │                                     │
           ▼                                     │
  check reachability                             │
           │                                     │
           ▼                                     │
  verify behavior   ─── fail ─────┐              │
           │                      │              │
           │ pass                 ▼              │
           ▼               read logs / events    │
  URL (proof)             fix from evidence ─────┘

Once the loop produces verified work, the agent doesn't push to production. It hands off — through whichever path your team uses: a tag push, a protected-branch merge, a manual zcli release, a pull request, or a CI job. A human gates the release, and the production deploy runs into a separate production project that has no zcp service at all.

      Dev project                 GitHub                  Prod project

┌─────────────────────┐       ┌──────────────┐       ┌─────────────────────┐
│  appdev             │       │              │       │   app    (HA)       │
│  appstage           │       │  Pull        │       │                     │
│                     │ push  │  Request     │ CI/CD │   db     (HA)       │
│  db, cache          │ ────▶ │              │ ────▶ │                     │
│                     │       │  + human     │       │   cache  (HA)       │
│  zcp service        │       │    review    │       │                     │
│                     │       │              │       │   (no zcp service)  │
└─────────────────────┘       └──────────────┘       └─────────────────────┘

Where does this fit in the agent landscape

With the model clear, here's where ZCP sits among adjacent tools. People say "agent infrastructure," "infra for Claude agents," "agent hosting," or "agent sandboxes" to mean different things — usually one of the categories below.

PaaS MCPs

AWS MCP servers · Railway MCP · Fly.io MCP · Render MCP

Most major PaaS providers have shipped an MCP — provision services, deploy code, list resources, read operational state. Great for "let my agent ship to my Railway account." These are deploy and operate surfaces, driven from outside the platform — and they reflect what's underneath: platforms optimized for day-one deploy that tuck the infrastructure behind a wall. Log and metric read tools landed across the category in 2025 (and AWS only just hit GA), but the in-network, in-container surface an agent needs to actually develop — hit Postgres from inside the network, follow a build live, drive the dev loop before it ships anything — is still on the other side of the wall.

ZCP exposes the full Bootstrap and Develop loop as MCP-addressable primitives because Zerops was built around the development lifecycle from the start — not a dev loop retrofitted onto a deploy-first platform.

Cloud VPS MCPs

Hetzner Cloud MCP · DigitalOcean MCP · Linode MCP · raw SSH/server MCPs

"Let your agent manage your Hetzner VPS." Two shapes cluster here: vendor-API MCPs (DigitalOcean ships an official one) that provision services from outside the box, and community-built SSH MCPs (Hetzner, Linode, Vultr) that give the agent shell access — provision it, SSH in, install Docker and Postgres and nginx, set up systemd units, point a domain at it. Maximum control, lowest cost, full Linux to play with. The same reason senior developers reach for managed platforms applies here: even if you can harden SSH, write nginx configs, tune pg_hba.conf, rotate TLS, set firewall rules, run fail2ban, and stay on top of CVEs across kernel, OpenSSL, Docker, Postgres, and nginx — you usually don't want to. Each layer is its own domain with its own gotchas, each is a security surface that drifts the moment you stop tending it, and every project becomes a snowflake. Hand that work to an agent and you also hand it the blast radius: misconfigured firewall, debug endpoint left open, port 5432 exposed to the internet, keys never rotated. ZCP is the inverse trade-off — the guardrails of a managed platform. Private networking, TLS, isolated services, safe defaults, managed backups, no exposed ports unless you opt in — all built in. The agent operates through project-scoped MCP tools instead of sudo on a fresh Ubuntu box, so the mistakes that matter on a VPS aren't reachable from where it sits.

Cloud dev environments with AI

GitHub Codespaces + Copilot Coding Agent · Ona (ex-Gitpod) · Coder

A managed Linux container in the cloud with your editor and an AI assistant attached. Solves "where the agent runs" so state survives between sessions and machine setup stops being a question. The category itself is repositioning toward governed agent runtimes — Copilot Coding Agent (the productized successor to Workspace), Coder Agents, and Ona (Gitpod's rebrand after it shut down the SaaS in late 2025) all point the same way. The zcp service is the closest thing in this category — managed Linux container, Cloud IDE, your agent of choice — except it lives inside a Zerops project, addressing the project's runtimes, database, and cache by hostname, with deploys and logs as primitives the agent can call.

Bundled agent platforms

Replit Agent · Lovable · Bolt.new · v0 · Devin

The agent, the workspace, the stack, and (often) the hosting target are fused into one closed product. Fast for prototypes. Decisions are made for you. Switching agents usually means switching platforms, and production-grade primitives — a real dev/stage/prod release flow, private networking, observability — are uneven across this category: v0, Bolt, and Devin have moved upmarket with deploy/auth/DB primitives, others have not. ZCP doesn't bundle: the agent and model stay yours on your own subscription, and the platform underneath is normal Zerops with the full stack of managed services, networking, deploys, and observability.

Local coding agents

Cursor · Windsurf · Zed · Claude Code · Codex CLI · Aider · Cline

The agent runs on your machine, edits your local checkout, runs local commands. Excellent at code changes. MCP is now native across these tools, so external reach — databases, networking, deploy targets, runtime logs — comes through plugins instead of bare hands. The agent still lives on your laptop, though: anything off-machine has to be reached, not inhabited. Install the ZCP MCP locally and run zcli vpn up, and any of these agents can now reach a real Zerops project alongside your local code: services addressed by hostname, deploys, logs, events.

Code-execution sandboxes

E2B · Modal · Daytona · CodeSandbox SDK

Mostly ephemeral Linux environments that AI applications spin up — often per request — to execute generated code safely (E2B, Modal). The right primitive when you're building a product that needs a model to run untrusted code and hand back the output. Some have pivoted toward stateful, resumable agent workspaces — Daytona now explicitly markets "every agent a computer," and CodeSandbox SDK's hibernation/resume sits between ephemeral and persistent. Still a different shape from ZCP; they show up here because the names cluster nearby.

Agent SDKs and frameworks

Cloudflare Agents · Vercel AI SDK · Mastra · Claude Agent SDK

Libraries for building and shipping agents to your users — tool calling, memory, orchestration, model providers, sometimes hosting. They're how somebody would build a product like ZCP, not where a coding agent runs against a project. Same disambiguation — adjacent on the shelf, different shape.