VMs

VMs are virtual machines you create from a plan, on a pool of your own servers or on the Frazer fleet. You pick a machine type, an image and disks, and the plan shows the price and the servers the VM fits on before anything runs. Each VM sits in your project’s network and signs people in with their Frazer account, so there are no SSH keys to hand out. On your own servers a VM has no per-VM charge.

Product overview: VMs.

How it works

A Frazer VM is a hardware virtual machine. It runs on Frazer’s VM layer in your project’s own namespace, either on the servers of a pool your project owns or one shared with it, or on the Frazer fleet. You see a VM, never Kubernetes: you create and change it through the Frazer API from the console, the CLI or MCP, and nobody runs kubectl against the servers underneath. On shared servers every workload is its own VM, and the servers never run your containers directly.

Every create and change is a plan you apply. The plan checks your project’s quota and the free capacity on real servers (“fits on 2 of 3 servers”), shows the cost, and then applies as an operation. Each applied change becomes a revision of the VM.

• Machine type: the VM’s size, from a series or a custom shape. g1-4 is 4 vCPU and 16 GiB.
• Placement: where the VM runs. --pool names a server pool of your project or one shared with it; --location names a Frazer fleet region. The rest of the spec is the same.
• Image family: a name such as ubuntu-2404-lts that points to the newest usable image of an operating system.
• Disk: local-nvme (fast, stays on one server), replicated (survives a server and moves with the VM) or scratch (erased on stop). The disk type decides whether a VM can move.
• Snapshot and backup: a snapshot copies one disk next to it; a backup copies the whole VM, every disk and its settings, to Frazer Storage.
• Instance template and instance group: an immutable VM spec, and a group of identical VMs made from it that heals, scales and updates together.
• SSH sign-in: a certificate that lasts minutes and opens one VM, issued after an access check.
• Guest agent: Frazer’s agent inside the VM. It serves the VM’s metadata, runs startup scripts and trusts the SSH sign-in certificate authority. Images also boot with cloud-init alone.

Machine types

Series	For	vCPU : memory	CPU
s1 shared	Development, small services, CI runners	1 : 2–4 GiB	Shared up to 2:1, stated on the price
g1 general	Most workloads; the default	1 : 4 GiB	1:1
c1 compute	CPU-bound work	1 : 2 GiB	Dedicated (pinned) cores
m1 memory	Caches, in-memory analytics	1 : 8 GiB	1:1, with a hugepages option
x1 exclusive	Latency-critical work, per-core licenses	As c1 or g1	Dedicated cores and the NUMA topology passed through, on servers that report it
gpu-<model>-<n>	GPU work	Fixed per GPU	Dedicated; whole GPUs by direct PCI passthrough
custom-<vcpu>-<mib>	Right-sizing	1 : 1–8 GiB in 256 MiB steps	As the series, at the same unit price

Sizes are 1, 2, 4, 8, 16, 32, 48, 64 and 96 vCPU. On your own servers, the largest size is the biggest server in the site minus the reserve each server keeps for itself (8 cores and 32 GiB). Memory is never overcommitted, and the VM’s own overhead counts against the server.

Network

Each VM has one to eight network interfaces, each in a subnet of a VPC network in your project. An interface has an internal address, ephemeral or reserved (an IPv4 address and an IPv6 address on a dual-stack subnet), and two separate external choices, external_ipv4 and external_ipv6. Each is none, ephemeral or static, and both default to none. Tags on the interface select firewall rules, and ip_forwarding turns a VM into an appliance.

• The internal address survives a restart and a live migration.
• Port security is on: a VM cannot spoof another address.
• By default nothing reaches the VM from the internet. Traffic from Frazer Link and from the network’s own subnets is allowed. Outbound traffic leaves through the network’s NAT, or through the VM’s own external address.
• Outbound port 25 is blocked on both address families.
• Each VM gets a private name, {vm}.{subnet}.{network}.{project}.internal.

Firewall rules, NAT and load balancers are covered in VPC and firewall.

Host maintenance

Each VM has two settings: what happens on host maintenance (MIGRATE or TERMINATE) and whether it restarts automatically. A VM whose disks are all replicated and that has no passed-through device defaults to MIGRATE: it moves to another server and the guest does not notice. Every other VM defaults to TERMINATE: it stops and starts again inside your project’s maintenance window.

Frazer gives notice through the VM’s metadata (maintenance-event), a console banner, webhooks and email: 7 days ahead of planned work on a TERMINATE VM, 60 seconds before a live-migration blackout, and 60 minutes ahead for GPU VMs, which can never migrate. To take a planned restart early, call the VM’s performMaintenance method. When a server in a shared pool needs work, every project with VMs on it sees the event in its own maintenance calendar.

Create a VM

You need a project, and either a server pool in it or shared with it, or access to a Frazer fleet region. See Servers and pools for pools.

1. Plan the VM. Nothing is created yet.

   CLI

   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

   Output

   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   no charge · covered by acme-infra

   To place the same VM on the Frazer fleet, replace --pool vint-hill-default with --location us-virginia1.

   Console

   Open Compute › VM instances › Create VM. One page holds every choice:

   • Name and where the VM runs: your project’s pools, then pools shared with the project, then the Frazer fleet, cheapest first, each with the capacity it has free.
   • Machine type, with its price and the servers it fits on.
   • Image family, boot disk type and size, data disks.
   • Network and subnet, external addresses, sign-in (SSH sign-in is on), startup script, and backups (on for local-nvme).
   • Advanced: placement group, maintenance policy, labels and service account.

   The right rail shows the cost, the quota impact and the plan diff. Copy as CLI / API / YAML gives you the same VM as code.

2. Apply the plan.

   CLI

   Run the same command without --dry-run. The CLI waits for the operation to finish; add --async to return at once.

   Console

   Choose Apply.

   In a production project, someone other than you approves the plan before it applies. Agents and service accounts never approve.

3. Sign in.

   frazer compute vms ssh web-1 --tunnel

   The CLI gets a certificate for web-1 and connects through Frazer Link, so a VM without an external address needs no bastion host.

A local-nvme boot disk stays on one server

Fast. Stays on one server. If that server fails, this VM comes back from its last backup (daily by default). Backups are on by default for VMs with local-nvme disks. Use replicated disks for a VM that must survive the loss of a server.

Every VM is also a declarative resource: frazer export writes it as YAML in the same schema as the Terraform and OpenTofu provider, and frazer apply -f applies such a file with a plan first.

Connect to a VM

SSH sign-in

frazer compute vms ssh web-1 asks Frazer for an SSH user certificate that lasts 5 to 10 minutes. It is issued from your organization’s SSH certificate authority, the same one devboxes use, only after an access check on that VM, and it carries a principal bound to that VM, so it opens no other. The VM trusts the authority through cloud-init.

• compute.vms.login lets you sign in; compute.vms.adminLogin adds sudo. Grant them on a project, a group or one VM.
• Without --tunnel, the CLI connects to the VM’s external address. With --tunnel, it forwards TCP through Frazer Link.
• Remove the role and access ends: certificates expire within minutes, and there are no keys on the VM to clean up.
• Your organization can require a passkey or TOTP step for sudo sessions.

Images without the guest agent can use SSH public keys from project or VM metadata instead. When your organization requires SSH sign-in, those keys are ignored. Nobody ever reads a stored VM password: on Windows, Reset password generates one, shows it once to the person who asked, and stores nothing.

Use the console and rescue mode

frazer compute vms console web-1
frazer compute vms console web-1 --vnc

The serial console and VNC also open in the browser on the VM’s Console tab, through Frazer Link. They need compute.vms.console, and your organization can turn the serial console off. For a VM that does not boot:

• The Logs tab keeps the serial log, so you can read it after a crash.
• The VM page shows a VNC screenshot.
• Rescue mode restarts the VM into a Frazer rescue image with its disks attached.

Metadata and startup scripts

On first boot, cloud-init (Linux) or Sysprep (Windows) applies the user data from the VM’s spec. Inside the VM, the guest agent serves the metadata document at 169.254.169.254: project and VM metadata, labels, the sign-in policy, maintenance events and a token endpoint. It reaches Frazer over vsock, not the network, so a forged request from an application cannot read another VM’s metadata.

• Set startup-script or startup-script-url in metadata to run a script at boot; the agent also runs shutdown scripts.
• Attach a service account and the token endpoint returns a short-lived Frazer token, so the VM never holds a static key.

Work with images

Frazer’s public images are built from the upstream cloud images with cloud-init defaults and the guest agent, signed, and cached on every site, so a first boot never downloads over the WAN. Families: Ubuntu 24.04 and 26.04 LTS, Debian 13, Rocky and Alma 10, Fedora and Flatcar. Windows Server runs with your own license.

Make your own image from a disk or a snapshot, or bring one:

frazer compute images create --upload ./disk.qcow2 --family app-base
frazer compute images create --from-disk web-1-boot --family app-base

• Imports accept qcow2, raw, VMDK, VHD, VHDX and ISO: from a URL with --from-url, as an upload from the CLI or from Compute › VM instances › Images in the browser, or from an OCI registry. Imports have a size limit per organization.
• To capture a VM, choose Create image on the stopped VM, or on a running VM while the guest agent freezes the file system.
• Images belong to a project and can be shared with other projects of your organization.
• You can export any image or disk at any time.

A family points to its newest image that is not deprecated. To roll a family back, deprecate its newest image.

State	New VMs
READY	Allowed
DEPRECATED	Allowed, with a warning
OBSOLETE	Refused
DELETED	Refused; the image is gone

Manage disks, snapshots and backups

Property	local-nvme	replicated	scratch
Backing	A volume on the server’s NVMe, encrypted with LUKS2	Block storage replicated across servers in the site	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
Snapshots	Restore on the same server	Restore anywhere in the site	None
Resize	Grow online; shrink by copying to a new disk	Grow online; shrink by copying to a new disk	Fixed
Good for	Databases on VMs, build boxes, stateless VMs in a group	Long-lived VMs, Windows, anything that must survive a host	Caches, temporary files

• Attach and detach data disks on the VM’s Disks tab, or with frazer storage disks attach and detach, also while the VM runs.
• A small local-nvme disk can be moved to another server while it runs, and a local-nvme disk can change to replicated online.
• On your own servers, replicated disks need a site with at least three servers in the pool and 25 GbE networking.
• Every disk is encrypted with LUKS2 and erased cryptographically on delete. On a shared pool, each local-nvme VM disk has its own key, kept in your project’s secrets namespace, so the project that hosts the pool cannot read it.

Property	Snapshot	Backup
Scope	One disk	The whole VM: every disk and its settings
Where	Next to the disk; lost with a local-nvme server	Frazer Storage, incremental, with an optional off-site copy
Consistency	Crash, or app-consistent with a guest-agent freeze	The same
Restore	A new disk, or over the disk of a stopped VM	Always a new VM, or over the disks of a stopped VM after you type to confirm

Back up VMs by label on a schedule:

frazer compute backup-policies create daily --schedule "0 3 * * *" --keep 14 \
    --vms label:environment=production

Snapshots and backups are named objects you delete yourself. No deploy, migration or maintenance ever deletes one.

Run groups of VMs

An instance group keeps identical VMs healthy, scaled and updated together. It is made from an instance template, an immutable, versioned spec with the machine type, the image family or a pinned image, disks, metadata, network interfaces and sign-in settings.

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

• Placement: a pool or a region, spread across servers. A group is stateless, or stateful when it must keep each VM’s disks and name.
• Autohealing: an HTTP, TCP or gRPC health check runs next to each VM; after a set number of failures the group recreates the VM, after an initial delay you choose.
• Autoscaling: on CPU, on a custom PromQL metric from your project’s metrics, or on a schedule, with a minimum, a maximum, a cool-down and scale-in protection.
• Updates: point the group at a new template with Edit group under Compute › VM instances › Instance groups. A rolling update replaces VMs within maxSurge and maxUnavailable; a canary runs a second template on a share of the group. Pause stops an update, and rolling back is a plan like any change.
• Load balancing: a group is a backend of a load balancer in your VPC. See Load balancers.

Placement groups apply to single VMs too: spread puts VMs on different servers, compact keeps them in the same rack.

Stop, resize and delete

frazer compute vms stop web-1
frazer compute vms start web-1

A stopped VM keeps its disks and pays only for storage. To change the machine type, stop the VM, run frazer compute vms resize, and start it again; this always works. A VM whose disks are all replicated can change vCPU and memory without a restart.

To move a VM to another site, back it up and restore the backup at the other site.

frazer compute vms delete web-1 offers a final backup first. Deletion is soft: within the restore window, frazer compute vms undelete web-1 brings the VM back. Disks are soft-deleted the same way.

Access and audit

Who	What they can do
Admins and developers	Create and change VMs, sign in (compute.vms.login) and use sudo (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 sign-in and a reset of a production VM need a person to approve
Your organization’s policies	Allowed machine types, sites and regions, external addresses, the serial console, and the number of VMs

• Your organization can require explicit sign-in bindings in production projects; this policy is on by default.
• Every VM method is also an MCP tool. Read tools answer at once; a write returns a plan that waits for approval.
• In a production project, a second person approves each plan. Nobody approves their own plan.
• Placing a VM on a pool shared with your project needs no extra permission by default.

What is logged:

• Every change, applied from a plan and kept in the VM’s revision history.
• Every sign-in: who, which VM, which principal, and on whose behalf for agents.
• Console sessions: start, end and person. Keystrokes are not recorded by default.
• Maintenance notices, in the VM’s metadata, the console, webhooks and email.
• On a shared pool, the project that hosts the pool sees each placement on its servers (resource name and size) and nothing inside your VMs.

Limits and quotas

Limit	Value
Network interfaces per VM	1 to 8
Machine sizes	1, 2, 4, 8, 16, 32, 48, 64 and 96 vCPU; on your servers, up to the biggest server minus 8 cores and 32 GiB
Custom shapes	1 to 8 GiB per vCPU, in 256 MiB steps
Memory overcommit	None
CPU sharing	s1 up to 2:1; every other series 1:1 or dedicated
SSH sign-in certificate	5 to 10 minutes
External addresses	None by default
Outbound port 25	Blocked by default
Image imports	A size limit per organization
Labels	Up to 64 per resource; keys and values up to 63 characters
Maintenance notice	7 days before a planned restart; 60 seconds before a migration blackout; 60 minutes for GPU VMs

Every plan checks your project’s quotas and, on a shared pool, your share of it: the capacity guaranteed to your project and the limit it may burst to. Quotas and quota increases are covered in Servers and pools.

Pricing

On your own servers the server fee covers a VM’s compute; on the Frazer fleet you pay per second while it runs. A stopped VM pays only for storage: disks, snapshots, backups and images per GiB-month, and a reserved external IPv4 address per IP-hour at cost (IPv6 is free).

VMs	On your servers	On the Frazer fleet
Price	Included	Same rates · a 4 vCPU / 16 GiB box ≈ $0.232 / hour

Every line, with the estimator: pricing.

Troubleshooting

Symptom	Cause	Fix
The plan fails with QUOTA_EXCEEDED	The VM would take the project past a quota	Pick a smaller machine type, delete what you no longer use, or follow the error’s link to request more
The plan fails with POOL_NO_FIT	No single server in the pool has room for this shape	Pick a smaller machine type or another pool, or add a server
The plan fails with POOL_CAPACITY_EXHAUSTED	Your project is at its limit on the shared pool, or the pool is full	Use the plan’s request more guaranteed option, or place the VM on the Frazer fleet
The plan fails with POOL_NOT_SHARED or POOL_SHARE_DRAINING	The pool is not shared with your project, or the share is ending	Choose another pool; ask the pool’s admins about the share
New VMs are refused for an image	The image is OBSOLETE	Use the family, or a newer image
frazer compute vms ssh is denied	You lack compute.vms.login, or the project requires explicit sign-in bindings	Ask an admin for the role on the project or the VM
SSH times out	The VM has no external address, or no rule allows your traffic	Add --tunnel to go through Frazer Link
Metadata SSH keys are ignored	Your organization requires SSH sign-in	Sign in with frazer compute vms ssh
The VM does not boot	A broken image, disk or startup script	Read the serial log on the Logs tab, check the VNC screenshot, or restart into rescue mode
Mail from the VM does not leave	Outbound port 25 is blocked by default	Send through a mail service on another port
The VM stopped after its server failed	Its disks are local-nvme	Restore the last backup to a new VM; use replicated disks for VMs that must survive a server
The machine type cannot change while running	Changing vCPU and memory live needs all disks replicated	Stop the VM, resize it, start it
A VM on the Frazer fleet stopped	A budget cap was reached; its disks are kept	A billing admin lifts the cap, then start the VM. VMs on your own servers are never stopped by a cap
VMs on a shared pool stopped	The pool was unshared and its grace period ended; disks stay 30 days	Snapshot to Frazer Storage, or move the VM to another pool or the fleet

To see why traffic is blocked, list the rules that apply to a VM, or test a path:

frazer network firewall-policies get-effective --vm web-1
frazer network connectivity-tests run --from vms/web-1 --to databases/orders --port 5432

Reference

CLI

Command	What it does
frazer compute vms create	Create a VM from a plan, on a server pool or in a Frazer fleet region.
frazer compute vms list	List the VMs in a project.
frazer compute vms get	Show one VM with its state, machine type, placement, disks and addresses.
frazer compute vms ssh	Sign in over SSH with a short-lived certificate; --tunnel goes through Frazer Link.
frazer compute vms console	Open the VM's serial console; --vnc opens the graphical console.
frazer compute vms stop	Stop a VM. Its disks stay, and it pays for storage only.
frazer compute vms start	Start a stopped VM.
frazer compute vms reset	Hard-reset a VM.
frazer compute vms resize	Change a VM's machine type.
frazer compute vms migrate	Live-migrate a VM whose disks are all replicated to another server in the site.
frazer compute vms delete	Delete a VM. Deletion is soft, with a restore window, and offers a final backup first.
frazer compute vms undelete	Restore a deleted VM inside its restore window.
frazer storage disks create	Create a local-nvme, replicated or scratch disk, blank or from an image or a snapshot.
frazer storage disks attach	Attach a disk to a VM, also while it runs.
frazer storage disks detach	Detach a disk from a VM.
frazer storage disks resize	Grow a disk while it is in use.
frazer compute snapshots create	Snapshot one disk, crash-consistent or app-consistent.
frazer compute snapshots restore	Restore a snapshot to a new disk, or over the disk of a stopped VM.
frazer compute images create	Create an image in a family from a disk, a URL or an uploaded file.
frazer compute instance-templates create	Create an immutable, versioned VM spec, for example from an existing VM.
frazer compute instance-groups create	Create a group of identical VMs from a template, with autohealing and autoscaling.
frazer compute backup-policies create	Back up the VMs that match a label on a schedule and keep a number of backups.

All of them: CLI reference.

Related

• VMs product page
• Servers and pools
• Volumes and snapshots
• VPC and firewall
• Kubernetes
• CLI reference