Bare metal servers give you the raw performance and isolation that virtualized environments can't match. You control the hardware, kernel, and every service layer—no hypervisor tax, no noisy neighbors.
I've walked dozens of clients through their first bare metal deployments, and the process boils down to five repeatable steps: hardware prep, OS install, network configuration, security hardening, and monitoring. Get these right and you'll have a stable foundation for production workloads. Rush them and you'll troubleshoot phantom network drops or SSH lockouts at 2 a.m.
Step 1: Hardware selection and BIOS configuration
Start by confirming your server meets the workload requirements. CPU core count, RAM capacity, disk IOPS, and network interface speed all matter. For a typical web hosting node I recommend at least 32 GB RAM, hardware RAID or NVMe for database writes, and dual power supplies if uptime is critical.
Once the hardware arrives, connect via IPMI or iLO to access the BIOS. Check boot order first—set it to boot from your installation media, whether that's a mounted ISO over IPMI or a USB drive. Enable UEFI mode if you plan to use GPT partitions and systemd-boot. Disable unnecessary onboard devices like serial ports or floppy controllers to reduce attack surface.
Next verify RAID configuration in the hardware controller utility. RAID 1 mirrors protect against single-disk failure; RAID 10 gives you speed and redundancy if you have four drives. RAID 5 is common but rebuilds kill performance under load. I've seen RAID 5 arrays take 18 hours to rebuild a 4 TB drive while serving production traffic—not fun.
Enable hardware virtualization extensions (VT-x, AMD-V) if you'll run KVM or Docker later. Set a strong BIOS password and record it in your password manager. Save and reboot.
Step 2: Operating system installation
Mount your OS ISO via the remote console. For hosting workloads I lean toward Ubuntu LTS, Rocky Linux, or Debian stable—each offers five-plus years of security updates and a mature package ecosystem.
Boot into the installer and choose manual partitioning. Create a 512 MB EFI partition, a root partition of at least 50 GB, and dedicate the rest to /var or /home depending on where your app data lives. Separate partitions let you mount with restrictive options later—/var can be nodev,nosuid to limit privilege escalation paths.
Set a strong root password during install but plan to disable root SSH login immediately after. Create a non-root user with sudo privileges. This user will be your daily driver.
Select minimal package sets. Skip GUI environments and office tools. You want sshd, a bootloader, and basic network utilities. Everything else gets installed deliberately in the next steps.
After the installer finishes, eject the media and reboot. Log in via IPMI console to confirm the system comes up cleanly.
Step 3: Network configuration and IP assignment
Your datacenter or colocation provider will give you at least one public IPv4 address, a gateway, and DNS resolvers. You'll configure these statically because DHCP leases are unreliable for production servers.
On modern Ubuntu or Debian systems, network config lives in /etc/netplan/. Edit the YAML file and set your primary interface (usually eno1 or eth0) with the assigned IP, netmask, gateway, and nameservers. Here's a typical example:
network:
version: 2
ethernets:
eno1:
addresses:
- 203.0.113.10/24
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses:
- 1.1.1.1
- 1.0.0.1
Apply the config:
sudo netplan apply
Test connectivity with ping 1.1.1.1 and ping google.com. If ping to the IP works but DNS fails, double-check your nameserver entries.
For multi-homed servers (two NICs, two upstream providers), you'll need policy-based routing and separate routing tables, but that's beyond a basic setup.
Configure the firewall before you disconnect from IPMI. On Ubuntu use ufw:
sudo ufw allow 22/tcp
sudo ufw enable
On Rocky or CentOS use firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
Now SSH in from your workstation using the non-root user you created. If it works, you can close the IPMI console.
Step 4: Security hardening
Out of the box, your server allows password authentication and root login over SSH. Both are liabilities.
First, generate an SSH key pair on your local machine if you don't have one:
ssh-keygen -t ed25519 -C "[email protected]"
Copy the public key to your server:
ssh-copy-id [email protected]
Verify key-based login works, then edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Restart sshd:
sudo systemctl restart sshd
Test SSH again in a new terminal before closing your existing session. If you lock yourself out, you'll need IPMI to recover.
Next install fail2ban to block brute-force attempts:
sudo apt install fail2ban # Debian/Ubuntu
sudo dnf install fail2ban # Rocky/CentOS
The default SSH jail is usually enabled automatically. Check the status:
sudo fail2ban-client status sshd
Enable automatic security updates. On Debian/Ubuntu:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
On Rocky:
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
Disable unused services. List running services with systemctl list-units --type=service --state=running and stop anything you don't recognize. In support tickets I handled, the usual culprit was a full disk from log files generated by a forgotten service.
Step 5: Monitoring and backups
A server without monitoring is a server you'll discover is down when a customer emails you. Install basic observability tools first.
For system metrics I use Netdata because it's lightweight and self-contained:
bash <(curl -Ss https://get.netdata.cloud/kickstart.sh)
Netdata listens on port 19999 by default. Access it via SSH tunnel:
ssh -L 19999:localhost:19999 [email protected]
Then open http://localhost:19999 in your browser. You'll see CPU, RAM, disk I/O, and network graphs in real time.
For alerting, configure Netdata to send notifications or integrate an external monitoring service like UptimeRobot to ping your server every five minutes.
Set up log aggregation next. Forward logs to a centralized syslog server or use journald's persistent storage:
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
Finally, automate backups. Use rsync over SSH to a remote backup server or object storage. Here's a daily cron job that backs up /var/www and /etc:
0 2 * * * rsync -avz --delete /var/www/ backup-server:/backups/web/
0 2 * * * rsync -avz --delete /etc/ backup-server:/backups/etc/
Test restoration from backup at least once. A backup you've never restored is just a file that makes you feel better.
What about IPMI security?
IPMI interfaces run separate firmware and often ship with default credentials or known vulnerabilities. Change the default password immediately. Place IPMI on a dedicated management VLAN or restrict access by IP if your datacenter supports it. Never expose IPMI directly to the public internet—too many older BMC implementations have hardcoded backdoors or weak authentication.
If your provider offers IP-based IPMI access control, whitelist only your office or VPN IP. For colocation setups, consider a jump host within the datacenter network as the only allowed IPMI client.
Choosing between RAID levels
RAID 1 mirrors two drives and survives one failure. It's simple and fast for read-heavy workloads but gives you only half your raw capacity. RAID 10 stripes mirrored pairs—you get speed and redundancy but need at least four drives.
RAID 5 stripes data with parity across three or more drives. You lose one drive's capacity to parity but gain more usable space than RAID 1. The catch: rebuild times are brutal and a second drive failure during rebuild destroys the array. For production hosting I avoid RAID 5 unless write performance isn't critical.
RAID 6 adds a second parity block, so you can lose two drives safely. Rebuild times are even worse but the extra safety margin matters for large arrays with slow mechanical drives.
For NVMe-based setups, software RAID with mdadm often outperforms hardware RAID because modern controllers weren't designed for NVMe speeds. Benchmark your specific hardware before committing.
Do I need a control panel?
If you're hosting a single application and comfortable with the command line, no. Manage services, users, and firewall rules directly. Control panels like cPanel or Plesk add convenience—web-based account provisioning, automated SSL via Let's Encrypt, email server config—but they also add overhead, licensing cost, and another layer to troubleshoot.
For shared hosting or reseller environments, a control panel makes sense because you'll onboard customers who expect a GUI. For a dedicated app server or API backend, skip it and invest the time learning systemd, nginx config, and proper backup scripting.
Frequently asked questions
How long does a typical bare metal setup take?
Hardware configuration and OS install take 30 to 60 minutes. Network setup and security hardening add another hour. Monitoring and backups depend on your tooling. Budget half a day for your first deployment; you'll cut that to two hours once the process is muscle memory.
Can I automate bare metal provisioning?
Yes. Tools like Foreman, MaaS, and Tinkerbell handle PXE boot, automated OS install, and post-install config via Ansible or Puppet. For a single server it's overkill, but if you're provisioning ten servers a month, automation pays off quickly.
What's the difference between bare metal and a VPS?
A VPS shares physical hardware with other tenants via a hypervisor. You get flexibility and lower cost but also noisy neighbor problems and a performance ceiling. Bare metal gives you the entire machine—predictable performance, direct hardware access, and no virtualization overhead. You pay more and lose the ability to spin up instances in 30 seconds.
How do I know if I need bare metal instead of cloud instances?
If you have steady workloads (database servers, build systems, high-traffic web apps), bare metal is cheaper and faster over time. If your workload is spiky or you need to scale horizontally every few hours, cloud instances make more sense. I've run cost comparisons for clients—bare metal breaks even around month three if utilization stays above 60 percent.
Should I enable SELinux or AppArmor?
Yes, if you're comfortable with the learning curve. SELinux (Rocky, CentOS) and AppArmor (Debian, Ubuntu) provide mandatory access controls that limit damage from compromised services. They ship in permissive or enforcing mode. Start in permissive, read the audit logs, then switch to enforcing once you've resolved policy violations. I've seen both stop privilege escalation attacks that would have owned the box otherwise.
Do I need redundant network interfaces?
For production environments, yes. Bond two NICs in active-backup or LACP mode so a single NIC or switch failure doesn't take the server offline. Your datacenter switch config has to support it. For dev or staging boxes, a single NIC is fine.
What to verify before going live
Before you point DNS at your new server or migrate production traffic, walk through this checklist: SSH key authentication works and password auth is off. Firewall rules allow only required ports. Automatic updates are enabled and tested. Backups run daily and you've restored a test file. Monitoring alerts reach your phone or email. IPMI is password-protected and firewalled.
Boot the server and let it run for 24 hours. Check for kernel panics, disk errors in dmesg, or memory issues in journalctl. Performance problems that show up under synthetic load will show up worse under production traffic.
Once you're confident, migrate one low-risk service first. Monitor it for a week. If it's stable, move the rest. Bare metal hosting is reliable when you respect the fundamentals.