Not sure what to deploy? Here's a quick map.
| You want to… | Use |
|---|---|
| A flexible virtual server you fully control | VPS |
| Dedicated, single-tenant physical hardware | Dedicated Server |
| Run containers at scale | Managed Kubernetes |
| A managed MySQL, PostgreSQL or Valkey | Managed Databases |
| Spread traffic across servers | Load Balancer |
| Serve static content fast worldwide | CDN |
| Manage domains and records | DNS |
| Call AI models through one endpoint | AI Gateway |
| Launch a ready-made application | Apps |
If you're just getting started, deploy a VPS first. It's the most flexible and the easiest to undo.
VPS or dedicated server?
The most common first decision:
| VPS | Dedicated Server | |
|---|---|---|
| Billing | Hourly — destroy it and charges stop | Monthly, paid in advance |
| Ready in | Minutes | After payment and physical provisioning |
| Resize | Change the plan in place, up or down | Not possible — order a different machine |
| Hardware | A slice of a shared host | The whole physical machine |
Choose dedicated when you need consistent I/O, a specific RAID layout, hardware-level control (IPMI, custom ISO boot) or licensing that requires a physical machine. Choose VPS for everything else — and note that "I'll need more later" is an argument for the VPS, since it's the one you can resize.
Shared or dedicated CPU?
Once you've chosen a VPS, pick its family:
| Family | vCPU | Good for |
|---|---|---|
General Purpose (gp.*) | Shared | Websites, APIs, small databases, bots, staging |
High Frequency (rz.*) | Shared, AMD Ryzen | Shared plans that need faster single-thread performance |
Dedicated CPU (dc.*) | Dedicated | Workloads that keep the CPU busy: builds, CI runners, video encoding, batch jobs |
High Frequency Dedicated CPU (hd.*) | Dedicated, AMD Ryzen | Busy, single-thread heavy work such as game servers |
On a shared plan the vCPUs share physical cores with other customers' servers, and the plan is sized for normal usage with bursts. On a Dedicated CPU plan the vCPUs are reserved for your server, so its performance doesn't depend on what its neighbours are doing. If your workload keeps the CPU close to full for long periods, choose a Dedicated CPU plan.
A VPS can only be resized within its own family. If you start on a shared plan and later need dedicated CPU, take a snapshot and deploy it on a Dedicated CPU plan.
NoteCryptocurrency mining is not allowed on any CubePath service, whatever the plan.
Managed or self-hosted?
You can run PostgreSQL on a VPS yourself for less than a managed database costs. What you're buying with the managed version is replication, automatic failover and the operational work of keeping it healthy — which only becomes a bargain once an outage would actually hurt.
The same logic applies to Kubernetes: a managed control plane costs more than a single VPS running Docker, and is worth it exactly when you have enough services that orchestrating them by hand has become the job.
How they combine
Most real setups are a few of these together. Three shapes cover the majority:
- A website that has to stay up. Two or more VPS in an availability group, a load balancer in front, a managed database behind, and a CDN for the static assets.
- A private application tier. Servers on a private network with no public IPs, a NAT Gateway for outbound access, and a load balancer as the only way in.
- A container platform. A Kubernetes cluster with an ingress controller and a load balancer in front of the workers.
TipStart with the smallest thing that works and add pieces when a specific problem shows up. Every component above solves a real problem, and every one you add before you have that problem is something you now have to operate.