A small VPS host can begin with one leased server and five customers. This modest setup tests the service with real money and real workloads. Investors, racks and a support rota can wait until demand justifies them.
The machine provides the compute. The service also has to start on time, keep its addresses, survive routine maintenance and recover after a failure. The operator handles password resets, failed payments, noisy neighbors, abuse reports and the occasional customer who believes "unmanaged" means "someone else will fix it at 3 a.m."
This guide builds the smallest credible version of that service. It uses a dedicated server, Proxmox Virtual Environment, KVM guests, two maintained Linux images, remote backups and public IPv4 addresses routed through one tunnel. The result is a first node that can show its operator what the second node needs to solve.
Start with a smaller promise
A first product should be narrow enough to operate manually. A single location, two plan sizes, monthly billing and Linux-only service are enough. Instant global deployment, hourly billing, five distributions and automatic failover increase setup and support work before demand is known.
The initial offer can be described plainly: unmanaged KVM VPS hosting for developers, small services and private infrastructure. The word unmanaged needs a definition beside it. Hardware, host networking and console access belong to the operator. Packages, application configuration and data inside the guest belong to the customer. Security incidents still cross that boundary and require active monitoring.
A single node has no compute failover. If it loses power, storage or network access, every VPS on it stops. Backups support recovery after the incident. High availability requires additional compute infrastructure.
A narrow offer is easy to explain and support. Early customers receive direct access to the operator and a fair price. The operator has fewer order paths to maintain.
Rent the first node in a datacenter
A home lab provides a practical place to learn Proxmox. Paying workloads need stable power, predictable connectivity and remote intervention when the machine stops responding. Commercial hosting may also conflict with residential access-provider terms. A site that has no public address adds another problem, explained in the guide to hosting behind CGNAT.
For the first sellable node, a leased dedicated server removes several distractions at once. The datacenter handles power, cooling, physical replacement and upstream connectivity. The operator remains responsible for the service layer.
The whole machine must suit the expected workload. A useful pilot specification looks like this:
| Resource | Sensible starting point | Reason |
|---|---|---|
| CPU | Modern 8 to 16 core x86 server CPU with AMD-V or Intel VT-x | Enough parallel capacity for a small mixed workload and moderate shared use. |
| Memory | 64 or 128 GB ECC RAM | Memory is easy to account for and often sets the first capacity ceiling. |
| Storage | Two enterprise SSDs or NVMe drives in a mirror | A mirror tolerates one drive failure. Enterprise drives handle sustained writes more predictably. |
| Network | 1 Gbit/s port with a stated traffic allowance | A stated transfer allowance makes the network capacity measurable. |
| Recovery | Out-of-band console or remote KVM | Remote access recovers broken firewall and boot configurations. |
Proxmox recommends fast redundant storage for production and publishes separate requirements for evaluation and production hardware. Customer data needs the production specification. The current Proxmox hardware guidance is worth checking against the shortlisted machine before signing a long contract.