zeabur: a deployment platform that an AI agent can drive

A platform, and a repository that documents it

This repository is not the platform implementation. The top-level listing is short: a docs/ directory, a schema/ directory, a scripts/ directory, a readme.md, a .claude/ directory and a .github/ directory. The contribution guidance in the readme says it plainly, with docs as the first category, where contributions are pull requests in this repository that fix errors, improve clarity or add examples. Templates are a second category, published to the marketplace for rewards, with a template format guide to get started, and OSS projects are a third, pointing at the wider zeabur GitHub organisation.

So the source here is the written contract between the platform and the people using it, plus the machine-readable schema that other tools read. That distinction matters for anyone evaluating the project, because the thing you would actually deploy against is the hosted service at zeabur.com, and the code that runs it is not in this repository.

The platform itself is described as helping you deploy services with one click, and the current positioning in the readme is more specific than that. Zeabur is introduced as an AI DevOps engineer: you tell an AI agent what you need, and Zeabur deploys services, rents servers, manages domains, configures databases and troubleshoots issues through natural language, with no DevOps expertise required.

That framing is the whole pitch of the readme, and the rest of it is the evidence: an MCP server, a Claude Code plugin, a VS Code and Cursor extension, a GraphQL API, a CLI, and WebSocket subscriptions for real-time logs and project events. The licence is MPL-2.0 and the last push was on 2026-10-16.

For the audience, the readme's own claim is that it is for people who want deployment to be something an agent can do rather than something an operator does.

Automatic stack detection, and what that costs you

The deployment section describes the platform's central convenience. Zeabur automatically analyses your code to detect its language and framework, with no Dockerfile or docker-compose.yml required. Push to your repository and Zeabur builds, deploys and updates your service automatically.

The supported input paths are broad: GitHub integration, Dockerfile, Docker images, CLI, a Chrome extension, and more. So the detection is a convenience layer over the inputs you would otherwise have to write by hand, not a replacement for them, and a team with an existing Dockerfile can keep using it.

The design decision worth thinking about is where the build definition lives when detection is used. If the platform infers the language and framework from the repository contents, then the build for a given service is not something you wrote, it is something the platform derived, and it can change when the platform's detection rules change. For a hobby project that is a clear win. For a service with a specific toolchain version, a native dependency, a custom build step or a particular base image, inference is going to be wrong, and the resolution is to take control by supplying your own Dockerfile, which the platform accepts. The readme is thin on how the detection prioritises these cases, so a team with a non-trivial build should not rely on it without checking.

The other thing to note is what a platform like this takes over. The configuration section says environment variables are managed from the dashboard with no .env files required, and that you can roll back, suspend, restart and scale services with one click. There is also team collaboration on the same project, and full domain management in the same place, with free zeabur.app subdomains or a custom domain, and DNS records and registrant profiles handled alongside.

Two infrastructure shapes, and a third one you bring yourself

Zeabur supports two infrastructure options, and the choice between them is a genuine architectural decision rather than a pricing tier.

Servers are single-machine deployments. You buy a server from Zeabur or bring your own hardware, with AWS, GCP, Hetzner and your own datacenter named as examples. Zeabur manages deployments, firewall rules and resource allocation, and no SSH is required. Billing is monthly at a fixed rate, and the readme positions this option for small-to-medium workloads and stable production services.

Clusters are multi-node Kubernetes environments for high-availability workloads, giving cross-node scheduling, automatic failover, distributed storage and horizontal scaling. You purchase a cluster from Zeabur or connect your own existing Kubernetes cluster.

The third option is Wonder Mesh, which turns any computer or server into a Zeabur compute node over an encrypted WireGuard tunnel, with no public IP, no port forwarding and no firewall changes needed. It works from home labs or offices, you deploy templates, push code, bind domains and monitor resources as with a managed server, and it supports Linux and macOS on both amd64 and arm64.

Wonder Mesh is the interesting one for an engineer, because it inverts the usual direction of the relationship. Instead of the platform provisioning hardware, your hardware joins the platform, and the tunnel does the networking. For a team with spare machines or a homelab it removes the public IP problem entirely. It also means the platform is in the path for those workloads, and the readme does not describe what happens to a node that drops off the tunnel or how the platform handles nodes in different networks.

Templates are the other layer that reduces per-project work. The catalogue covers WordPress, Postgres, Redis, n8n, Ghost and hundreds more, each pre-wiring services, environment variables and connection settings, and you can create and share your own templates as YAML.

The agent interfaces, and the commands that install one

The AI-native section is the part that distinguishes this platform, and it comes with concrete installation steps.

The Claude Code plugin is described as Zeabur's official plugin that converts natural language into infrastructure operations, so you can rent servers, deploy services, bind domains, manage databases and debug issues without leaving your editor. It is added with two commands:

claude plugin marketplace add zeabur/zeabur-claude-plugin
claude plugin install zeabur@zeabur

The MCP server is the more general route. It connects Zeabur to any MCP-compatible AI assistant, with Claude Desktop and Cursor named as examples, and covers managing projects, deployments, environment variables and logs through conversation. Note what the platform is exposing to a model: the ability to change deployment state and read logs, which is why the readme frames the whole platform as an AI DevOps engineer rather than as a dashboard with a chat box attached.

The VS Code and Cursor extension is the third surface, deploying a local project to Zeabur in one click without leaving the editor. There is also a Chrome extension listed among the deployment inputs.

For developers who would rather not leave the terminal, the Zeabur CLI is invoked with npx zeabur, and the GraphQL API at api.zeabur.com/graphql gives full programmatic access to projects, services, deployments and logs. There are REST APIs too, including an upload API for ZIP deployments and the Email REST API, and WebSocket subscriptions for streaming real-time logs and project events.

The product adjacent to this is InsForge, described as an agent-native Supabase alternative with PostgreSQL, JWT auth, S3-compatible storage, serverless edge functions and MCP support, aimed at AI agents building full-stack apps autonomously.

Where zeabur is the wrong choice

The first limitation is the one the repository structure makes obvious. This is documentation, templates and a schema, not a platform you can run. If your requirement is a deployment platform you host and control, the code to run Zeabur is not here, and the self-hosted path is not something the readme offers.

The second is what a managed platform takes from you. Environment variables move to the dashboard, which means no .env files and no local-parity file in the repository, and a developer's local setup and the deployed environment can drift in a way that is harder to see in review. Servers means Zeabur manages the firewall rules and the resource allocation for the machine, and while no SSH is required, that is also control given up rather than control retained.

The third is the pricing shape on the Servers option, billed monthly at a fixed rate. A fixed monthly charge suits a service with steady traffic and a predictable load, and it is an awkward fit for something spiky, where a service is idle for most of the day and busy for an hour. Clusters and the higher availability they bring are a different purchase again.

The fourth is the agent-first framing, which is a bet. Putting the deployment API in reach of a model means an agent can rent servers, change deployments and read logs, which is exactly the point and also exactly the thing a security reviewer will want to reason about. The readme says the email service has a 99.9% uptime guarantee and that the community forum has priority response times for paid plans, and it does not say anything about how agent-driven operations are bounded, audited or rolled back.

The fifth is the dependency on the platform's own terms and infrastructure for things the readme lists as features: the email service is built on AWS SES, so a mail-reliant product now depends on that provider's behaviour as well as Zeabur's. Cluster mode is Kubernetes, which is a genuine benefit if you already know Kubernetes and a new operational surface if you do not.

Editorial conclusion

zeabur fits a small team that wants a hosted platform with no Dockerfile to write, and an interesting one for teams already building agent-driven workflows, since the platform exposes projects, deployments, environment variables and logs over GraphQL, REST, WebSocket, an MCP server and a Claude Code plugin rather than only through a dashboard. It is the wrong choice if you need a platform you host yourself, if you need region-specific data residency or compliance guarantees the documentation does not state, or if you want the AI operations to be the primary interface rather than an addition. Before deploying, read the one-click detection behaviour, because Zeabur analysing your code to pick a framework is convenient and also means the platform decides how your service is built, and note that the last push was on 2026-10-16 with the source here being the docs, templates and schema rather than the platform implementation.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. Project website
4. README
5. zeabur/zeabur on GitHub