Skip to main content
This feature is in public preview.
An instance is a GPU machine that runs a VM image. You create an instance, attach it to a pool, choose an image, and optionally provide a cloud-init script. The instance waits for compute time (from orders) before starting.

Instance lifecycle

An instance in awaiting_allocation starts running when the pool’s allocation schedule covers the current time. For example, if you buy compute starting at now, the instance starts within about a minute. If the order starts in the future, the instance waits until then. The image download and boot process takes up to 10 minutes before SSH is available.

Create an instance

All flags are optional in interactive mode — omit them to use pickers for pool and image.

Images

List available images to find one to use with your instance.
Pass the image ID when creating an instance.
To build and upload your own custom image, see Custom Images.

Cloud-init

Pass a startup script or cloud-config YAML via --cloud-init to configure the VM on first boot. Shell script — inject your SSH public key:
Cloud-config YAML — set up users and keys declaratively:
startup.yaml

Check instance status

Filter by time range.
--created-after and --created-before accept a datetime, Unix timestamp, or a duration like 24h or 7d (meaning 24 hours or 7 days ago, respectively). You can also use --since and --until as aliases. Get details on a specific instance.

SSH into an instance

The instance must be in running status and the image must be fully booted. This can take up to 10 minutes after the instance starts.

View logs

Show more lines.
Filter by time range.
--after and --before accept flexible time expressions: "now", "in -1h", a date like mar 1, ISO 8601, or a Unix timestamp.

Terminate an instance

Stop the VM immediately. The instance moves to terminated status.

Replace an instance

Replace an instance with a new one on the same pool. The original instance is terminated and a new instance is created with the specified image.
Provide a cloud-init script for the replacement:
Give the replacement instance a specific name:
Cloud-init is not carried over from the original instance. If you omit --cloud-init, the replacement boots with no startup script and you won’t be able to SSH into it.

Delete an instance

Permanently remove an instance.

Replace an instance

Replace an instance with a new one on the same pool and SKU. The original instance is terminated and a fresh instance is created with a new image (and optionally a new startup script and name).
The replacement inherits the original’s pool, SKU, subnet, public IPv4 setting, firewall, tags, and priority. Replace with a new startup script
If you omit --cloud-init, the replacement starts with no startup script — you will not be able to SSH into it. Pass a cloud-init file to configure SSH access.
Replace with a specific name
There is no persistent storage attached to an instance. Replacing an instance will result in loss of all data stored on the original.

Instance priority

When a pool’s quota drops below the number of running instances, the system terminates instances to match. Instance priority controls which ones survive. Higher-priority instances are kept longer; lower-priority ones are terminated first. Priority has four arms, ordered yield < normal < preferred < critical. Every instance defaults to normal. The expected_shutdown_at field on instance responses is deprecated and always null. Set priority on an existing instance.
Set priority at create time.
The same surface is available over the API. Pass priority_level in the body of POST /preview/v2/instances to set it at create time.
Omit priority_level to default to normal. Update one instance with PATCH /preview/v2/instances/{id}.
Omit priority_level to leave it unchanged. Pass "normal" to reset to the default. Update many instances atomically by PATCHing the collection.
If any entry is rejected (unknown id, cross-account id, missing permissions), the entire request rolls back with a 422 and no instance is touched. Up to 10,000 entries per call. An empty data returns 200 with no writes. When the same id appears more than once, the last occurrence wins. The response includes the updated instance for each entry, so you can confirm the result in one round-trip. When two instances have the same priority, the newer one is terminated first.

critical and procurement automations

critical cannot be set on an instance whose pool has an active procurement automation — procurement-backed pools resize automatically, so critical can’t be honored there. The constraint applies in both directions:
  • Setting priority_level: critical on such an instance returns 422.
  • Creating a procurement on a pool that already has critical instances returns 422 — downgrade the affected instances (for example, to preferred) first.
Use preferred instead when the pool is procurement-backed, or disable the procurement before setting critical. Setting priority requires the Node: Write permission. Read-only tokens see priority_level on GET responses but receive 403 on writes.

Limitations

  • No persistent storage. If the underlying machine dies, you get a replacement but not the same disk.
  • No public IPs. To serve inference, set up a proxy in another cloud and connect it via VPN.
  • No InfiniBand.
  • Instances don’t share a VPC or VLAN. Configure a VPN if you need connectivity between instances.
  • Boot time can be up to 10 minutes for image download and startup.
  • No GPU monitoring. GPUs may occasionally fall off the bus — terminate and recreate the instance, or contact us.

API reference

See the Instances API for programmatic access.