Dora NodaOpen Zeabur's homepage today and the headline hits you before the nav bar finishes loading: "Your AI DevOps Engineer." Not a PaaS with an AI assistant. Not a dashboard with a chatbot. An engineer — a role, not a feature — that "runs your infrastructure while AI writes your code."
It is the boldest positioning move any git-push platform has made in the agent era, and it deserves a serious reading rather than an eye-roll. So here is the verdict up front, with the receipts below: Zeabur shipped a real thing — Agent Skills plugins that run deploy, server-rental, and config actions from inside Claude Code and Codex. But the substance is a conversational layer over the platform's existing actions.
Its genuine differentiator against Render's agent story is server rental, not deeper agent authority. On the operations that actually define "an agent runs your infrastructure" — deploy, rollback, scale, logs, secrets, database access — Render's official MCP server already gives agents as much or more, with no rebrand required. Marketing: ahead. Authority: roughly even. And the whole comparison previews the bar every agent-operator pitch, including ours, now has to clear.
What "AI DevOps engineer" concretely buys you today
Strip the headline and Zeabur's agent story has three layers: the Skills plugins, the platform actions underneath, and the APIs those actions were already exposed through.
Layer one is Zeabur Agent Skills, published at zeabur/agent-skills and installed as a plugin, not a dashboard toggle:
claude plugin marketplace add zeabur/agent-skills
claude plugin install zeabur@zeaburCodex gets the mirror image (codex plugin marketplace add zeabur/agent-skills, then codex plugin add zeabur@zeabur). Once installed, the agent gains what Zeabur's Skills page summarizes as "DevOps with a single prompt": deploy services, rent servers, and manage configs from a line of chat, without context-switching to the dashboard.
Layer two is what those prompts can actually do. The Skills page names three capabilities, and they are worth quoting precisely because the scope is narrower than "engineer" suggests:
- Rent servers. Browse and rent discounted servers from AWS, Hetzner, Linode, and more by describing the spec. This is the genuinely unusual one — no other git-push PaaS lets an agent provision the underlying machine through the same chat interface that deploys the app.
- Deploy services. Ship a local project or a marketplace template; Zeabur detects the framework and deploys it to your server.
- Enable AI models. Route GPT, Claude, and Gemini calls through Zeabur's AI Hub with one API surface instead of managing a key per provider.
Layer three is the foundation none of this replaces. Zeabur's public API is GraphQL-first — a single endpoint at api.zeabur.com/graphql exposing projects, environments, services, deployments, environment variables, domains, regions, and templates — with a CLI (npx zeabur) and a handful of REST APIs (ZIP-upload deploys, email) alongside. The Skills do not bypass this stack; they ride on top of it. That is not a criticism — it is how every serious agent interface works, including Render's. But it sets up the right question: what does an agent gain from Zeabur's framing that it could not already get from a documented API plus a skill file?
What an agent can already do on Render — no rebrand required
While Zeabur was writing headlines, Render shipped the unglamorous version of the same idea: an official MCP server, hosted at https://mcp.render.com/mcp and open-sourced as render-oss/render-mcp-server, that lets Claude, Codex, and Cursor manage Render resources through the Model Context Protocol — the open standard for agent tool calls, not a vendor plugin format.
The tool surface reads like a DevOps engineer's Tuesday: list and inspect services, create new services, redeploy existing ones, query Postgres databases, update environment variables, and pull logs and performance metrics. Render's own docs are candid that the server supports "potentially destructive operations, including modifying a service's environment variables and triggering deploys" — which is exactly what "an agent runs your infrastructure" has to mean to be more than a demo. Auth is OAuth for interactive use or a plain API key (Authorization: Bearer) for non-interactive environments, and Render ships official plugins plus skills for all three major agent harnesses.
Notice what Render did not do: rename the company, coin a job title, or ask anyone to learn a new concept. The MCP server is a tool adapter over the Render API the way Zeabur's Skills are a prompt adapter over the Zeabur GraphQL API. The difference is the interface standard (open MCP tools any harness can call vs. plugin skills for two specific harnesses) and the action set — which brings us to the scorecard.
Head to head: the agent-authority scorecard
Titles argue; tables settle. Here is what each platform's agent path actually authorizes today, plus where bex's Render-compatible API plus roadmapped MCP server lands on the same axes:
| Agent capability | Zeabur (Agent Skills) | Render (official MCP) | Bex (Render-compatible API) |
|---|---|---|---|
| Deploy / redeploy a service | Yes — deploy local project or template | Yes — redeploy + create services | Yes — Render API shape, agent-callable today |
| Roll back to a previous deploy | Via dashboard/API, not a named skill action | Via API primitives the tools wrap | Via API; first-class MCP tool roadmapped |
| Scale / change plan | Via dashboard/API | Via service-update tools | Via API |
| Read logs and metrics | Dashboard-first; skill coverage partial | Yes — log querying + metrics tools | Via API; MCP tools roadmapped |
| Manage env vars and secrets | Yes — "manage configs" is a named skill action | Yes — explicit env-var tools | Via API |
| Database operations | Managed DBs via platform; template deploys | Yes — query Postgres, KV stores | Bring your own (no managed DBs — a deliberate non-goal) |
| Provision the underlying server | Yes — rent from AWS/Hetzner/Linode by chat | No — managed fleet only | N/A — you already own the machines |
| Auth for non-interactive agents | Account-bound plugin install | API key bearer token | API key bearer token (Render-compatible) |
| Interface standard | Vendor plugin skills (Claude Code, Codex) | Open MCP tools (any MCP harness) | Open standards: Render API now, MCP next |
Two readings fall out of this table. First, Zeabur's one uncontested lead is the server-rental row: neither Render nor bex lets an agent go from "I need a bigger box" to a billed, provisioned machine in one prompt, because Render abstracts machines away and bex assumes you own them. If your mental model of a DevOps engineer includes procuring hardware, Zeabur is the only platform above that automated it.
Second, on every operate-the-running-system row — deploy, rollback, scale, logs, secrets, database reads — Render's MCP server matches or exceeds the Skills' named actions, and it does so over an open protocol any harness can speak. An agent that learned Render's tools can be pointed at any Render-compatible API without relearning a vendor skill. That portability is the quiet variable the branding conversation skips: skills lock the agent to the platform that wrote them; MCP tools and REST APIs let the agent roam.
The agent-operator test: four questions the branding has to survive
Strip every vendor's framing and "an agent runs your infrastructure" reduces to four testable questions. Apply them to Zeabur, Render, and bex alike:
- Is there a documented API under the chat? All three pass. Zeabur's GraphQL endpoint, Render's REST API, and bex's Render-compatible API each give agents (and auditors) something to call that outlives any assistant UI. Any "AI engineer" without this is a demo with a billing page.
- Is infrastructure state machine-readable? Render passes cleanly — services, deploys, and environments come back as structured tool results an agent can reason over. Zeabur partially passes: the GraphQL API returns structured state, but the Skills' chat-first surface is the documented agent path, and chat transcripts are a lossy state store. Bex inherits Render's shape by compatibility, which is precisely why compatibility matters: every Render-targeting agent already speaks it.
- Does the agent hold real mutate authority — including rollback? This is the sharpest edge. Deploy authority without rollback authority is a junior with a merge button. Render's tools wrap the full deploy lifecycle through the API; Zeabur's named skill actions center on deploy-forward and config, with rollback living one layer down in the dashboard/API rather than in the chat surface. An "engineer" that can ship but cannot revert is an intern with good marketing. Both platforms should put rollback in the agent's front pocket — and any MCP server we ship will.
- Can a non-interactive agent authenticate? Render passes with API keys; bex passes the same way by design. Zeabur's plugin-install model is account-bound and interactive-first, which fits a developer chatting in Claude Code but fits a cron-triggered ops agent poorly. The DevOps engineer who only works when you are watching is not an engineer — it is a dashboard with latency.
Score it honestly and nobody sweeps: Render leads on protocol openness and lifecycle depth, Zeabur leads on machine provisioning, and bex's bet is that compatibility plus self-hosting wins the third race — the agent that operates infrastructure you own.
Where bex's pitch fits
Bex.co's position in this landscape is deliberately boring in the right places. The platform exposes a Render-compatible API, which means the Render-targeting skills, plugins, and MCP clients above operate bex without modification — no new skill to install, no new tool vocabulary to teach the agent. The dedicated MCP server is on the roadmap, not in the headline, because an MCP adapter over an already agent-readable API is an afternoon's honest work rather than a rebrand. And the self-hosted difference reframes Zeabur's server-rental lead: when the agent's job includes capacity, bex's answer is not "rent a box through chat" but "the fleet is Cluster API declarative state, so the agent edits the desired state and controllers reconcile" — provisioning as GitOps, not shopping.
That is not a claim that bex wins today's scorecard. It is a claim about which axis compounds: open protocols and owned machines get more valuable as agents get more capable, while chat wrappers get reabsorbed into every harness. Marketing can be ahead for a quarter; authority compounds for years.
The title was ahead of the product. The direction is right anyway.
Zeabur deserves credit for naming the destination first: infrastructure operated conversationally, by agents, as the default rather than the demo. "AI DevOps engineer" oversells the current action set the way every good category name does — but the Skills plugins are real, installable, and pointed at the correct target. Render, meanwhile, proved the unglamorous path works: document the API, publish MCP tools, let any harness call them.
The lesson for teams evaluating either — or building the next one — is to grade the authority, not the headline. Ask for the tool list. Ask for rollback.
Ask whether your agent keeps working when you switch harnesses, and whether it keeps working at 3 a.m. without you. The platform that answers all four is your AI DevOps engineer, whatever its homepage says.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API your agents already speak. Star the repo on GitHub or deploy your first app today.
