Virtual Servers
Virtual Private Servers
Committed compute on hardware we own, with root access from the first boot and a monthly figure that does not move.
Every instance is a virtual machine on the Karl platform, the container-native virtualisation stack we run on hardware we own and operate. vCPU and memory are committed rather than oversubscribed, storage is NVMe backed by Ceph or ZFS, and snapshots run to mapped persistent volumes on a schedule you agree. You get root, a fixed monthly price, and a named engineer to call.
Who It Is For
- Teams outgrowing shared hosting
- Agencies running client workloads
- Businesses moving off a cloud bill they cannot forecast
What It Is
A full virtual machine with its own kernel, on a Karl cluster we own and operate
What You Control
Root from handover, plus console and API, so the kernel and the stack are your choice
How It Is Billed
One fixed monthly figure per instance, quoted against the specification before you commit
Who Answers
The engineer who sized and built it, with a managed layer available
Specification
Virtualisation
Karl, container-native, one control plane
Storage
NVMe backed, ZFS or Ceph
Network
1 Gbps port, IPv4 and IPv6
Backups
Karl Snap to mapped volumes, retained off-host
Provisioning
Minutes, not tickets
Access
Full root, console and API
What You Get
Real Isolation
Each instance is a full virtual machine with its own kernel, committed vCPU and committed memory. Nothing is shared with another tenant at the OS level, and nothing is oversubscribed without telling you first.
Snapshots And Restores
Snapshots are taken through Karl Snap and written to mapped persistent volumes, deduplicated and retained off-host. Restores are rehearsed on a cadence we agree with you, so the recovery time you have been quoted is one we have actually measured.
Grows Sideways
Start on a single node and move to a Kubernetes-orchestrated cluster with instance pools and automatic rescheduling, without rebuilding the workload. Storage moves from local ZFS to replicated Ceph on the same path.
Operated, Not Abandoned
Monitoring, patching and remediation are available as a managed layer, so you can take the instance as unmanaged compute or hand the whole thing to us and keep one number to call.
Pricing
Three standard configurations, priced per month. Committed vCPU and memory, NVMe storage and a daily backup of the previous twenty four hours are on every one of them. Anything that does not fit these three is sized and quoted against the workload.
INVPS-1
₹2,025
Excluding GST, per month
- 4 vCores
- 8 GB RAM
- 75 GB SSD NVMe
- Daily backup of the previous 24 hours
- Unlimited traffic
- 1 Gbps public bandwidth
INVPS-2
₹2,900
Excluding GST, per month
- 6 vCores
- 12 GB RAM
- 100 GB SSD NVMe
- Daily backup of the previous 24 hours
- Unlimited traffic
- 2 Gbps public bandwidth
INVPS-3
₹5,600
Excluding GST, per month
- 8 vCores
- 24 GB RAM
- 200 GB SSD NVMe
- Daily backup of the previous 24 hours
- Unlimited traffic
- 3 Gbps public bandwidth
Figures are monthly and exclude GST. Additional storage, extra public addressing, Windows licensing and the managed operations layer are quoted on top of the plan.
How It Works
Five stages from an enquiry to an instance you can grow into. Nothing here needs a call to get moving.
Sizing
We start from the workload rather than a tier list: what runs on it, how it peaks, and what it depends on elsewhere. The output is a written specification with committed vCPU, memory and storage, and a monthly figure against it.
Provisioning
The instance is cut on a Karl node in the cluster, with its disk on NVMe backed ZFS or Ceph. Root credentials, console access and API tokens are handed over together, so nothing is held back behind a support ticket.
Backup And Verify
Karl Snap takes the instance on the schedule you agreed, deduplicated and written to mapped volumes retained off-host. Restores are rehearsed against those snapshots, so a backup that cannot restore is found before the day you need it.
Operate
Monitoring, patching and capacity review either stay with your team or come to us as a managed layer. Either way the console, the API and the data stay yours throughout.
Grow
When one node stops being enough, the instance moves onto a Kubernetes-orchestrated Karl cluster with instance pools and automatic rescheduling, and storage moves from local ZFS to replicated Ceph. The workload is not rebuilt to get there.
Against Shared Hosting
Most enquiries arrive from a shared plan that has run out of room. These are the differences that actually change how the box behaves.
Isolation
- Shared Hosting
- One operating system divided between many accounts, with limits enforced by a control panel
- Our Virtual Servers
- A full virtual machine with its own kernel, its own memory and its own scheduler
Noisy Neighbours
- Shared Hosting
- Another account's traffic spike becomes your traffic spike
- Our Virtual Servers
- vCPU and memory are committed to the instance rather than pooled and oversubscribed
Root Access
- Shared Hosting
- Whatever the panel chooses to expose, with kernel modules and system services out of reach
- Our Virtual Servers
- Full root from handover, with console and API, so you choose the kernel and the stack
Backups
- Shared Hosting
- A button in a panel, with no way to prove that a restore actually works
- Our Virtual Servers
- Karl Snap to mapped volumes, with restores rehearsed on an agreed cadence
Growth Path
- Shared Hosting
- Move to a different product once the plan is outgrown, and migrate again
- Our Virtual Servers
- Add nodes, move to Ceph and enable HA on the same instance, with no rebuild
Who Answers
- Shared Hosting
- A queue staffed by people who have never seen your workload
- Our Virtual Servers
- The engineer who wrote the specification and built the instance
What We Need From You
Five things, and a specification comes back. None of them require a meeting first.
A Workload Description
What the box runs: application, database, queue, batch job, whatever else. Peak behaviour tells us more than an average ever will.
An Operating System Position
The distribution and version you want to standardise on, or a note telling us to recommend one and why the choice is open.
Network Requirements
Public addressing, private ranges the instance has to reach, and anything that must stay reachable from a fixed address.
Backup Expectations
How far back you need to be able to go, and how long a restore can take before it stops being an inconvenience and starts being an outage.
A Named Contact
One person who can approve the specification and take the credentials at handover, so the build does not stall waiting on a signature.
Send those five and a written specification comes back with a monthly figure against it. An engineer picks it up, not a form.
Start An EnquiryQuestions About Virtual Servers
The technical ones that come up before anyone asks for a figure.
vCPU and memory are committed to the instance rather than pooled across tenants. Where a workload genuinely benefits from a shared pool we will say so and put it in the specification, rather than leaving you to notice it under load.
Yes. Karl will import a qcow2, raw or VMDK disk, so an existing machine can be moved rather than rebuilt from scratch. We check the boot mode and the drivers with you before the cutover window, not during it.
On a single node deployment the instance is restored from its Karl Snap. On a clustered deployment the orchestrator reschedules it onto another node, and because Ceph has already replicated the storage, the disk does not have to move with it.
Either, and you can change your mind later. Taken unmanaged you get root and the console and we stay out of the operating system. Taken managed, monitoring, patching and backup verification move to us, with the same engineers on it.
Yes. KVM runs Windows Server as a guest with VirtIO drivers for disk and network. The licence stays yours to hold, and we will tell you what the hypervisor reports to a licence check before you commit to anything.
Size A Server With Us
Send us the workload and we will reply with a specification and a monthly figure. No call needed to get a number.
Sales
- New servers, identity rollouts and workstation pilots
- Specifications, sizing and monthly pricing
- Moving an existing estate across to us
sales@infinite-networks.net
Support
- Anything already running with us
- Incidents, capacity changes and restores
- Accounts, access and policy changes
support@infinite-networks.net
Office
#002, Ceaser's CastleSainikpuri, Defence Colony
Hyderabad 500 094
India