Bare Metal Servers

Every server was a bare metal server once. Before virtualization and the cloud, a physical machine running an operating system on its own hardware was simply what a server was. The term exists today to draw a line between that original model — one physical machine, one tenant, direct access to the hardware — and the shared, virtualized infrastructure that became the default in between. In 2026, bare metal is neither a relic nor a niche; it is a deliberate choice for workloads that want the hardware itself, delivered with the automation and speed people now expect. This page explains what a bare metal server is, how it differs from the older idea of a “dedicated server,” how provisioning and automation actually work, the workloads that reward direct hardware access, and where bare metal is the wrong tool — written plainly, the way we would walk a customer through it.

What is a bare metal server?

A bare metal server is a physical machine rented to a single customer, with the operating system installed directly on the hardware and no virtualization layer in between. The phrase points at the architecture: there is no hypervisor creating guest machines on top of the hardware, so the operating system sits on the metal and talks straight to it.

That direct relationship is the whole substance of the idea. On a virtualized host, a hypervisor divides one physical machine among several tenants and mediates their access to the underlying resources; the operating system never touches the hardware directly. On bare metal, there is nothing in the path. The CPU executes instructions without a translation layer. Applications address memory without negotiating for their share. Storage and network I/O run without a virtualization tax skimming resources to manage the environment. And because the machine is single-tenant, the noisy-neighbor problem — where another tenant’s heavy load on the same host degrades your performance — does not exist, since there is no one else on the machine. What you rent is a complete, functional computer that is yours alone for the term of the rental, to configure however the workload needs.

Bare metal or dedicated server — is there a difference?

In most conversations, none that matters: both describe single-tenant physical hardware. But the language has shifted, and the shift is worth knowing because it shapes what people expect when they hear each term.

“Dedicated server” is the older phrase. It grew up describing a physical box leased on a monthly or annual contract, provisioned by hand — a technician racking the machine, cabling it, and installing the operating system over hours or, historically, days. The phrase sometimes still carries that association of a slower, manual, more traditional arrangement. “Bare metal” emerged later as a name for the same single-tenant machine delivered in a more cloud-like way: provisioned automatically in minutes, managed through an API or a portal, and billed flexibly, sometimes by the hour as well as the month or year. So when a provider draws a distinction, “bare metal” tends to signal speed and automation while “dedicated” signals a conventional lease — but underneath, the hardware is the same and the single-tenant performance is identical.

We treat the two as synonyms and let the work speak. A machine is provisioned quickly and cleanly or it is not; it is sized to your workload or it is not; it is managed well or it is not. None of that depends on which word appears on the order form. If it helps to think in terms of “dedicated server hosting,” our dedicated server hosting page covers the same ground from the cost-and-buying angle; this page leans into the architecture and the way the machine is delivered.

How direct hardware access changes performance

The performance argument for bare metal is not a vague claim that physical is faster; it is specific, and it comes from removing the hypervisor.

On a virtualized host, the hypervisor that divides the machine consumes a portion of its resources just to run the virtualization environment — commonly cited as somewhere around 5 to 15% of the host, depending on the workload and the platform. That is overhead you pay before any of your own work runs. On bare metal there is no hypervisor, so that overhead is simply absent, and a dedicated core consistently outperforms a virtual core of the same nominal size. The benefit is sharpest for I/O. Applications on bare metal communicate directly with PCIe devices — NVMe drives, network cards, GPUs such as the NVIDIA accelerators used for AI — and that direct path matters enormously for latency-sensitive work, where a virtualization layer in the way adds jitter and delay that a high-frequency trading system or a busy database feels.

The second half of the performance story is consistency. Because no other tenant shares the machine, your throughput and latency depend only on your own workload, not on a stranger’s traffic spike. For workloads where steady, predictable performance is the requirement — and that describes most production databases and most sustained sending platforms — this predictability often matters more than peak speed. A machine that is reliably fast is worth more than one that is occasionally faster and occasionally throttled by a neighbor.

There is a storage dimension to this too. Direct access to NVMe drives, without a virtualization layer translating block I/O, gives databases and write-heavy systems the low, consistent latency they depend on, and lets you choose the exact disk layout — single drives for speed, mirrored or RAID arrays for redundancy — rather than accepting an abstracted volume whose real performance you cannot see. For a workload whose bottleneck is disk rather than CPU, that direct path is frequently the whole reason to choose bare metal.

How does bare metal provisioning actually work?

The old image of dedicated hosting — a technician racking a machine over days — has largely been automated away, and understanding how is useful, because provisioning quality is a real differentiator between providers.

When you order a modern bare metal server, an automation platform runs the steps a human used to: it finds a physical machine matching your specification, installs your chosen operating system from a master image, configures the network and assigns IP addresses, and hands you secure credentials to log in. With a well-built stack the machine can be online in minutes; platforms built on tooling like Canonical’s MAAS have reported provisioning a dedicated server in under two minutes. At fleet scale, providers run dedicated provisioning systems — MAAS, Foreman, or OpenStack Ironic among the common ones — that treat racks of physical hardware as a pool of resources managed through the same kind of API used for virtual machines, handling discovery, health checks, OS deployment, and decommissioning across many machines.

Underneath all of it is the baseboard management controller, the BMC, reached over IPMI or a modern equivalent. It is an independent path into the server that works even when the main operating system is down, and it is the cornerstone of lights-out automation: powering the machine on, setting boot order, installing an operating system over the network, and recovering the server remotely. Configured properly, the BMC sits on an isolated management network with a static address and strong credentials, never exposed to the public internet. That same out-of-band access is what lets you reinstall or reboot in an emergency without a support ticket. The snapshot below is the shape of an automated provision, lightly abstracted.

# automated bare metal provision · lights-out via BMC/IPMI · mcsnet
# 1. out-of-band power + boot the target node
ipmitool -H bmc.node-17.tor -U ops chassis power on
ipmitool -H bmc.node-17.tor -U ops chassis bootdev pxe
# 2. platform installs the OS from a master image over the network
provision —node node-17.tor —os almalinux-9 —disk raid1-nvme
# 3. network + IP plan applied, credentials issued
net apply —node node-17.tor —vlan prod —ip /29 —gw auto
# 4. machine handed over — online, ready, single-tenant
status node-17.tor   ==>   READY · ssh root@NODE-IP  (online · single-tenant)

The honest note is that building this kind of automation well is hard, and keeping it reliable is ongoing work. Part of what you pay a provider for is that the automation already exists and is maintained, so you get the speed without owning the complexity.

Three ways to get bare metal: on-prem, colocation, and rental

There are three routes to a bare metal environment, and they differ mainly in how much of the physical burden you carry.

The first is on-premises: you buy the servers and run them in your own facility, with your own power, cooling, networking, and staff. You own the hardware outright, and you own every operational responsibility that comes with it. The second is colocation: you still own the servers, but they live in someone else’s data center, racked among other companies’ machines, with the facility providing power, cooling, and connectivity while you remain responsible for the servers themselves. The third is rental — infrastructure as a service, or bare metal as a service. Here you rent the machines from a provider who sources and configures them to your specification, racks them, powers and maintains them, manages the relationships with the networks, and hands you control through a portal. Rental removes the upfront capital cost entirely and turns infrastructure into an operating expense you can take by the month, the year, or in some models by the hour.

Most teams that want bare metal without becoming a data-center operator choose rental, which is the model we provide. It gives you the single-tenant hardware and full control of the operating system and stack, without the capital outlay, the procurement lead time, or the physical work of running a facility. What you keep is the part worth keeping: control over the machine and the software on it.

Running your own hypervisor or Kubernetes on bare metal

One of the most useful properties of a bare metal server is that nothing is decided for you above the hardware. Because there is no pre-installed hypervisor, you can install your own — KVM, Proxmox, VMware, or Hyper-V — and run virtual machines on top, building a private cloud where you, not a provider, decide how the hardware is carved up. This is a standard pattern for teams that want the control and isolation of physical hardware with the internal flexibility of virtualization, on their own terms.

Bare metal is just as natural a foundation for containers. Running Kubernetes directly on physical nodes — bare-metal Kubernetes — gives container workloads a direct path to the hardware with no virtualization layer in between, which keeps performance predictable and avoids the resource over-provisioning that can sit underneath a virtualized cluster. Because the nodes are single-tenant and not shared, scaling stays performance-predictable even under heavy load. This is what full-stack control means in practice: you choose the operating system, the kernel, whether to virtualize and with what, and how to orchestrate — rather than accepting the abstractions a managed platform imposes. When a customer wants machines specifically as hypervisor hosts or Kubernetes nodes, we provision them for exactly that, sized and configured for the role.

What workloads is bare metal built for?

Bare metal earns its place where consistent performance, direct hardware access, or physical isolation are genuine requirements. A few categories come up again and again.

Databases are a natural fit: engines such as PostgreSQL, MySQL, and MongoDB reward the predictable disk and network I/O that single-tenant hardware provides, particularly under sustained load where a shared host’s variability would show up as latency. Latency-sensitive workloads benefit for the same underlying reason — online games, real-time applications, and high-frequency trading, where the direct application-to-hardware path and the absence of hypervisor jitter are measurable advantages. AI and GPU workloads favor bare metal because an accelerator needs direct I/O to deliver its full capability, and a virtualization layer in the path costs real performance during training and inference. High-traffic websites and SaaS platforms lean on dedicated CPU and memory to stay responsive under load rather than degrading when a neighbor gets busy. And compliance-driven workloads in finance, healthcare, and government often require the physical isolation that single-tenant hardware gives, which makes the security and regulatory story simpler to defend.

Two more categories round out the list. Analytics and big-data workloads — Spark clusters, data warehouses, batch pipelines — move large volumes through CPU and storage continuously, and they hold their performance better on dedicated nodes than on shared instances that throttle under sustained throughput. And edge or content-delivery roles, where a machine sits close to users to cut latency, benefit from a predictable, single-tenant box whose response time does not wander with a neighbor’s load. The thread connecting all of these is that they are steady, performance-sensitive, or regulated. That is the profile bare metal serves well, and it is worth matching your own workload against it honestly before committing.

When a bare metal server is the wrong tool

The same honesty that recommends bare metal for steady workloads recommends against it for others, and a provider worth trusting will tell you which you have.

Bare metal gives you fixed capacity at a fixed cost. That is a strength for sustained load and a weakness for spiky load: if your demand peaks occasionally and runs low the rest of the time, you pay for the peak continuously while using a fraction of it, and cloud or a VPS lets you pay closer to what you actually consume. Scaling is also slower than a slider — adding capacity means provisioning more physical hardware, and even with fast automation that is a heavier operation than resizing a virtual instance — so workloads that must scale up and down rapidly and unpredictably are a poor match. A small project or a development environment is usually more than bare metal needs, where a VPS offers ample power for far less commitment. And bare metal carries more operational responsibility than a managed cloud service: you, or a managed-hosting arrangement, own the operating system, patching, and maintenance.

If your workload is variable, bursty, experimental, fast-scaling, or small, bare metal is the wrong tool, and we will say so rather than rent you a machine that sits half-used. Knowing when not to use it is part of using it well.

Bare metal for email infrastructure

Email infrastructure is one of the cleanest cases for bare metal, which is why it is our specialty. A mail platform is a sustained, performance-sensitive workload with a specific dependence on the physical machine, and each of those qualities points at single-tenant hardware.

A busy mail transfer agent handles many concurrent connections and writes constantly to queues and logs, so it rewards the direct, predictable disk and network I/O that bare metal provides — the same direct hardware path that helps databases helps a sending engine. Sending continues around the clock rather than spiking unpredictably, which suits fixed capacity. And sending-IP reputation, the foundation deliverability rests on, attaches to the infrastructure mail leaves from; on shared hardware, the noisy-neighbor problem becomes a deliverability risk when another tenant’s load can affect your sending performance. A single-tenant box removes that risk and keeps the sending environment entirely yours. We run managed PowerMTA and KumoMTA on bare metal for exactly these reasons, with full out-of-band access for recovery, and we size and tune each machine to its sending workload rather than handing over a generic plan. The configuration that matters here is specific — enough CPU for concurrent connections, fast mirrored NVMe for queue and log I/O, memory headroom for reputation state, and a warmed IP block tied to the machine — and getting it right is the difference between a sending platform that holds its deliverability and one that fights the inbox. That match between machine and sending workload is precisely the decision we are set up to make well.

Provisioned and run from Toronto and six more locations

Where a bare metal machine lives affects latency to its users, the data-residency rules it falls under, and — in 2026 — the power and supply conditions of the region. Our home data center is in Toronto, which gives Canadian data residency and a stable North American base, and we run servers in Frankfurt, Strasbourg, Amsterdam, Singapore, Panama City, and Miami so you can place a machine close to its users or inside a required jurisdiction.

We provision and operate the hardware rather than just leasing it: out-of-band access through the BMC for fast deployment and recovery, remote-hands work in the facility when something physical needs doing, and administration and managed hosting for teams that would rather have the box run for them. You can compare configurations and locations in our configurator, and when the build or location you need is not listed, it is usually available on request.

Why work with us?

Most of the bare metal we run, we run for our own sending infrastructure, so the operational knowledge is first-hand rather than theoretical. We size machines to the real workload instead of upselling capacity, build and maintain the provisioning automation so you get speed without owning its complexity, and treat the unglamorous parts — monitoring, patching, recovery, and the out-of-band access that makes recovery quick — as the actual job.

The honest thread runs through all of it. We would rather provision a right-sized machine and tell you to keep your bursty traffic on cloud than rent you a box that idles. That is how infrastructure decisions hold up over years, and it is the kind of working relationship we are trying to build rather than a transaction we are trying to close.

Who this is for, and who it is not

Bare metal servers are for workloads that are steady, performance-sensitive, or bound by compliance, and for teams that want direct hardware access or full-stack control: databases under sustained load, latency-sensitive and real-time systems, GPU and AI work, high-traffic platforms, private clouds built on your own hypervisor, bare-metal Kubernetes, and regulated data that benefits from physical isolation. If that describes your workload, bare metal will serve it better than a shared, virtualized alternative.

It is not for variable, bursty, experimental, fast-scaling, or small workloads, where a VPS or the cloud fits better and costs less — and we will tell you so. Read this page as a test rather than a sales pitch: if your workload wants the hardware itself, talk to us about provisioning one properly; if it wants elasticity, we will point you at the model that fits. The honest answer is the service we are actually offering.