VMs on the servers you own.
Every choice priced before you apply.
Pick a machine type, an image and a disk, and see what it costs and where it fits before anything runs. Each VM sits in your project’s network, signs people in with their Frazer account, and backs itself up when its disk lives on one server. On your own servers there is no per-VM charge.
A VM, not a cluster to run.
Kubernetes stays underneath.
Each VM is a virtual machine in your project’s namespace on a pool of your servers. You create and change it with a plan from the console, the CLI or MCP, and it sits in your project’s network.
The console, the CLI and MCP send one plan to the Frazer API, which checks quota and fit first and sends signed state to a server in your pool. There the VM runs on Frazer’s VM layer in your project’s namespace, with a local NVMe boot disk encrypted with LUKS2, a network card in a VPC subnet and a guest agent that serves metadata over vsock. People sign in over SSH with a 5–10 minute certificate through Frazer Link, and daily backups go to Frazer Storage, off the server. On your servers there is no per-VM charge.
Disk type decides mobility.
The create page says so.
A local NVMe disk is fast and pins its VM to one server. A replicated disk lets the VM move or restart anywhere in the site.
| local-nvmeDefault | replicatedThree copies | scratchTemporary | |
|---|---|---|---|
| Backing | A volume on the server’s NVMe, encrypted with LUKS2 | Replicated block storage, 3 copies | The server’s NVMe, erased on stop |
| Speed | Native NVMe | Network block: fewer IOPS, more latency | Native NVMe |
| If the server dies | Back from its last backup; writes since then are lost | Restarts on another server in the site, no data lost | Lost |
| Live migration | No: stop, maintain, start | Yes | No |
| Host maintenance | Restart with 7 days’ notice | Migrates; the guest does not notice | — |
| Snapshots | Restore on the same server | Restore anywhere in the site | None |
| Good for | Databases on VMs, build boxes, stateless VMs behind a group | Long-lived VMs and anything that must survive a host | Caches, temporary files |
SSH that ends with the role.
No keys to hand out.
frazer compute vms ssh web-1gets a certificate that lasts 5–10 minutes and opens that VM only.- It is issued after an access check:
compute.vms.loginto sign in,compute.vms.adminLoginfor sudo. - Remove the role and access ends within minutes. There are no keys on the VM to clean up.
- Private VMs need no bastion:
--tunnelgoes through Frazer Link. - Sudo can require a passkey step. Every login records who, which VM and on whose behalf.
$ frazer compute vms create web-1 --project acme-staging --pool vint-hill-default \
--machine-type g1-4 --image-family ubuntu-2404-lts \
--boot-disk 50,local-nvme --subnet default \
--external-ipv4 ephemeral --external-ipv6 ephemeral --dry-run
Plan + VM web-1 · g1-4 · 4 vCPU · 16 GiB
+ Disk web-1-boot · 50 GiB local-nvme · daily backups
+ NIC nic0 in default · external IPv4 and IPv6
Fits on 3 of 3 servers in Vint Hill
Compute $0 · covered by acme-infra
? Apply? yes ✓ web-1 running$ frazer compute vms ssh web-1 --tunnel
Access compute.vms.login on web-1
Cert 5–10 minutes · principal bound to web-1
Path Frazer Link · no bastion
$ frazer compute vms console web-1
Console serial, through Frazer Link · session audited$ frazer compute images create --upload ./disk.qcow2 --family app-base
$ frazer compute images create --from-disk web-1-boot --family app-base
Family app-base points to its newest image
deprecate the newest to roll back$ frazer compute backup-policies create daily --schedule "0 3 * * *" --keep 14 \
--vms label:environment=production
Backups whole VM: every disk and its settings, incremental
Restore always to a new VM$ frazer compute instance-templates create web-v3 --from-vm web-1
$ frazer compute instance-groups create web --template web-v3 --size 3 \
--autoscale cpu=60,min=2,max=10Groups that heal and roll.
From one immutable template.
An instance group keeps identical VMs healthy, scaled and updated together, and serves as a backend of a load balancer.
Images, disks, groups.
And the rest a VM needs.
Machine types with prices
Shared, general, compute and memory series, and custom shapes at the same unit price.
Images and families
Ubuntu, Debian, Rocky, Alma, Fedora and Flatcar; import from a URL or upload, export any disk.
Snapshots and backups
Whole-VM backups, incremental, on by default for local NVMe. Restore always makes a new VM.
Metadata over vsock
No network metadata endpoint for a forged request to reach; short-lived tokens, never static keys.
Serial and VNC console
In the browser through Frazer Link, with rescue mode and a serial log kept after a crash.
Your network, both families
Each NIC in a subnet of your VPC; external IPv4 and IPv6 are separate choices, both off by default.
Instance groups
One template; autohealing, autoscaling, rolling and canary updates; placement groups.
Live migration
With replicated disks, host maintenance moves the VM instead of restarting it.
Who may sign in.
And what happens at the cap.
Who may do what
- Admins and developers
- Create VMs and sign in with
compute.vms.login; sudo withcompute.vms.adminLogin. - Viewers and responders
- See VMs, disks and their state. They cannot sign in.
- Agents
- Plan any change under their ceiling. Console sessions, sudo and a reset of a production VM need a person.
- Org policy
- Allowed machine types, sites, external IPs, serial console and the number of VMs; explicit sign-in rights in production, on by default.
What is logged
- Every change, applied from a plan and kept in the VM’s revision history
- Every login: who, which VM, which principal, on whose behalf
- Console sessions: start, end and person; keystrokes are not recorded by default
- Maintenance notices, sent to the VM’s metadata, the console, webhooks and email
At the cap
- A spend cap stops VMs on the Frazer fleet and keeps their disks. It never touches VMs on your own servers.
- A plan checks the project’s quota and free room on a real server before anything runs.
- Memory is never overcommitted.
- Delete is soft, with a restore window, and offers a final backup first.
No per-VM fee on your servers.
Stopped VMs pay for storage only.
On your own servers a VM uses capacity you already pay for, so there is no per-VM charge. On the Frazer fleet you pay per second while a VM runs, at the same rate for custom shapes.
See every priceVMs, answered.
Do I need to know Kubernetes to use VMs?
No. A Frazer VM runs on Frazer’s VM layer on your pool’s servers, but you see a VM: machine type, disks, network and console. You create it with a plan from the console, the CLI or MCP, and there is no kubectl to the servers underneath.
What happens to a VM when its server fails?
It depends on its disks. A VM on local-nvme comes back from its last backup, so backups are on by default and the create page shows how much you could lose.
A VM whose disks are all replicated restarts on another server in the site with no data lost.
Do VMs restart for host maintenance?
VMs on local disks stop and restart, with 7 days’ notice for planned work, inside your maintenance window. VMs with only replicated disks and no passed-through device migrate live instead. GPU VMs always restart, with 60 minutes’ notice.
Can I bring my own image?
Yes. Import a qcow2, raw, VMDK, VHD or ISO from a URL, upload one from the browser or the CLI, or pull it from an OCI registry. You can also make an image from a disk or a snapshot, and export any disk at any time. Windows Server runs with your own license.
Where do my VMs run?
On a pool of your servers, one your project owns or one shared with it, at a site you choose, or on the Frazer fleet in us-virginia1. The spec is the same; only the flag changes, --pool or --location.