Virtual machines are the right answer for a lot of workloads. They are not the right answer for all of them. When you need exclusive access to CPU topology, NVMe devices without a virtualization layer in the path, or a single-tenant environment where you own every kernel parameter, bare metal server setup is the only option that delivers. This checklist covers the five phases that matter: BIOS hardening, network bonding, OS provisioning, storage layout, and pre-production validation. Work through them in order and you will not spend your first production incident tracing a problem you introduced at rack time.
Phase 1: BIOS and UEFI hardening
Firmware sits below every defense most teams actually monitor. If an attacker reaches it, they can bypass OS-level controls entirely, which is why BIOS hardening is the first item on any serious bare metal deployment checklist, not an afterthought. NIST Special Publication 800-147B covers server BIOS protection guidelines and is the authoritative reference for this layer.
The practical controls to enforce before the OS even installs: lock firmware setup behind role-based access so that physical access to the console does not mean unrestricted access to boot policy; restrict or disable network boot (PXE) on interfaces you are not actively using for provisioning; require authenticated firmware updates so that a routine patch cannot be silently replaced; and enable TPM 2.0 with Secure Boot so that only authenticated firmware and OS components load at startup. On Linux, mokutil --sb-state and efivar -l confirm whether Secure Boot is actually enforced rather than just configured.
A word on Secure Boot vulnerabilities: BootHole, BlackLotus, and PKFail all demonstrated that Secure Boot misconfiguration, reused platform keys, and permissive boot policies create real exposure. Enabling the feature is not sufficient; verify the key hierarchy and confirm that your bootloader is not in any known revocation list.
Firmware drift is an underappreciated operational risk. Two nodes with identical CPUs and memory can behave differently if their UEFI settings diverge, affecting performance, boot time, and recovery from failure. Capture your validated BIOS configuration as a baseline immediately after hardening, before you provision the OS. Every subsequent node in the same role should match it exactly.
Phase 2: Network bonding
The Linux kernel bonding driver offers seven modes (Mode 0 through Mode 6). For production dedicated server provisioning, the decision almost always comes down to two: active-backup (Mode 1) or 802.3ad LACP (Mode 4).
Use Mode 1 when you need failover only and cannot or do not want to configure the upstream switch. One interface is active; the other waits. Simple, reliable, no switch involvement required. Use Mode 4 when your switch supports LACP and you want both redundancy and aggregated throughput. Mode 4 uses the IEEE 802.3ad dynamic link aggregation standard, provides fault tolerance, and requires that the switch port be configured as an LACP port group. For production servers on a managed switch, Mode 4 is the right default.
Choosing the wrong bonding mode at provisioning time is one of those mistakes that does not surface until a link goes down in production. Get it right at rack time.
Whatever mode you choose, verify that both physical interfaces show the expected state before you continue. On RHEL and its derivatives, cat /proc/net/bonding/bond0 shows the active slave, link status, and MII polling interval. If you are using Mode 4, confirm that the LACP negotiation succeeded on the switch side before moving on.
Phase 3: OS provisioning
Bare metal OS provisioning is where teams most often import technical debt from their VM habits. A few things to get right from the start.
Use a minimal base image and add only what the workload requires. A database node and a Kubernetes worker node do not need the same package set; resist the temptation to start from a general-purpose image and trim later. Configure your package manager to pull from a controlled internal mirror so that you have a reproducible, auditable software bill of materials from day one.
Set your hostname, DNS resolvers, NTP sources, and SSH authorized keys through your provisioning toolchain (cloud-init, Kickstart, or Ignition depending on your stack) rather than interactively. Interactive configuration does not reproduce. Use chronyc tracking to confirm NTP synchronization before you declare the node provisioned; time skew causes subtle failures in distributed systems that are genuinely difficult to diagnose after the fact.
Disable root login over SSH. Use key-based authentication only. If your provisioning system requires password authentication to bootstrap, rotate those credentials immediately after the first successful automated run.
Phase 4: Storage layout
Physical server configuration guide advice on storage tends to be generic. Here is what actually matters for production bare metal.
Separate your OS disk from your data disk. This is not just about capacity; it is about recovery. If the OS disk fails or needs reimaging, your data survives. If you are using NVMe, check whether your workload benefits from namespace isolation or whether a single namespace with a partition scheme is sufficient.
For RAID, decide at provisioning time whether you want software RAID (mdadm) or hardware RAID, and document which you chose. Mixing them or changing later is painful. For most workloads that do not require specific RAID controller features, software RAID under mdadm gives you better observability and portability. Use mdadm --detail /dev/md0 to verify array state after provisioning and before the node enters rotation.
Filesystem choice matters for the workload. XFS is the default on RHEL-family distributions and handles large files and high concurrency well. ext4 is simpler and adequate for most general workloads. Avoid making this decision based on familiarity alone; match it to the I/O pattern the workload will produce.
At AMS1, where we run bare metal nodes behind AMS-IX dense peering, storage layout decisions intersect directly with network I/O patterns for latency-sensitive workloads serving Western European markets. Getting the filesystem and queue depth right at provisioning time avoids a class of performance problems that are difficult to correct under load.
Phase 5: Pre-production validation
A bare metal production readiness check is not a formality. It is the gate between a provisioned node and a node you can actually trust under load.
Run a memory test before the node enters production. Tools like memtest86+ or the kernel’s built-in memory test surface hardware defects that will otherwise manifest as intermittent application errors. This takes time; schedule it into your provisioning workflow rather than skipping it because the timeline is tight.
Stress the CPU and storage subsystems under synthetic load before real workloads arrive. stress-ng covers CPU, memory, and I/O. fio gives you detailed storage benchmarks with configurable I/O patterns. Establish a baseline for the hardware configuration and keep it; when a node in the same role starts behaving differently, you will want that baseline to compare against.
Validate your monitoring agent, log shipper, and alerting paths are all functioning before the node is handed off. A node that is not being observed is not production-ready regardless of how well provisioned it is. Confirm that your IPMI or out-of-band management interface is reachable and authenticated independently of the OS; if the OS stops responding, that interface is how you recover without a physical visit to the rack.
Run through your runbook for a graceful shutdown and cold restart. Verify that the node comes back with the expected configuration, that bonding re-establishes correctly, and that your monitoring picks up the return. Do this before the first real workload, not after.
Keeping the checklist alive
A bare metal deployment checklist is only useful if it reflects what you actually do. Treat it as a living document: when a provisioning step causes a problem in production, add a validation step that would have caught it. When a new BIOS vulnerability changes your hardening baseline, update the firmware section. The gap between the checklist you wrote at launch and the infrastructure you are actually running is where the interesting failures live.
