Bare metal, provisioned like cloud

What a bare metal server actually is

A bare metal server is one physical machine, rented whole, with your operating system installed directly on the hardware. There is no hypervisor between your kernel and the CPU, and no other customer on the box. When you read a core count, that is the core count you get, every hour of the month, whether or not somebody else on the same rack is running a build.

The difference people notice first is not raw speed but predictability. A virtual instance is a scheduling promise: the hypervisor decides when your vCPU runs, how much of the host NIC you see, and how deep the storage queue goes. On bare metal those are physical facts you can measure once and rely on. That matters most for the workloads that are sensitive to the ninety-ninth percentile rather than the average: databases, latency-bound game servers, real-time media, and anything where a scheduler stall shows up as a user complaint.

Where the two models actually differ

Cloud instances are the right tool for bursty, short-lived, horizontally scaled work. This is the honest list of what changes when the workload stops being any of those things.

The trade is real in both directions: you cannot resize a physical box at 3am, and you should not pick one for a workload that idles at zero most of the week. What you get in return is a machine whose performance you can characterise once, and a bill that does not move when your traffic does.

What comes with every server

You pay for the server, for additional IP blocks, and for bandwidth beyond your plan's allowance. Every other function in this table comes with the server at no cost.

Workloads that earn the whole machine

Four patterns come up over and over in the accounts that move off virtual instances.

• Kubernetes on metal. Running the kubelet directly on the host removes a scheduling layer from every pod and gives the CNI a real NIC to work with. You also stop paying twice for isolation you already get from the cluster.
• Databases and anything storage-latency bound. Physical disks in the chassis, no network storage hop, and a page cache that is not competing with another tenant's.
• Game and real-time servers. Tick rates live or die on the tail of the latency distribution, which is exactly what a shared host scheduler makes unpredictable.
• Steady, always-on compute. CI fleets, encoders, indexers and batch workers that run flat all month. Elasticity you never use is elasticity you should stop paying for.

If your workload is bursty, idles overnight, or scales out and back several times a day, a cloud instance is genuinely the better answer. We sell those too.

From claim to root shell

The point of running bare metal cloud-style is that a physical machine stops being a project. This is the entire lifecycle, in the console or over the API.

1. 1Claim a machine. Pick a configuration from the live catalogue and choose a billing cycle: hourly if you are testing, longer if you are staying. The same operation is one call with an API key you issue yourself.
2. 2The install runs itself. A cloud-init image lands on the hardware and reports progress live in the console. No ticket, no scheduled window. Need something outside the catalogue? Mount your own ISO over virtual media or boot it with iPXE.
3. 3Get to work. SSH in as normal, or open the browser KVM to watch the boot and fix what breaks: out-of-band, in seconds. DDoS mitigation is already inline in front of the machine, including during the install.
4. 4Capture it, move it, or hand it back. Record an image of the live server and redeploy it onto another box, or return the machine when the job ends. An hourly server is a resource, not a contract.

Every step above is an API call as well as a console click. The cloud console is a client of the API, not a layer above it. Issue a key and script the parts you do more than once.