---
title: "VMs: virtual machines on your servers · Frazer"
description: "Create virtual machines on your own servers with the price on every choice and a plan before anything runs: machine types, images, local NVMe or replicated disks, SSH sign-in and instance groups."
url: https://frazer.ai/vms
index: https://frazer.ai/llms.txt
tokens: 2674
---

> For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt.

# VMs: virtual machines on your servers · Frazer

**VMs**  frazer.ai

# 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.

[Create a VM](https://frazer.ai/start?product=vms) [Read the docs](https://frazer.ai/docs)

*The Create VM page of the Frazer console for the demo organization Acme: etl-worker-3, a g1-8 VM with 8 vCPU and 32 GiB on the pool vint-hill-default shared from acme-infra, where its compute is covered by the server fee, next to the Frazer fleet at $0.464 an hour. Every machine type shows its fleet price and the servers it fits on. The 200 GiB local-nvme boot disk has daily backups, and the plan adds the VM, its disk, a network card and a backup policy, moving the project from 44 to 52 of 96 guaranteed vCPU.*

Create VM: the price and the plan before anything runs product UI, demo organization

01 · How a VM works Fig. 1

## 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.

**Fig. 1** A VM from the plan to the server, with its disks, network, sign-in and backups

02 · Disks

## 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.

The three disk types compared

|  | local-nvme Default | replicated Three copies | scratch Temporary |
| --- | --- | --- | --- |
| 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 |

03 · Sign in and script

## SSH that ends with the role.  
No keys to hand out.

-   `frazer compute vms ssh web-1` gets a certificate that lasts 5–10 minutes and opens that VM only.
-   It is issued after an access check: `compute.vms.login` to sign in, `compute.vms.adminLogin` for sudo.
-   Remove the role and access ends within minutes. There are no keys on the VM to clean up.
-   Private VMs need no bastion: `--tunnel` goes 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=10
```

04 · Instance groups Fig. 2

## Groups 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.

*The instance group web-legacy in the Frazer console for the demo organization Acme, in a rolling update from web-legacy-v2 to web-legacy-v3: 2 of 3 VMs replaced with new healthy VMs, the third being created with a surge of one and none unavailable; the template is immutable, a health check recreates a VM after 3 failures, and autoscaling keeps 2 to 6 VMs at 60 % CPU.*

**Fig. 2** An instance group mid-update: a surge of one, none unavailable product UI, demo organization

05 · What you get

## 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.
    

06 · Controls

## 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 with `compute.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.

07 · Pricing

## 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 price](https://frazer.ai/pricing#lines)

Your servers **Included** · no per-VM compute charge

Fleet $0.030 per vCPU-hour + $0.007 per GiB-hour, per second · a g1-4 ≈ $0.232 / hour

While stopped Storage only: disks, snapshots and backups

Backups, images 100 GB per server included, then $0.012 per GiB-month

External IPv4 $3.00 per address a month, billed hourly · IPv6 is free

Questions

## VMs, 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`.

## More in Compute

-   [**Servers and pools** Bring, rent or buy servers](https://frazer.ai/servers)
-   [**Kubernetes** A cluster per project](https://frazer.ai/kubernetes)
-   [**Serverless** Deploy a repo, DB included](https://frazer.ai/serverless)
-   [**Devboxes** Real machines per engineer](https://frazer.ai/devboxes)

## Your servers, as VMs.  
Planned, priced and backed up.

[Create a VM](https://frazer.ai/start?product=vms) [Read the docs](https://frazer.ai/docs)
