Dora Noda"We're moving from millions of developers to millions of developers working alongside AI agents. Most platforms weren't designed for either of these changes." That is Damir Špoljarič, founder of Gi21 Capital, explaining why his fund just led a seed round of two million dollars into Zerops, a Prague-based platform-as-a-service startup. The round, announced May 14, 2026, is explicitly framed around rebuilding cloud infrastructure for the AI development era — and its centerpiece is not a faster build pipeline or cheaper compute.
It is Zerops Control Panel (ZCP), a control plane designed so that an AI coding agent can build, deploy, and debug against real project infrastructure instead of a local mock or a generic sandboxed VM.
This is the first PaaS funding round that names the coding agent, not the developer or the CI runner, as the primary consumer of the platform's API. That framing deserves more than a funding-note skim, because it forces a concrete design question every platform team now faces: what actually changes in a control-plane API when the caller on the other end is an agent mid-task rather than a human clicking a dashboard? Zerops has published unusually specific answers — open-source server, public trust model, behavioral evals — so this post dissects what ZCP really is, scores it against the agent surfaces Render and Railway already ship, and turns the comparison into a five-item MCP roadmap checklist for anyone running a self-hosted platform.
The $2M news in one box
The facts, from the Tech.eu announcement and the round's syndicated coverage: Zerops raised two million dollars (€1.7 million) in seed funding led by Gi21 Capital. The money funds bare-metal expansion into North America and Asia — including a new Singapore datacenter — plus product development and team growth. The company already runs its own bare-metal hardware across Europe and the United States, claims up to 4x lower cost than legacy platforms, and ships 15+ built-in services. (We previously covered Zerops's hardware-only pricing model and how it compares to owning a Cluster API fleet on Hetzner; this post is about the other half of the announcement.)
The architectural pitch underneath the raise is a unified environment: no dev/staging/prod tiers, one project where code behaves identically regardless of scale, full Linux containers instead of restricted app containers, and production deploys that take a single click rather than weeks of environment-parity debugging. CEO Aleš Rechtorík's summary: "Most platforms ask you to trust that development and production are close enough. We removed the gap entirely." That gap-removal is what makes the agent story credible — an agent debugging against infrastructure that differs from production is debugging a fiction — but the genuinely new artifact is ZCP itself.
What ZCP actually is: a work loop, not a dashboard
Despite the "Control Panel" name, ZCP is not a GUI. It is an open-source MCP server plus a zcp binary (Go, roughly two dozen zerops_* tools) that gives a coding agent what the docs call a "work loop": read live state, choose the app runtime, change code and platform wiring together, deploy through Zerops, verify real behavior, and return proof or a blocker. Three of its design choices are worth stealing explicitly.
Live state is the source of truth, not chat history. The MCP tools read the actual project — runtime and managed services, env-var keys, recent build/deploy events, build and runtime logs, saved work state after an interrupted session — instead of asking the human to paste a service inventory into the prompt. The docs are blunt about why: "Chat history is not the source of truth," and the prescribed recovery move when an agent sounds confused is a prompt that re-reads current project status before changing anything. Any platform exposing deploy tools to agents without a state-reading surface is shipping half the loop.
Verification has two layers, and only the second counts. A successful deploy proves Zerops accepted the build and started the runtime. Reachability checks prove the service answers. Neither proves the product request — so ZCP's proof gate is requested behavior: create the task, move it, refresh, confirm it persisted. The final answer must name the runtime, the URL, and the behavior checked. Note the discipline this imposes on the platform side: behavior proof needs structured deploy evidence (logs, events, verification output) an agent can query, not a green checkmark in a dashboard.
Delivery happens after proof, through the same loop. Direct deploy, git push, or CI handoff are delivery choices selected once a verified runtime exists — the first functional deploy goes through MCP so the agent has a running result to verify against. The loop also runs in two setups with identical control flow: remote (a zcp@1 service inside Zerops with private networking, optional bundled agent CLI and browser VS Code) or local (zcp init on the laptop, managed services reached over VPN). Same evidence surface either way, so a human can take over mid-task from files, logs, events, and verification state.
Two process details signal how seriously Zerops takes this: the repo carries behavioral evals — scripted scenarios verified against a live playground project, including rendered-text checks through a headless browser — and multi-agent container support already spans Claude Code, Codex CLI, Cursor, Gemini, and others. Evals for the agent loop are the test suite for this product category. A platform shipping agent tools without them is flying blind.
The contract shift: what changes when the agent is the customer
A human-oriented control plane optimizes for glanceability: dashboards, green checks, click-to-deploy. A CI-oriented one optimizes for scriptability: idempotent endpoints, exit codes. An agent-oriented one optimizes for something else — evidence the caller can reason over mid-task — and ZCP's public trust model reads as the first draft of that contract:
| Concern | Human-oriented default | Agent-oriented contract (ZCP pattern) |
|---|---|---|
| State | Dashboard renders it; human remembers it | Agent queries live state via tools; chat history explicitly untrusted |
| Verification | Green deploy checkmark | Two layers: deploy success, then behavior proof against the product request |
| Failure mode | Human reads logs, forms a theory | Recovery routed to matching evidence surface; retry-without-new-evidence is defined as non-progress |
| Blast radius | User's whole account session | One process operates exactly one project; token resolving to zero or multiple projects is refused |
| Permissions | Click-through with role prompt | Platform RBAC stays authoritative; the MCP layer adds no bypass |
| Confirmation gates | Approve-everything or approve-nothing | Routine ops (deploy, env, restart, scale) ungated and audited; hard gates only where loss is irreversible (service deletion, wholesale replacement) |
| Credentials | One login | Three separated surfaces: project token, agent subscription/key, git-or-CI credentials |
Three rows deserve emphasis. First, the one-project boundary: ZCP_API_KEY resolves to exactly one project at startup, and production is meant to be a separate project with no zcp service at all. That is deny-by-default scoping done right — the agent's credential cannot wander, because wandering is unrepresentable. Second, RBAC remaining authoritative means the agent surface inherits every permission decision the platform already made instead of inventing a parallel policy engine. Third, the confirmation philosophy inverts the naive "agents are dangerous, gate everything" instinct: routine operations flow ungated with audit evidence, and friction concentrates exactly where mistakes are unrecoverable. Gate the delete, not the deploy.
The feature-war scoreboard: Zerops vs Render vs Railway
Zerops is not entering an empty field. The deploy-from-chat feature war is already underway — which makes the comparison the interesting part.
Render ships a hosted MCP server (plus open-source implementation) with official plugins for Claude Code, Codex, and Cursor. Authenticate with OAuth or an API key, and natural-language prompts can create and redeploy services, query databases, and analyze metrics and logs. Render's docs carry the honest warning this category needs: connecting grants the AI tool access to workspaces and services, including destructive operations like env-var changes and deploys.
Railway takes the skills route: the railway-skills repo publishes agent skills backed by Railway's GraphQL API, with remote MCP authentication over Railway OAuth and a railway mcp CLI-backed local server for those who want one. Skills plus API helpers (with agent-session headers for attribution) rather than a single hosted endpoint.
Third parties are already papering over the gaps: community-built MCP servers wrap Render's API for deploy-and-diagnose flows, and at least one unified deploy-dashboard MCP manages Vercel, Render, Railway, and Fly.io services from a single endpoint. When third parties unify your control plane before you agent-enable it, the demand signal is unambiguous.
Scored against the agent-oriented contract above:
| Capability | Zerops ZCP | Render MCP | Railway skills/MCP |
|---|---|---|---|
| Agent reads live infra state | Yes — first-class work-loop step | Yes — list/query tools | Yes — via GraphQL helpers |
| Behavior proof gate | Yes — documented two-layer verification | No — deploy success is the terminal signal | No |
| Behavioral evals published | Yes — scenario evals in-repo | Not publicly | Not publicly |
| Credential scoping | One project per process, enforced | Account/workspace via OAuth or API key | OAuth + per-session headers |
| Open-source server | Yes (zeropsio/zcp) | Yes (render-oss/render-mcp-server) | Yes (railwayapp/railway-skills) |
| Agent runs against prod-like env | Yes — unified env is the architecture | Preview envs are a separate construct | Preview envs are a separate construct |
The pattern: incumbents wrap a human-designed API in MCP tools — valuable, but the underlying verbs (deploy, list, restart) still assume a human verifies the outcome. Zerops designed the loop agent-first: state-reading before acting, evidence-typed recovery, behavior proof before delivery. That is a real architectural lead, with one honest caveat — Zerops is a seed-stage company on owned bare metal, and its proof burden for reliability, scale, and security review is correspondingly heavier than Render's or Railway's. Design lead is not market lead.
A five-item MCP roadmap checklist for self-hosted platforms
For a Cluster-API-based platform (or any self-hosted PaaS) scoping its own MCP surface, the scoreboard gives a concrete answer to the design-target question: scope around "an agent debugging a live deploy," not "an agent triggering one." Triggering is the easy verb; every incumbent already exposes it. Debugging is where the contract above either holds or collapses. Five items, in dependency order:
- Queryable live state before operable verbs. Ship state-reading tools (services, revisions, env keys, events, logs) before — or at least with — deploy/restart tools. An agent that can act but cannot observe will paste stale assumptions into production. ZCP's "chat history is not the source of truth" is the principle; a status surface agents read without scraping is the implementation.
- Deploy evidence as structured output. Build logs, runtime logs, platform events, and verification results must be tool-returnable, typed data — not dashboard screenshots or "check the logs" prose. Evidence-typed recovery (build failure → build logs; start failure → runtime logs; behavior failure → request-time logs) is what turns a failed deploy from guesswork into a diagnosis surface.
- A behavior-proof gate in the loop. Define what "done" means per task type (endpoint returns the shape, job processed, data persisted) and require the agent to report proof — runtime, URL, behavior checked — rather than accepting deploy success. This is the single biggest gap between ZCP and the incumbent surfaces, and the cheapest to close: it is a prompt-and-schema change more than an infrastructure change.
- Project-scoped, revocable agent credentials. One credential, one project, RBAC-authoritative, with production unreachable by construction rather than by policy reminder. Separate the agent's model credentials from its platform token from delivery credentials, the way ZCP's three surfaces do — conflating them is how a leaked chat log becomes an infrastructure breach.
- Behavioral evals for the agent loop. Script the golden paths (fresh deploy, env change, failed build recovery, interrupted-session resume) against a real playground project and run them in CI. Zerops verifies rendered text through a headless browser; the method matters less than the existence of a suite that fails when the agent loop regresses. No evals, no agent feature — it is untestable CLI surface otherwise.
Items 1–3 are loop design, item 4 is the trust model, item 5 is how you know any of it still works next quarter. A platform that ships all five has an agent-oriented control plane; a platform that ships deploy-and-restart tools has a demo.
The customer changed; the interface must follow
Gi21's Špoljarič framed the Zerops bet as demographics: millions of developers plus their agents, on platforms designed for neither. Whether Zerops itself wins that bet will depend on execution far beyond ZCP — datacenter buildout, reliability, enterprise trust. But the interface question the round poses is already settled by the scoreboard: the agent is becoming a primary consumer of PaaS control planes, the verbs that serve a human (deploy, glance, click) underserve an agent (read state, gather evidence, prove behavior), and the platforms treating that gap as an architecture problem rather than a plugin problem are pulling ahead on design.
The cheapest way to start is also the most diagnostic: pick one golden path — an agent debugging a failed deploy on your platform today — and watch where it stalls. Every stall is a missing row in the contract table. Fill those rows before adding more tools.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first app today.
