Setup scripts, environment and labels

A setup script customizes a newly created computer after boot. Treat it as a finite, repeatable bootstrap step: install explicit dependencies, write the application's configuration, and fail visibly when a prerequisite is absent. Do not place API or model-provider keys in an image or script that will be retained.

Readiness is separate from running

The run timer and running compute charges begin when the VM is observed running. Setup completion can come later. The SDK create waiter checks the required final state and readiness; a raw 202 acceptance does not establish either one. Inspect setup status and the bounded setup-log stream using the original computer ID.

The setup timeout defaults to 900 seconds and must be between 1 and 86,400 seconds. A local waiter has its own deadline and does not cancel a server-side script. If a create waiter fails or times out, retain the computer ID from its diagnostic and inspect the existing operation instead of creating another machine blindly.

Reproducibility and output

Use explicit versions and verify downloaded artifacts inside your own provisioning design. Avoid printing credentials: setup logs are retained output. Binary or oversized output follows stream retention rules; it is not an unbounded audit archive. Close each log stream when finished. For a large base environment, stop the computer and create a private image, then keep the remaining setup step short.

Exact environment and first-boot contract

| Field | Rules ||---|---| | class | vm (default; the only v1 class) | | size | ac-2, ac-4 (Tier 1+), ac-8, ac-16 (Tier 2+) | | mode | on_demand (default) or always_on (holds capacity) | | image | ce-desktop (latest), a pinned ce-desktop@2026.11.1, or a private img_… | | desktop | default true; false = headless (no X server, desktop endpoints return 409 desktop_disabled) | | timeout_seconds | Stored run policy; active only in on_demand. Default 3600; finite values 1..2,592,000 seconds (30 days); null = no timeout (Tier 1+). Counted from start/resume | | on_timeout | pause (default) or stop | | network | {mode: open|allowlist|none, allow: [domains or CIDRs]} | | env | At most 64 entries; compact UTF-8 JSON encoding at most 32768 bytes; omitted = {}; names match ^[A-Za-z_][A-Za-z0-9_]*$; values must not contain NUL | | setup.script | At most 65,536 UTF-8 bytes (64 KiB), measured after JSON decoding; one at-most-once automatic first-boot attempt as dev under the computer's network policy; setup.timeout_seconds defaults to 900. Interrupted attempts fail and are not automatically repeated, including after snapshot restore. A private-image clone runs only the setup supplied in its own create request. A larger decoded script returns 422 unprocessable before computer creation; the independent whole-JSON-body limit still returns 413 payload_too_large | | metadata | ≤ 16 keys |

setup.timeout_seconds is separately bounded to 1..86,400 seconds (default 900); invalid values return 422. Unknown/unauthorized private-image sources or unresolvable ssh_key_ids return 404 not_found.

Create-time env persists on the same computer across stop/start. Setup, exec/processes and PTY receive a sanitized base environment for the selected Unix user, overlaid with create env, then with per-call env for exec/PTY; later values win. Base variables are HOME/USER/LOGNAME/SHELL from that user's passwd entry, PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin and LANG=C.UTF-8; do not inherit the service process's environment. The bounds/name/NUL rules also apply to per-call env and the merged customer map. Shell startup files may subsequently change variables. No automatic inheritance into SSH sessions, existing desktop apps or systemd services is promised. env is guest-readable configuration, not a vault, and cannot be PATCHed. A new computer from a private image receives only its new create env/setup as CE-managed configuration; arbitrary files and services in the image are not scrubbed. Secret values are not echoed in public resource reads or platform request logs; a customer's script can expose them in its own stdout/stderr. Setup failure is distinct from agent readiness: a computer can be ready with failed setup.

Dory is in development; these pages describe the planned service and may change. Questions: support@computeengines.com.