Managing servers
Server states
| Status | Meaning |
|---|---|
provisioning | Being set up by us. Not yet operable. |
active | Running normally. Reboot and re-image are available. |
rebooting | A reboot is in progress. |
reimaging | A re-image is in progress. |
error | The last operation failed. Reboot and re-image are still available — this is the recovery path. |
retired | No longer in service. |
Reboot and re-image are accepted only from active and error. Anything else returns
409 server-not-ready, and a machine that already has an operation running returns
409 server-busy.
Asynchronous operations
Reboot and re-image operations return 202 with an action, then run in the background. Poll
GET /api/v1/actions/{id} until status is succeeded or failed; a failure carries the reason in
error.
This is the one workflow worth writing out end to end, because it is the shape every power operation takes: start it, then follow the action it hands back.
ACTION=$(curl -s -X POST "https://braesystems.com/api/v1/servers/$SERVER_ID/reboot" \
-H "Authorization: Bearer bs_live_..." | jq -r .data.id)
while :; do
STATUS=$(curl -s "https://braesystems.com/api/v1/actions/$ACTION" \
-H "Authorization: Bearer bs_live_..." | jq -r .data.status)
echo "$STATUS"
case "$STATUS" in succeeded|failed) break ;; esac
sleep 10
doneThe simulated field
Every action carries a simulated boolean. It is true when the action ran against a
short-circuited environment — a preview deployment, where hardware operations report success after a
short delay without touching a machine.
In production it is always false. It exists so a simulated success can never be mistaken for a real
power cycle after the fact.
Reboot
curl -X POST https://braesystems.com/api/v1/servers/$SERVER_ID/reboot \
-H "Authorization: Bearer bs_live_..."A graceful restart is attempted first, which asks the operating system to shut down cleanly. If the machine has not returned after roughly five minutes we escalate to a forced restart. If it still has not returned after ten, the action fails.
The failure message distinguishes two cases, because they call for different responses:
- “Server never left power state On” — the restart was ignored. Investigate the operating system.
- “Server did not return to power state On” — it went down and did not come back. Investigate the hardware, or contact us.
Re-image
Re-imaging erases every disk on the server. All data on it is destroyed and there is no undo.
curl -X POST https://braesystems.com/api/v1/servers/$SERVER_ID/reimage \
-H "Authorization: Bearer bs_live_..." \
-H "Content-Type: application/json" \
-d '{"image":"ubuntu-24-04"}'image is a slug from GET /api/v1/images. Optionally pass ssh_key_ids to install a specific subset
of your keys; omit it and every key on the account is installed.
A re-image with no keys is rejected before anything is erased — a rebuilt server with no key would be one you could not log into.
What happens
- We validate the request: the image exists, the keys belong to your account, and there is at least one of them.
- The installer image and a configuration volume carrying your SSH keys are mounted over the server’s virtual media.
- The machine is set to boot from the installer once, then power-cycled.
- Every disk in the server is erased, including data drives that are not the boot volume.
- The operating system is installed on the boot volume and reports back when it finishes.
- Both volumes are unmounted and the server returns to
active.
Typically fifteen to forty minutes depending on the image. If the installer has not reported back
within two hours the action fails and the server is marked error.
Step 4 erases partition tables and filesystem signatures on every disk, which makes the data unreachable by any normal means. It is not a certified secure erase — the blocks themselves are not overwritten, so specialist recovery of a physically obtained drive is not ruled out. Tell us if you need a certified wipe before hardware leaves your control.
Listing addresses
Addresses are also available on their own:
curl https://braesystems.com/api/v1/servers/$SERVER_ID/ips \
-H "Authorization: Bearer bs_live_..."{
"data": [
{
"address": "203.0.113.11",
"version": 4,
"kind": "public"
},
{
"address": "2001:db8:1::11",
"version": 6,
"kind": "public"
}
]
}This endpoint returns one flat list rather than the separate ipv4 and ipv6 arrays a server carries,
so version is what tells the two families apart here.
Addresses survive a re-image — rebuilding a server does not change how you reach it.