Create and Access a VM | DC VM Documentation

Create the project

Projects are the parent scope for the VM and almost every related resource you will touch afterward.

curl --request POST \
  --url 'https://api.zennohosting.com/projects' \
  --header 'Authorization: Bearer <token>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{
"name": "automation-project"
}'

Resolve provisioning inputs

Before the VM request, resolve a live imageId and tariffId. If you want a new public IP at creation time, resolve the separate public IP tariff input as well.

Prepare access and optional plugins

Use sshPublicKeys when your client already has raw OpenSSH public keys.
Use sshKeyIds when you want to reuse project-level SSH keys.
Decide whether the VM should request a public IP at creation time via publicIpMode.
Decide whether to attach optional plugins, such as backup-related automation plugins, during provisioning.

Create the VM

The example below uses existing project SSH keys, requests a new public IP, sets the separate public IP tariff, and declares an optional plugin. Adapt the payload to your own provisioning inputs.

curl --request POST \
  --url 'https://api.zennohosting.com/projects/{projectId}/vms' \
  --header 'Authorization: Bearer <token>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{
"tariffId": "00000000-0000-0000-0000-000000000000",
"imageId": "00000000-0000-0000-0000-000000000000",
"vmName": "worker-01",
"plugins": [
  "00000000-0000-0000-0000-000000000000"
],
"sshKeyIds": [
  "00000000-0000-0000-0000-000000000000"
],
"publicIpMode": "New",
"publicIpTariffId": "00000000-0000-0000-0000-000000000000",
"privateNetworkIds": [
  "00000000-0000-0000-0000-000000000000"
]
}'

1
Resolve image and tariff identifiers
Query the image and tariff catalogs before building the VM payload so the request uses live identifiers instead of copied examples.
2
Create the project and keep its identifier
You will reuse the same projectId for VM, SSH key, network, and backup calls.
3
Create or select SSH access inputs
Either create project SSH keys ahead of time or embed raw public keys directly in the VM creation request.
4
Choose public IP and plugin behavior
Decide whether the VM should create, reuse, or skip a public IP, and whether provisioning-time plugins should be enabled as part of the same request.
5
Submit the VM creation request
Expect a command-oriented response. The VM itself should be fetched afterward to inspect operation state, boot state, and network attachments.
6
Store the returned password immediately
If the create response includes a password, store it immediately. Treat it as a one-time disclosure rather than something you can fetch again later.
7
Fetch the VM details until state is ready
Read the VM resource to confirm identifiers, sizing, interfaces, operationStatus, and bootStatus before continuing with access or follow-up automation.

Expected result

A successful flow leaves you with a created VM resource, its identifier, a confirmed usable state, and a clear record of how access, public IP behavior, and provisioning-time options were declared.

Password handling

The create response may include a password field that is shown only once. If your workflow needs it, persist it before the response leaves the client boundary.

POST/projects

Create the parent project.

POST/projects/{projectId}/ssh-keys

Create project-level SSH keys for reuse.

GET/images

Resolve the image identifier for the VM request.

GET/tariffs

Resolve the VM tariff identifier for the VM request.

POST/projects/{projectId}/vms

Create the virtual machine.

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

Fetch the resulting VM resource and verify state.