Bare Metal, bereitgestellt wie in der 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.

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 panel is a client of the API, not a layer above it. Issue a key and script the parts you do more than once.

Our own network, not resold capacity

Every server here connects through AS55285, an autonomous system we operate end to end. We register our own routes under AS55285:AS-ALL, set our own peering policy, and answer for our own routing decisions instead of relaying your problem to an upstream. Servers land on dual uplinks across separate switches, take diverse paths through the fabric, and reach the internet through a blend of transit and settlement-free peering at 6 exchanges. IPv4 and IPv6 are both live on day one, and you can announce your own address space over BGP if you have it.

None of that has to be taken on faith. Our ASN and peering records are public on PeeringDB and bgp.tools, and our looking glass runs ping, traceroute and BGP lookups from every metro we sell servers in. Measure the path from where you actually sit, before you order.