Skip to main content

Platform model

Everything in ZennoHosting is organised around projects and the resources they own. Model it that way in your client from the start and platform behaviour becomes predictable: reference data stays separate from live resources, and follow-up operations stay within one project.

Reference data for creation

Images

Define the operating system a VM is created from.

Tariffs

Define commercial terms for the VM and, separately, for a public IP.

Configurations

List the available combinations of cores, memory and disk, and whether capacity exists for them right now.

Access and plugins

Access comes from public keys in the request or references to project keys; plugins are attached at creation.

Live resources

Projects

Own VMs, SSH keys, networks, public IPs and backups. A project response carries resourceCounts for VMs, networks and addresses.

Virtual machines

The primary compute resource. Responses carry identifiers, sizing, network attachments and a status field with the current state.

Networks

Project-level private networks that VMs attach to and can be reconfigured in.

Addresses and backups

Public IPs belong to the project; backups belong to one specific VM.

Project boundaries

  • Project first, then SSH keys, networks, public IPs and VMs.

  • Keep projectId as the primary identifier in your data model.

  • Reuse project resources instead of recreating them for every VM.
  • Do not model a public IP as part of a private network's lifecycle: they are related but independent.

What to settle before creating a VM

A create request is assembled from live data. Decide the image, the VM tariff and whether a public IP is needed up front. If it is, remember that the price of a public IP is a separate decision, not a property of the VM tariff.

Check the bounds too: account quotas from GET /limits and capacity for the configuration you chose. These are two different reasons to be refused, and both are visible in advance.

What to keep in the client

Treat projectId, vmId, networkId and publicIpId as stable references — nearly every follow-up request depends on them. A project's vmCount field is deprecated: use resourceCounts.vms.

GET/projects

List projects together with their resource counts.

GET/limits

Read account quotas and current usage.

GET/configurations

Inspect VM configurations and their availability.

GET/images

Inspect the available images.

POST/projects/{projectId}/vms

Create a virtual machine.

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

Read a VM's state after an async operation.