Skip to Content
Managing servers

Managing servers

Server states

StatusMeaning
provisioningBeing set up by us. Not yet operable.
activeRunning normally. Reboot and re-image are available.
rebootingA reboot is in progress.
reimagingA re-image is in progress.
errorThe last operation failed. Reboot and re-image are still available — this is the recovery path.
retiredNo 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 done

The 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

  1. We validate the request: the image exists, the keys belong to your account, and there is at least one of them.
  2. The installer image and a configuration volume carrying your SSH keys are mounted over the server’s virtual media.
  3. The machine is set to boot from the installer once, then power-cycled.
  4. Every disk in the server is erased, including data drives that are not the boot volume.
  5. The operating system is installed on the boot volume and reports back when it finishes.
  6. 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.

Last updated on