Skip to main content

Core Concepts

Platform Model

The API is centered on projects and their child resources. Understanding these boundaries helps you build correct payloads and avoid mixing provisioning inputs with long-lived runtime resources.

Provisioning inputs

Images

Define the base OS or machine template used during VM creation.

Tariffs

Represent the plan or commercial profile that the VM will use.

Configurations

Expose available VM configuration profiles that can inform your selection logic.

SSH inputs

Access can be supplied as raw public keys or existing project-scoped SSH key identifiers.

Runtime resources

Projects

The top-level namespace for VMs, SSH keys, networks, and public IP resources.

VMs

The main compute resource. VM responses expose identifiers, resource sizing, and network attachments.

Networks

Project-level network resources to which VMs can be attached and reconfigured.

Backups

VM-scoped recovery points that are created, listed, restored, and deleted separately.

Asynchronous behavior

Several operations are command-oriented. For example, VM creation returns a command identifier, while the VM resource itself exposes operation and operation-status fields that reflect ongoing work. In practice, create first, then fetch the affected resource until it reaches the state your workflow requires.

Modeling recommendation

Persist project and VM identifiers in your client as first-class references. They are the main join keys for nearly every follow-up call in the current API surface.

GET/projects

List top-level project resources.

GET/images

Inspect available image identifiers.

GET/tariffs

Inspect tariff identifiers used during VM creation.

POST/projects/{projectId}/vms

Create the main compute resource.

GET/projects/{projectId}/vms/{vmId}

Read the VM state after an asynchronous operation.