server-manage

name	server-manage
description	Use when managing an existing Zeabur-rented server — checking status, listing servers, powering on/off, rebooting, or reinstalling the OS. Use when the user says "restart my server", "is my server up", "wipe and reinstall", or "list my servers". 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 Manage

Day-2 operations for rented servers. Set up the zapi helper from the auth skill first. All queries take an optional ownerID for team workspaces.

List servers

zapi '{"query":"{ servers { _id name ip sshPort sshUsername provisioningStatus expiresAt price providerInfo { code name } country city status { vmStatus isOnline } } }"}' \
  | jq -r '.data.servers[] | "\(._id)\t\(.name)\t\(.ip)\t\(.status.vmStatus // "-")\tUS$\(.price)/mo"'

Check one server

zapi '{"query":"query($id: ObjectID!){ server(_id: $id) { name ip sshPort sshUsername provisioningStatus expiresAt status { vmStatus isOnline usedCPU totalCPU usedMemory totalMemory usedDisk totalDisk } events { message time severity } } }","variables":{"id":"<server-id>"}}' \
  | jq '.data.server'

events carries provisioning/operation progress and errors — read it when something looks stuck.

Historical metrics (averages, trends)

kubectl top and the in-cluster Metrics Server only give instantaneous snapshots. For machine-level history (e.g. "average CPU over the last 30 minutes"), query Zeabur's metrics pipeline — on ZeaburOS machines the operator feeds it, and the dashboard charts read the same data:

zapi '{"query":"query($id: ObjectID!, $type: MetricType!, $start: Time!, $end: Time!){ server(_id: $id) { metrics(metricType: $type, startTime: $start, endTime: $end) { labels values { timestamp value } } } }","variables":{"id":"<server-id>","type":"CPU","start":"<ISO8601>","end":"<ISO8601>"}}'

MetricType: CPU / MEMORY / DISK / NETWORK. Average the values with jq. This is machine-level; per-pod history is not collected for toolkit workloads (only instantaneous kubectl top pod).

Power on / off / reboot

zapi '{"query":"mutation($id: ObjectID!){ poweronServer(_id: $id) }","variables":{"id":"<server-id>"}}'
zapi '{"query":"mutation($id: ObjectID!){ poweroffServer(_id: $id) }","variables":{"id":"<server-id>"}}'
zapi '{"query":"mutation($id: ObjectID!){ rebootServer(_id: $id) }","variables":{"id":"<server-id>"}}'

Powering off does not stop billing — the machine is still rented. After any of these, poll status.vmStatus until it settles (RUNNING / STOPPED).

⚠️ Reinstall — erases the disk

reinstallServer wipes the machine back to a clean base OS. Everything on it is destroyed. Before running it, say that plainly, tell the user to back up first, and get an explicit yes for this specific server — name it by name and IP in the confirmation question.

OP_ID=$(uuidgen)
zapi "$(jq -n --arg op "$OP_ID" --arg id "<server-id>" '{query: "mutation($id: ObjectID!, $op: String){ reinstallServer(_id: $id, operationID: $op) }", variables: {id: $id, op: $op}}')"

Reinstall takes several minutes; poll provisioningStatus back to READY, then reveal the new root password the same way as after renting (see the server-rent skill). The machine's SSH host key changes with the reinstall — clear the stale entry before reconnecting: ssh-keygen -R "[<ip>]:<port>" (or ssh-keygen -R <ip> for port 22).

Not covered here

Renewal, refunds, spec upgrades, disk attach/detach, and traffic-pack queries are managed in the Zeabur dashboard for now.