We handle
- Hypervisor, host patching, storage health, and network
- Snapshot schedule, off-host backup copies, and restore on request
- Console access, resource resizing, and capacity planning
- Publishing the guest through our edge if you want it public
Most common
Managed Virtual Server
A real machine with root, and somebody else responsible for the host.
What this tier is
Some software assumes it owns a machine. It wants a filesystem, a systemd unit, a kernel module, or a licence tied to a MAC address. Containers are the wrong shape for that, and pretending otherwise produces a fragile stack that nobody wants to touch.
This is a full virtual machine on our Proxmox estate. You get root and a distribution of your choice from the supported list. We keep the hypervisor patched, the storage healthy, the snapshots running, and the network working. What happens inside the guest is yours, though we are happy to be asked.
Specification
| vCPU | 2 cores |
|---|---|
| Memory | 4 GB |
| Storage | 60 GB on SSD-backed storage |
| Operating system | Supported Linux distribution of your choice |
| Access | Root over SSH plus independent console |
| Snapshots | Daily, 14-day retention, copied off-host |
| Networking | Private path to managed data tier; optional public via edge |
| Host maintenance | Performed by us, announced in advance |
What is included
- Full virtual machine with root access
- Choice of supported Linux distribution at provisioning
- Scheduled snapshots with copies held on separate storage
- Private networking to our managed data tier
- Optional publication through our edge with managed TLS
- Console access independent of SSH, for when SSH is the problem
- Host-level monitoring with alerting to us on hardware and capacity issues
Typical use cases
- Line-of-business software that expects a conventional server
- A development or staging box that needs to look like production
- Self-hosted services with unusual kernel or filesystem requirements
- Consolidating home lab machines onto maintained hardware
Responsibility split
Written down so there is no argument about it later.
You handle
- Everything inside the guest: packages, updates, users, and services
- Guest-level firewall rules beyond the ones we apply at the edge
- Application backups where a filesystem snapshot is not sufficient
How provisioning works
Operator-provisioned. We confirm distribution, sizing, and whether the guest needs public exposure, then hand over credentials and console details. Typical turnaround is one business day.
Order
Other tiers in Managed compute and containers
Entry
Container Workload
Your image, running on our cluster, described in a repository.
$14 /mo
- Declarative manifest held in Git, not clicked into a panel
- Public hostname with managed TLS, or internal only
- Restart policy, resource limits, and log access included
View details
More cores, more memory, and dedicated CPU rather than burst.
$72 /mo
- Dedicated CPU allocation rather than burst credits
- 8 GB memory and 200 GB storage
- Priority on capacity when we schedule host maintenance
View details
Cron that somebody notices when it stops.
$9 /mo
- Execution history and exit codes, not silent failure
- Alert on failure or on a missed run
- Runs on maintained infrastructure, not somebody's desktop
View details
Background reading
- Docker for game servers: clarity over hype Reproducible builds, update flow, and where containers stop helping.
- Double NAT and CGNAT: the silent party crashers Symptoms, diagnosis, and when a hosted relay is the honest answer.