Reboot server

POST /v1/infra/servers/:id/reboot

Reboots a running server at the cloud provider. During the reboot the server moves to provisioning, the tunnel is briefly dropped — blackholeStatus becomes DISCONNECTED — and reconnects after the virtual machine starts. The operation is atomic: an internal database-level guard prevents races if several calls arrive at once. If the provider does not support reboot, the endpoint returns 501 and the status is rolled back to running.

Parameters

The request body is empty.

Examples

curl — personal key

curl -X POST -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/reboot

curl — OAuth application

curl -X POST -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/reboot

JavaScript — personal key

await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/reboot`,
  { method: 'POST', headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
)

// Poll readiness after the reboot
while (true) {
  await new Promise(r => setTimeout(r, 5000))
  const res = await fetch(
    `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}`,
    { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
  )
  const { data } = await res.json()
  if (data.status === 'running' && data.blackholeStatus === 'CONNECTED') break
}

JavaScript — OAuth application

await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/reboot`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)

Response fields

Response example

{ "success": true }

Error response example

422 — the server exists but is not in running status. The response carries the current state and the actions available now:

{
  "success": false,
  "error": {
    "code": "SERVER_WRONG_STATE",
    "message": "Server is SLEEPING; /reboot requires RUNNING.",
    "userMessage": "Server is currently SLEEPING. Reboot only applies to a RUNNING server.",
    "currentState": { "status": "sleeping", "blackholeStatus": "DISCONNECTED", "hasExternalId": true },
    "availableActions": ["wake", "start", "repair", "delete"]
  }
}

409 — the server status changed during the operation (race):

{
  "success": false,
  "error": {
    "code": "CONFLICT",
    "message": "Server state changed during operation"
  }
}

Errors

The full list of common API errors — Errors.

Known specifics

• Atomic transition running → provisioning. The database is updated with a single updateMany conditioned on status = 'RUNNING'. If another /reboot or /stop arrives at the same moment, the second call gets 409 CONFLICT.
• Automatic rollback on a provider error. If adapter.rebootServer() throws an exception, the record is reverted to running status — so the client is not left with a "stuck" provisioning.
• To restart only the application (without rebooting the virtual machine), use POST /exec with the command systemctl restart app — it is dozens of times faster and does not break the tunnel. This process restart does not itself delete server or application files. If a different service name (serviceName) was configured during deployment, replace app with that name. The application itself may modify its data on startup.
• After a reboot, wait for both fields. For the server to be ready, you need both status: "running" and blackholeStatus: "CONNECTED" at the same time — the tunnel reconnects after the virtual machine starts.

Galaxy apps (kind=GALAXY_APP)

For a Galaxy app container (kind=GALAXY_APP — it has no virtual machine of its own), /reboot restarts the container on the host rather than rebooting a VM. It is a self-recovery kick for a stuck or crash-looping app: it does not wipe the persistent /data volume (unlike deletion).

The restart is advisory — it does not change the record's status and does not clear the crash marker. After the restart the container is probed, and the response carries a healthy verdict: whether the container came up and stopped restarting. This inspects the container state (docker inspect), not the app's HTTP response. A crash-looping app is authoritatively fixed by redeploying its source via POST /v1/infra/servers/:id/deploy — redeploy is what clears the error state.

The app accepts /reboot in the running or error status (a regular server accepts only running).

Response fields

The verdict is nested under data (unlike a regular server reboot, whose body is the flat { "success": true }).

{ "success": true, "data": { "restarted": true, "healthy": false, "hint": "Redeploy the fixed source via POST /v1/infra/servers/:id/deploy" } }

Errors

An app refusal also repairs the host

A Galaxy app whose host has lost its connection to the platform hits the same barrier in every operation: both waking and deploying go through the host, and the host is unreachable. So before the 422 SERVER_WRONG_STATE refusal, the platform starts restoring the host connection in the background — the refusal itself still stands, but the next attempt has a chance to go through.

If the repair did start, the error body carries an optional hint object:

The hint object may be absent, and that is not an error. It is missing when no repair was started: the host connection is in fact alive, a repair is already under way or finished recently, the host itself is off or asleep, it was woken recently, the guest system on the machine does not boot, the machine is blocked from waking, or automatic recovery is switched off on the platform. Read hint as an optional cue — if it is there, wait the stated time and retry the deploy; if it is not, act on the error code.

Repeat calls do not start a new repair. While a repair is running, and for 10 minutes after it ends — successfully or not — the platform starts no new one, so a repeat refusal arrives without hint. This is the same ten-minute window as the lifetime of a completed record in Repair status. A repair that broke off and stopped reporting is treated as dead after 20 minutes and may be started again.

The retryAfterSeconds value is 300 and stays a lower bound on the wait rather than a promise of readiness: retrying sooner buys nothing, retrying later is fine.

The 502 GALAXY_HOST_UNREACHABLE refusal carries a different hint — four fields instead of three, with their own set of values. They are described under "The error.hint field of GALAXY_HOST_UNREACHABLE" on the Galaxy app page. The shape of the cue is set by the refusal code, so parse it by the code rather than by the page it appeared on.

See also

• Start the server
• Stop the server
• Repair tunnel
• Run a command