Instances
Create, start, stop, edit and delete system containers and virtual machines from the dashboard or the API.
An instance is a system container or a virtual machine running in your tenant. This page covers the full life of an instance: creating it, starting and stopping it, changing its configuration and devices, and deleting it.
Create an instance
In the dashboard
- Go to Instances and click New instance.
- Image step: pick an image from the tenant catalog, or type an alias such as
ubuntu/24.04. Browse opens the public image catalog so you can search for one. See Images. - Size step: fill in the details.
- Name: 1 to 63 characters, lowercase letters, numbers and hyphens, starting with a letter or number. Names are unique within the tenant.
- Type: Container or Virtual Machine.
- vCPUs (1 to 64), Memory (MiB) (64 to 65536) and Disk (GiB).
- Description (optional).
- Advanced options lets you pick a Profile. The list shows profiles created in your tenant; when it says No profiles available. the instance uses the
defaultprofile.
- Review step: check the summary and click Create instance.
The dashboard opens the new instance's page. New instances are created in the Stopped state, so click Start to boot it.
Note
In this version two wizard fields are not applied. The Disk (GiB) value is dropped, and the instance gets the root disk from the default profile, which has no size limit. The Config (YAML/JSON) box under Advanced options is not sent to the server. Set extra configuration after creation in the Config tab, or create the instance through the API.
With the API
POST /api/v1/compute/instances creates an instance. Only name and imageAlias are required. type defaults to container and profiles defaults to ["default"].
curl -X POST https://lahijan.example.com/api/v1/compute/instances \ -H "Authorization: Bearer $LAHIJAN_TOKEN" \ -H "X-Tenant-Id: $TENANT_ID" \ -H "Content-Type: application/json" \ -d '{ "name": "web-1", "type": "container", "imageAlias": "debian/12", "description": "Public web server", "config": { "limits.cpu": "2", "limits.memory": "2048MiB" }, "devices": { "root": { "type": "disk", "path": "/", "pool": "default", "size": "20GiB" } }, "profiles": ["default"] }'Every API call needs a personal access token in the Authorization: Bearer header (see Access tokens) and your tenant ID in the X-Tenant-Id header. Without the tenant header, compute calls fail with 400.
The response is 201 with the instance object, including its id. A few things to know:
- A
rootdevice only takes effect when it names apool. Arootdevice withoutpoolis ignored and the profile's root disk is used instead. Ask your operator for the pool name ifdefaultdoes not work. limits.cpu,limits.memoryand the rootsizecount toward your quota. Over quota returns422with codequota_exceeded.- A name already in use returns
409. - If the creation fails on the server (for example, an unknown image), the name is freed and you can retry.
List and filter instances
The Instances page shows each instance's Name, Status, Image and Type. Type in the filter box to match on name, description or image, and use the status dropdown to show Running, Stopped, Frozen or Other instances.
Through the API, GET /api/v1/compute/instances returns a page of instances. Use limit and offset to page. The list reflects the last known state; GET /api/v1/compute/instances/{instanceId} fetches a single instance and refreshes its status from the live system first.
Instance states
| Status | Meaning |
|---|---|
Running |
The instance is up. |
Stopped |
The instance is shut down. New instances start here. |
Frozen |
All processes are paused. Memory is kept. |
Starting, Stopping, Restarting, Freezing, Unfreezing |
A transition is in progress. The dashboard groups these under Other and refreshes the page every 2 seconds until the transition ends. |
Lifecycle actions
The instance page header shows the actions that fit the current state: Start when stopped, Stop and Freeze when running, Unfreeze when frozen, and Restart and Delete at any time. The same actions are in the row menu on the Instances list.
The API equivalent is one call per action:
POST /api/v1/compute/instances/{instanceId}/startPOST /api/v1/compute/instances/{instanceId}/stop?force=true&timeout=60{action} is one of start, stop, restart, freeze or unfreeze. Two optional query parameters apply:
force(defaultfalse): skip the graceful shutdown, like pulling the power cord. The dashboard never sends it for lifecycle actions.timeout(default30): seconds to wait for the action.
The response is the updated instance. Every action is recorded in the audit log.
| Action | Permission |
|---|---|
start |
compute.instance.start |
stop, freeze, unfreeze |
compute.instance.stop |
restart |
compute.instance.restart |
Edit configuration and devices
Open the Config tab. It has three sections:
-
Effective configuration: every setting in force after profiles are applied. The Source column shows whether a key comes from the instance, a profile or the system. Use the filter box to search.
-
Instance configuration: the settings stored on this instance, which override profile values. Click Add setting, enter a key (for example
limits.cpu) and a value, then Save. Reset discards unsaved edits. System-managed keys (volatile.*,image.*) are hidden and kept as they are. -
Instance devices: devices attached directly to the instance. To add one, enter a Name, choose a Type and write the Properties one
key=valueper line, then click Add device. For example, a disk device that mounts a storage volume:inipool=defaultsource=my-volumepath=/mnt/dataRemove a device with the trash icon. Devices inherited from profiles are not listed here; they appear in the Network and Storage tabs.
If the server refuses a change (for example, a blocked device type), you see Update rejected with the reason. Some settings apply immediately; others take effect on the next restart.
With the API, PATCH /api/v1/compute/instances/{instanceId} accepts description, config, devices and profiles. A field you leave out keeps its current value. A field you send replaces the whole map or list, so send every device you want to keep:
curl -X PATCH https://lahijan.example.com/api/v1/compute/instances/$INSTANCE_ID \ -H "Authorization: Bearer $LAHIJAN_TOKEN" \ -H "X-Tenant-Id: $TENANT_ID" \ -H "Content-Type: application/json" \ -d '{ "config": { "limits.cpu": "4", "limits.memory": "4096MiB" } }'To see what is in force, including profile values and live usage, call GET /api/v1/compute/instances/{instanceId}/runtime.
Delete an instance
Click Delete on the instance page. The dialog asks you to confirm and offers Force delete (skip graceful shutdown). A running instance is stopped first, then removed.
Caution
Deleting an instance removes it from the system. It cannot be undone. Deleting from the row menu or the bulk action bar on the Instances list does not ask for confirmation.
With the API:
DELETE /api/v1/compute/instances/{instanceId}?force=falseThe response is 204. Deleting requires compute.instance.delete, which the default Member role does not have.
Bulk actions
Select instances with the checkboxes on the Instances list (the header checkbox selects all). A bar appears showing how many are selected, with Start, Stop, Restart and Delete. Each button sends one request per selected instance. Only the buttons your role allows are shown.
Move an instance to another node
On a deployment with several compute nodes, POST /api/v1/compute/instances/{instanceId}/migrate moves an instance to another node. The body names the destination in targetMember; set live to true for a live move. Single-node deployments return 409. See Compute cluster for how nodes are managed.