microsrv
a cloud for developers
SSH access, a hostname, and TLS are available out of the box — no nginx and certbot setup required. VMs run on interruptible capacity from major clouds, which keeps costs down, and live migration preserves running processes, volumes, IP addresses, and connections.
Traffic flowing
HTTPS and the private connection are active
> how it works
You create VMs, connect over SSH, and deploy services as usual — hostname and TLS work out of the box. VMs run on spare capacity from major cloud providers, which makes them about 25% cheaper than standard rates, while the orchestrator manages host changes and preserves volumes and network identity.
01
Live migration transfers memory and running processes to a new host. Your workload keeps running without restarting or losing its in-memory cache, while network connections and addresses remain unchanged.
The orchestrator tracks spare vCPU and memory on adjacent servers to keep capacity available when a VM needs to move.
Paid vCPUs belong exclusively to your VM and are not shared with other customers.
A provider notice triggers live memory migration. Running processes continue on the new host without restarting the application.
When there is not enough time for live migration, the VM automatically launches from a replicated copy.
VMs run on interruptible cloud instances even where providers disable hardware nested virtualization.
02
Providers offer spare capacity at up to 70% off, but warn that hosts can be reclaimed whenever demand spikes.
Without automated orchestration, this capacity is typically used for noncritical or interruption-tolerant workloads. Our platform handles the operational work: it monitors provider notices, reserves capacity on nearby servers, and moves or recovers VMs when a host is reclaimed.
In the examples below, the total cost is about 25% below what the same provider charges.
interruptible capacity + microsrv orchestration = stable VM at a lower price
See the price comparison →03
Create a VM, connect over SSH, and deploy your services. Live migration happens automatically in the background.
Choose CPU, memory, and volumes. Configure the initial boot with cloud-init.
Use a persistent private IP and replicated volumes that remain intact across migrations.
Connect through the SSH gateway, or publish a service through the HTTPS gateway — hostname and TLS included.
Run web apps, databases, or background jobs. When a host is reclaimed, the platform migrates the VM or recovers it automatically.
04
Public services, internal systems, and background workers run as they would on traditional VMs.
Web applications, databases, AI agents, and background workers receive dedicated vCPUs, a private network, and a stable SSH address.
> pricing
VMs run on interruptible capacity while the platform provides 99.9% availability. The table below shows the cost of a typical three-node cluster.
Reference workload
3 × (4 dedicated vCPUs · 8 GB RAM · 40 GB SSD) — small cluster / Kubernetes node group
Self-hosted microsrv
Deploy microsrv on your own servers or in your cloud, and manage VMs, networking, and migrations from one place.
Estimated monthly totals for 3 × (4 vCPU · 8 GB · 40 GB SSD). Cloud A and Cloud B are standard rates from public provider calculators. Final microsrv pricing depends on the region, available capacity, and hosting terms.
> development & operations features
Network isolation, secure access, and service publishing are built in, with no additional infrastructure to configure.
Connect via ssh -A <vm>@msrv.space. Port 22 is never exposed to the internet, and no public IP is needed.
Add SSH keys, initialization scripts, and configuration during the VM’s first boot.
Isolated private networks with stable internal IPs and in-kernel protection against IP/MAC spoofing.
Reach external APIs, Git repositories, and registries while keeping the VM inaccessible from public ingress.
Your work laptop joins the VPC through the WireGuard gateway. With Kilo, microsrv nodes become part of your Kubernetes cluster.
Expose HTTPS apps and TCP databases with permanent <vm>.msrv.space hostnames and automated TLS.
Live memory migration keeps your application running without restarting, while eBPF identity rebinding preserves open TCP connections.
The VM needs no public IP, and its SSH port is never exposed to the internet. Its address remains the same regardless of the current physical host.
$ ssh -A <vm>@msrv.spacemicrosrv: connection to <vm> establishedWelcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-60-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com System information: 4 vCPU · 8 GB RAM · 40 GB SSDPrivate address: 10.42.0.17 Last login: Fri Jul 24 20:51:08 2026 from 10.42.0.1ubuntu@<vm>:~$Publish a web app or TCP service without assigning the VM a public IP. The HTTPS gateway accepts HTTPS traffic and routes TCP connections by TLS/SNI.
$ curl -v https://<vm>.msrv.space* Host <vm>.msrv.space:443 was resolved* Connected to <vm>.msrv.space port 443* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384> GET / HTTP/2> Host: <vm>.msrv.space< HTTP/2 200< server: microsrv-gateway< content-type: application/json {"hello":"from <vm>"}$$ psql "host=<vm>.msrv.space sslmode=require"psql (16.3, server 16.3)SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384)Type "help" for help. <vm>=> SELECT current_database(), inet_server_addr(); current_database | inet_server_addr------------------+------------------ app | 10.42.0.17(1 row) <vm>=>Every private network has a WireGuard gateway: your work machine gets an address inside the VPC, and database queries go over internal IPs — no exposed ports, no public IP.
$ wg-quick up microsrv-vpc[#] ip link add microsrv-vpc type wireguard[#] ip address add 10.50.0.200/32 dev microsrv-vpc[#] ip route add 10.50.0.0/16 dev microsrv-vpcpeer vpc-production: handshake complete user@laptop:~$ ping -c 2 10.50.0.12PING 10.50.0.12 (10.50.0.12) 56(84) bytes of data.64 bytes from 10.50.0.12: icmp_seq=1 ttl=64 time=4.05 ms64 bytes from 10.50.0.12: icmp_seq=2 ttl=64 time=3.87 ms --- 10.50.0.12 ping statistics ---2 packets transmitted, 2 received, 0% packet lossuser@laptop:~$$ psql -h 10.50.0.21 -U apppsql (16.3, server 16.3)Type "help" for help. app=> SELECT inet_server_addr(); inet_server_addr ------------------ 10.50.0.21(1 row) app=>> roadmap
Planned capabilities that are not currently available.
> blog
Short notes on interruptible capacity, networking, and how microsrv keeps VMs running through host interruptions.
What Hermes Agent from Nous Research can do and how to run it in a container on microsrv: official image pinned by digest, gateway mode, dashboard with basic auth, and publishing via an HTTPS gateway.
How to pair the density of containers with the flexibility of KVM virtual machines in a unified private network using a self-hosted Git & CI/CD stack.
How live migration works: pre-copy, dirty pages, stop-and-copy, cold restart as a fallback, and the way the microsrv orchestrator migrates VMs before Spot hosts are reclaimed.