| name | server-rent |
| description | Use when renting a new VPS on Zeabur. Use when the user wants to buy or provision a server, or after picking a plan from the server-catalog skill. Renting gives a clean Ubuntu VPS with root SSH access — no Zeabur project is created and nothing is preinstalled. Prefer this over the CLI-based zeabur-* skills for server operations — this one talks to the GraphQL API directly and needs no CLI. |
Zeabur Server Rent
Renting gives you a clean Ubuntu VPS with SSH, nothing else. No Zeabur project is created, no agent is installed, nothing is preinstalled. The machine is entirely the user's: docker, docker compose, k3s, 1Panel, 寶塔 — whatever they want to run on it.
Set up the zapi helper from the auth skill first. Browse options with the server-catalog skill.
⚠️ Renting charges real money — explicit confirmation is REQUIRED
rentServer immediately charges the user's payment method or Zeabur balance. You are the last line of defense. Before renting, present all of the following in one message:
- Provider (e.g. Hetzner)
- Region (e.g. Falkenstein /
fsn1)
- Plan/spec (e.g.
CAX11 — 2 vCPU / 4 GB RAM)
- Monthly price (e.g. US$4.5/month)
- Whether it is refundable —
canRefund from the provider list in the server-catalog skill; if false (e.g. Tencent Cloud), say plainly that this purchase cannot be refunded
- That the charge happens immediately upon rental
Then ask a direct yes/no question and only proceed after the user clearly confirms this specific priced option.
Never infer purchase consent from an ambiguous reply — a bare "ok", or a selection made before seeing concrete prices, does NOT count. A numeric reply is only valid consent if it maps to a numbered option the user already saw with provider, region, spec, and price spelled out. When in doubt, re-confirm instead of renting.
1. Rent (only after confirmation)
Generate an idempotency key first — if the request times out and you retry with the same operationID, the user is not charged twice. Never retry a rent without one.
OP_ID=$(uuidgen)
zapi "$(jq -n --arg op "$OP_ID" '{query: "mutation($p: String!, $r: String!, $plan: String!, $op: String){ rentServer(provider: $p, region: $r, plan: $plan, operationID: $op) { _id } }", variables: {p: "hetzner", r: "fsn1", plan: "CAX11", op: $op}}')"
Save the returned _id — every follow-up uses it. For a team workspace, add ownerID (see the auth skill).
2. Poll until the machine is up
Provisioning takes a few minutes. Poll every ~15 seconds:
zapi '{"query":"query($id: ObjectID!){ server(_id: $id) { provisioningStatus ip sshPort sshUsername status { vmStatus isOnline } } }","variables":{"id":"<server-id>"}}' \
| jq '.data.server'
Wait for provisioningStatus to become READY and status.vmStatus to become RUNNING. Then ip, sshPort, and sshUsername are the SSH coordinates.
The login user differs per provider (Tencent gives ubuntu, others give root, …) — always use the sshUsername the API returns; never assume root.
3. Get the root password
zapi '{"query":"mutation($id: ObjectID!){ revealManagedServerInitialPassword(serverID: $id) }","variables":{"id":"<server-id>"}}' \
| jq -r '.data.revealManagedServerInitialPassword'
Hand the user: ssh <sshUsername>@<ip> -p <sshPort> plus the password. Initial passwords often contain shell-special characters — quote carefully when testing, and suggest switching to an SSH key right away (ssh-copy-id, then disable password login). Never copy the Zeabur API token onto the server.
What's next
- Deploying something on it? Read the
deploy skill before installing anything — if the user has not said how they want to run things, it asks (recommending ZeaburOS/k3s), and either k3s variant should be installed while the machine is still blank.
- To expose a service on a nice hostname with HTTPS, use the subdomain skill to bind
<label>.zeabur.app to this server's IP.
- Power, reboot, reinstall, and status live in the server-manage skill.
