Update a computer
To change workspace_id, use PUT /computers/{id}/workspace. Sending it here is a 400, even alongside other fields; nothing is changed.
Rename it, resize it, change how long it may idle before its host suspends it, or set its browser proxy or its egress proxy. A request with no body is a 400. So is one naming size: a resize takes explicit cpu, ram_mb and disk_gb, which are on the row in GET /sizes.
SEND ONE OF THOSE FIVE AT A TIME. name, the sizing group (cpu/ram_mb/disk_gb), idle_suspend_min, browser_proxy and egress_proxy each refuse to travel with any of the others, and a request carrying two is a 400. They are separated because a resize needs the computer stopped and the others do not, so one request could not honour both without silently applying half of it.
A browser_proxy sent to a running computer is written into it within seconds (watch browser_proxy_pending); sent to a stopped or suspended one it is stored and applied as it starts. One sent to a host that cannot set a browser proxy yet — a null included — answers 409 with reason: "unsupported", as does a setting naming credentials_secret_id sent to a host that cannot give a browser proxy credentials yet; a host that could not be asked which it can do answers 503. Nothing is changed by any of these: send a 409 again once the host has been updated, and the 503 shortly.
An egress_proxy sent to a running computer is in effect when the answer arrives, and the connections it had open are closed; sent to a stopped or suspended one it is stored and applied before it starts. One its host cannot put into effect is refused with 503 and nothing is changed — unless the computer is being moved to another host at that moment, when the previous setting cannot be put back: then the 503 says so, the new setting is stored, and it takes effect at the host’s next successful write of its egress rules, retried every few seconds; until then the computer’s connections may go directly, or through its previous proxy if it had one. A setting sent to a host that cannot proxy a computer yet answers 409 with reason: "unsupported", as does an https:// setting, or one naming credentials_secret_id, sent to a host that cannot take those yet; a null is refused only by a host that does not know the field at all, so an egress proxy can always be removed. A credentials_secret_id naming no secret in the computer’s scope, or one whose value is not user:password, is refused with 400 and nothing is changed; so, with 409, is one whose value cannot be read on this control plane (replace its value) or one named where delivering secrets is not switched on for the deployment, and, with 503, one named where secrets are not enabled at all. A setting naming it is in effect once the host has the value, usually within seconds (watch egress_proxy_pending), and every connection is closed until then. A null, or a setting naming no credentials_secret_id or a different one, that its host answers with a 5xx, or that is sent and never answered, may or may not have taken effect, and the host is also told to forget the credentials it held for the secret the previous setting named. (A 503 whose error says nothing was changed was answered before the request was sent: it changed nothing, and the host keeps those credentials.) If the setting in effect afterwards names a credentials_secret_id — the previous one, once the host has forgotten its credentials, or the new one, whose value is not delivered after such an answer — a running computer reports egress_proxy_pending and its connections are closed until the setting is sent again, and a stopped or suspended one starts that way; if it names none, it behaves as described above.
A resize of a RUNNING computer answers 409 with reason: "running": stop it and send the same request again. Waiting does not clear it, and neither does a start.
A RESIZE DISCARDS A SAVED SESSION. Suspended counts as stopped here, so a resize of a suspended computer is accepted — and the saved desktop cannot survive it, because the vCPU count and the memory size are part of the state and growing the disk changes a device the state describes. It is dropped, and the next start is a cold boot. Resume it and finish what is open before resizing, or accept the loss deliberately.
A memory snapshot taken before a resize cannot be restored afterwards either — see POST /snapshots/{id}/restore.
Resolution is not settable — it is fixed at create.
Requires the member role or higher.
Request
- Base URL: https://app.mandala.computer/api/v1
- URL: https://app.mandala.computer/api/v1/computers/{id}
- Auth: HTTP bearer
Path parameters
The computer id.
Headers
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.
Request body
Response
The updated computer.
Changes
No recorded changes to this operation across all 1 revision of this API.