Dory is in development. The invite-only beta has not opened yet; prices and limits are planned and may change.
Doryby ComputeEngines
Request beta access

Computers, classes and sizes

A computer is a persistent Linux virtual machine with a stable resource ID, a disk and metadata. The control API creates it and manages its lifecycle; the data API reaches the in-guest agent running inside it. Creating a computer is an asynchronous operation. Keep both the returned computer ID and operation ID, including when a local waiter times out.

Create and observe

Choose a published image, a size, a name and an optional setup script. The SDK create waiter requires the expected running state and readiness; raw API callers must poll the returned operation and computer explicitly. A 202 response means acceptance, not a running machine. Metadata is descriptive and does not replace durable ownership or billing attribution.

The disk capacity is chosen at creation. Resize changes CPU and RAM only, while stopped; disk_gb continues to report the original disk capacity. Restoring a snapshot requires a matching configuration. Do not infer the disk size from a later size name.

Running, paused and stopped

Running preserves both disk and active memory. Pause retains memory for resume; stop discards memory. Deleting is separate from stopped and from the later purge. The state table describes transitions and the billing page explains which intervals accrue charges.

A computer's network policy, previews, hooks, sessions and access tokens are separately scoped resources. Delete or revoke what the workflow no longer needs. A legal hold can refuse destructive changes while leaving non-destructive stop or pause available. Read the returned problem rather than repeatedly submitting the same prohibited action.

Classes, sizes and diagnostic metrics

The only class in v1 is vm. Creation capacities are ac-2: 2 vCPU, 4 GB RAM, 40 GB disk; ac-4: 4 / 8 / 80; ac-8: 8 / 16 / 160; ac-16: 16 / 32 / 320. Tier 1 permits ac-2 and ac-4; Tier 2 the larger sizes. CPU and RAM change on resize; the initial disk does not. An unsupported capability such as forking a running computer returns 409 not_supported.

Diagnostic metrics contain completed UTC one-minute buckets for the last 24 hours, oldest first. CPU is normalized to the assigned vCPU capacity. Memory and disk are means of observations; network values are per-minute byte deltas. Missing samples are null, never a made-up zero. Metrics are not billing inputs.

Timer and mode changes

  • PATCH of name or metadata only works in every state except deleting and deleted (410).
  • PATCH containing mode, timeout_seconds or on_timeout works only in the running, paused and stopped states while no other change is in progress; otherwise 409 invalid_state. The whole PATCH is atomic.
  • extend works only for a running on-demand computer with an unexpired timeout_at. seconds adds to the existing deadline; timeout_at must be later than the time of the request, otherwise 422 unprocessable. Extending changes this run's deadline only, not the stored timeout_seconds.
  • Changing timeout_seconds changes the stored duration. On a running on-demand computer a finite value sets the deadline to now plus that duration, and null clears it. While paused or stopped, timeout_at stays null until the next start or resume. Changing only on_timeout does not move the deadline.
  • Finite timeout_seconds and extend.seconds are 1 to 2,592,000 seconds, and any newly set deadline must be at most 30 days ahead; excess values are rejected with 422 unprocessable. This does not limit the runtime when the timer is null.
  • An always-on computer stores timeout_seconds and on_timeout but keeps timeout_at at null; they take effect if you later switch it to on-demand. Entering always-on needs capacity, tier, restriction and key-cost checks to pass; a rejected switch changes nothing. No automatic start or resume ever follows a mode change. The monthly cap counter never resets on a mode change.
  • A newly installed deadline less than five minutes away emits computer.timeout_expiring immediately; otherwise it is emitted five minutes before the deadline, once per deadline version.

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