Mature KVM virtualisation, without a mandatory hypervisor licence.
- Clustering, snapshots and replication capabilities
- Reviewed at version level before onboarding
- Hardware, licensing and site dependencies stay yours
Connect supported virtualisation environments to StackHost without replacing the hardware underneath them. We add monitoring, management, backup and recovery around your workloads, with a clear boundary for what we manage.
Edge is reviewed before it is onboarded, and the responsibility line is agreed in writing before anything goes live.Live regions Dallas · Denver
The node stays yours. The layer above it is where we work.
Edge sits where customer-owned infrastructure meets a managed hosting layer, so it is deliberately more selective than the other lanes.
We look at the node, the virtualisation foundation it runs, the role you want it to play, and whether the Edge model actually fits.
Before any configuration work, both sides sign off the written split: what StackHost operates, and what stays with you.
The accepted node is prepared for the StackHost layer, monitoring hooks and the support workflow it will be handled through.
Backup schedule, alert thresholds and escalation routes are agreed. Only then does the environment become active.
Nothing here is automated self-service. An Edge engagement starts with a conversation and a written boundary, which is also why it tends to stay quiet afterwards.
The reason a managed layer on top of someone else's hardware can work is that the boundary is explicit and written down early. Vague arrangements are discovered during incidents, which is the worst possible time.
This is the split we operate Edge against.
| Concern | StackHost operates | You keep |
|---|---|---|
| The node itself | — | Ownership, rental contract and the right to keep running it |
| Power, facility, local network | — | All of it, including whatever the site depends on |
| Virtualisation foundation | Day-to-day visibility and agreed changes | Vendor licensing and hardware repair or replacement |
| Hosting layer | Configuration, upkeep and the environments you agree to host | What you choose to deploy into it |
| Monitoring and alerts | Collection, alerting and first response on the hosted layer | Acting on what the alerts tell you |
| Backups | The agreed schedule, retention and restore testing | Deciding what is worth backing up in the first place |
| Support line | A named route for everything inside the hosted layer | Routing hardware and site faults to whoever owns them |
A dash means that concern stays on your side — agreed before it matters.
Routine agreed management is included in the Edge scope. Hands-on intervention outside that agreed scope runs through support time, unless you have a custom SLA.
Naming them is the point: a support model that accepts “anything virtualises” cannot promise a fast answer at 11pm.
In development — not bookable yet
Lightweight edge infrastructure suited to smaller remote locations.
Open-source Xen virtualisation for organisations looking for an alternative to licensed hypervisors.
Kubernetes-native virtualisation where VMs and containers need to coexist.
Compact highly available infrastructure suited to smaller sites.
Capabilities are confirmed during onboarding — two integrations are supported today, four more are in development.
Most of what makes infrastructure tiring is not the box — it is the tools scattered around it, each with its own login and its own idea of what healthy means.
Depending on platform and deployment, Edge brings these under one operating model.
Capabilities vary by hypervisor and are confirmed during onboarding. Backup and disaster recovery stay separate conversations: a backup is a copy you restore from, recovery is a way back after a larger failure.
Edge is quoted per engagement: the answer depends on what the infrastructure already is and what you want it to carry. The review is a technical conversation, not a sales call.