Computers

Start a computer

Boots a stopped computer, or resumes a suspended one. A cold start that would deliver secrets answers 409 while a workspace change is pending or the recorded binding scope disagrees with the computer’s current workspace. Check the workspace change in the dashboard. For conflicting bindings, remove them with PUT /computers/{id}/secrets and {"secrets":[]}, check any pending workspace change again, then retry with no bindings or bind secrets in the current workspace.

A computer the platform is holding for disk-space recovery, after a suspend or memory snapshot failed (at any free space; see POST /computers/{id}/suspend), answers 503 (“waiting for disk-space recovery”) until it resumes by itself once that recovery can finish. Stop it to discard the paused session instead; one that already reads stopped will not resume by itself, so stop it.

On a host that is low on disk space a start or resume answers 503 (“this host is low on disk space; this computer cannot start or resume until space has been freed”) and starts nothing; a suspended computer keeps its saved session. It is refused the same way until space on that host has been freed, so sending it again soon does not help. One saying the host’s disk space “cannot be checked right now” is a failed reading, and can be sent again shortly. If the message adds that its paused QEMU could not be stopped, stop the computer before trying again.

Requires the member role or higher.

post/computers/{id}/start

Request

  • Base URL: https://app.mandala.computer/api/v1
  • URL: https://app.mandala.computer/api/v1/computers/{id}/start
  • Auth: HTTP bearer

Path parameters

idstring required

The computer id.

Query parameters

resume_only'true'

Resume only if a saved session still exists. A stopped computer is not booted and the call succeeds, but it is checked against your plan first like any start, so it can answer 402, or 503 when your plan usage cannot be checked.

Headers

Idempotency-Keystring

Optional: a key of your choosing, 1 to 255 printable ASCII characters with no spaces (a UUID is ideal), that makes this call safe to send again after a lost answer. The call and its operation are recorded BEFORE it is carried out, so GET /operations?idempotency_key= finds it however the connection ended. For 24 hours, the same key with the byte-identical request (method, path, query and body, from a credential of the same scope) is not carried out again: it answers 409 idempotency_in_progress while the first is running, and the original answer — status and body, with Idempotent-Replayed: true — once it has finished. An answer too large to keep (over 1 MiB) is replayed instead as a 200 carrying {operation_id, operation}, also with Idempotent-Replayed: true: operation is the call’s operation, or null when there is none to show. Keys are kept per scope: a key used by a workspace's credential and the same key used by another workspace's, or by an account-wide one, are different keys, and neither is refused because of the other. A replayed body omits the desktop credentials the original carried (vnc, with its tokens and URLs): read the computer (GET /computers/{id}) for them. The same key on a different request is a 422 with code: "idempotency_key_reused", and a malformed key (empty, too long, outside printable ASCII, or the header sent twice) a 400 with code: "idempotency_key_invalid"; neither does anything. A call refused with a 4xx that did nothing releases its key, so it may be sent again under the same one. The exception is a delete whose 4xx says the computer was deleted — computer_deleted: true, or a purge result beside computer_deleted: false (it was deleted, then listed again): it happened, so its key keeps that answer and its operation is succeeded. Except a 409 with reason: "contention" whose purge deleted, queued and left in doubt nothing (the computer was already gone and copies in use refused the purge): nothing happened, so its key is released and the same request may be sent again under it. With computer_deleted: null, or false where the platform cannot confirm the computer was left in place, it is an unknown outcome: its key answers 409 idempotency_in_progress until the platform gives up on it, then 409 idempotency_outcome_unknown. A 5xx answer that names an operation_id is an unknown outcome too: that is the operation reserved for it. From then on the same key answers 409 idempotency_outcome_unknown, naming that operation (not idempotency_in_progress): read the computer, or the operation. The operation stays pending until the platform gives up on it; if it never learns how the call ended, it becomes failed with error.code: "lost". Some 5xx answers are refusals given before the call was sent anywhere — the platform could not check the account’s usage, or find a host for the call, for example — and some are a create or clone the host confirms it refused before building anything, such as a 503 from a host with no room left, and some are a start, restore or suspend the host confirms it refused before changing anything (a sealed session whose key could not be opened or whose transport failed first; on a suspend, suspend_outcome: "not_started"). Those name no operation_id: nothing was done, so the key is released as a 4xx refusal’s is, and the same call may be sent again under the same key. A host running older software cannot confirm such a refusal, so its 5xx is an unknown outcome like any other. A 5xx without an operation_id is not proof that nothing was done on its own: a call that records no operation (a PATCH that does not resize) names none, and neither does one whose operation could not be recorded. Sending the same call again under the same key is safe after any 5xx: it is carried out if its key was released, and answered 409 idempotency_outcome_unknown if not.

Response

Started, or no saved session remains when resume_only=true.

okboolean required

Always true. A failure is a status code, not ok: false.

operation_idstring

This call’s operation, already succeeded: the step was done before the answer was sent. Read it with GET /operations/{id}. Absent, with the call still done, in the rare case the operation could not be recorded; a client must not treat its absence as a failure of the call.

Changes

No recorded changes to this operation across all 1 revision of this API.