Cubes
Create, size, connect to, and manage Cubes — and understand how running and power-off billing works.
A Cube is a lightweight virtual machine running on dedicated cloud infrastructure. You get full root access and a real Linux environment — run Docker, databases, web apps, build agents, anything you would on a VPS.
Creating a Cube
Create a Cube from your space dashboard. You choose:
- vCPUs, RAM, and disk — the resources allocated to the Cube. RAM and disk are dedicated (not oversold).
- Image — the operating system to boot. Ubuntu 24.04 or Debian 13, each available plain or with Docker Engine preinstalled.
- SSH key — your public key, written to the Cube at boot.
Cube provisions and boots in seconds. Available sizes and the per-hour cost are shown in the create form so you always know what you'll pay.
Connecting
Every Cube has an SSH endpoint shown on its page. Connect with the key you added at creation:
ssh -p <port> ubuntu@<cube-host>The login user is ubuntu on Ubuntu images and debian on Debian images. It has passwordless sudo, so sudo su gives you a root shell. Root SSH login is disabled. Cubes created before August 2026 log in as root and keep working exactly as they did.
To expose other services, add TCP port mappings from the Cube's networking tab — each maps a public host port to a port inside the Cube, with an optional IP allow-list. For HTTP/HTTPS apps, a custom domain is usually the better fit.
Resizing
You can change a Cube's vCPU and RAM, and grow its disk, after creation. Resizing applies the new resources to the running Cube; metered billing simply continues at the new size.
Power off & start
Cubes have two main states beyond running:
- Stopped — the Cube is powered off but its disk is preserved. You can power a Cube off manually, and a space whose balance reaches zero has its Cubes automatically powered off (no data loss).
- Running — start a stopped Cube any time (top up first if the balance is zero) and it starts back up from its saved disk.
Restart
Restarting a Cube is a cold restart: the hypervisor process is stopped and relaunched, so the Cube boots against the host's current kernel. Your disk is preserved — only the kernel changes.
This is the only way a Cube picks up a refreshed guest kernel after a platform update. A reboot issued inside the Cube cannot do it: the kernel is supplied by the host, not from your disk, so an in-Cube reboot brings the same kernel back with no error to tell you so.
krova cubes restart my-apiCube must be running (a stopped Cube already picks up the latest kernel when you start it). Restarting briefly interrupts service, and a second restart while one is still in flight is rejected rather than queued twice.
How billing works
Billing is prepaid, charged against your space's credit. Rates are quoted per hour, but usage is metered and billed by the minute — no rounding up to the hour:
- A running Cube is billed for its compute (vCPU + RAM) and its disk.
- A stopped Cube is billed only for its disk storage — much cheaper than running, so powering off is the right way to pause a workload you want to keep.
- Unexpected shutdowns (a crash, an in-guest
shutdown, a host reboot) are never charged compute for the partial hour — you only pay for time the Cube actually ran.
Snapshots & backups
Cubes can be snapshotted and backed up to off-host object storage, and restored, cloned, or redeployed from those copies. Automatic snapshot cadence and retention depend on your tier; you can also take manual snapshots and pin the ones you want to keep.
Next steps
- Custom domains — serve a Cube on your own domain over HTTPS.
- API keys and the REST API — create and manage Cubes programmatically.