A newly provisioned dedicated server arrives reachable, unconfigured and unprotected. Automated scanning finds it within minutes. The first hour decides whether the rest of its life is uneventful.
Test remote management before you need it
This is the step people skip, and it is the one that matters most when something goes wrong.
Your server has an out-of-band management interface, IPMI, iDRAC or similar. That works independently of the operating system. It gives you console access, power control and the ability to mount installation media when the machine is otherwise unreachable.
Log into it now, while everything is working. Confirm you can see the console and cycle power. Save the credentials somewhere that does not depend on this server.
The alternative is discovering the interface does not work on the night you have locked yourself out of SSH, which is exactly when you cannot fix it.
Secure it before anything else
In this order, because each step depends on the previous one still working:
- Create a normal user with sudo.
- Set up SSH key authentication and test it in a second terminal while the first stays open.
- Disable password authentication and root login, then test again before closing the original session.
- Enable a firewall: allowing SSH first.
- Apply all pending updates and turn on automatic security updates.
Steps two and four are where people lock themselves out. With working remote management that is an inconvenience; without it, it is a support ticket and a wait.
Server hardening goes over what to do after these five.
Check the hardware is what you ordered
Five minutes, and it catches provisioning mistakes while they are still easy to raise.
Confirm the processor, the total memory, and the disks, count, size and type. Then confirm the RAID array is in the expected level and is healthy, not degraded or still building.
A server delivered with an array already rebuilding is not a fault, but you should know before you start loading data onto it.
Set up RAID monitoring immediately
An array with a failed disk keeps working. That is its purpose, and it means nothing tells you unless something is watching.
Servers are routinely found running degraded for months, one disk from total loss, because monitoring was never configured. Set up alerting now and verify it by reading the array status yourself once. Setting up RAID and storage deals with the levels and what a rebuild involves.
Record what you configured
Write down the management address and credentials, the disk layout, the partition scheme, and anything you changed from defaults.
Keep it somewhere that is not on this server. The moment you need these notes is the moment the server is unreachable, and notes stored on it are useless exactly then.
Then plan the rebuild you hope not to do
Before putting the server into service, know how you would rebuild it. Which distribution, which packages, which configuration files, and where the backups are.
A server you can rebuild in an afternoon from documentation and backups is a manageable risk. A server nobody knows how to reproduce is a single point of failure with a long recovery, and you find that out under pressure.
Backups and disaster recovery goes over making that real rather than theoretical.
Once the machine is secured, Installing and Managing Web Server Software deals with what to install and in what order.
Once there is more than one machine, keeping them alike is what makes any procedure predictable. There is more in How to Manage Multiple Servers Consistently.
Before anything moves onto it, a day of deliberate load is the cheapest insurance available. How to Test a New Server Before Putting It into Service sets out what to test and why.
Confirm the disks before you trust them
A new server arrives with disks whose history you do not know, and checking takes minutes at a point where nothing depends on them.
lsblk -o NAME,SIZE,MODEL,SERIAL,ROTA smartctl -a /dev/sda 2>/dev/null | grep -iE 'power_on_hours|reallocated|model|serial|health' for d in /dev/sd?; do printf '%-10s %s\n' "$d" "$(smartctl -H "$d" 2>/dev/null | tail -2 | head -1)"; done
The power on hours figure tells you whether the drive is new or has been in service. A large number on a machine sold as new is worth a question before you build on it.
Reallocated sector counts above zero on day one mean the drive has already had problems. That is not necessarily a fault and it is a reason to ask for a replacement now rather than after the machine is in production.
Measure it before it has any load
The only chance to know what the machine does when idle is before anything runs on it.
nproc; free -g | head -2
dd if=/dev/zero of=/tmp/test bs=1M count=2048 oflag=direct 2>&1 | tail -1; rm -f /tmp/test
curl -o /dev/null -w 'indirme %{speed_download} B/s\n' -s https://speed.hetzner.de/100MB.bin
Record the results. They are the baseline against which every later complaint about the machine being slow is judged, and they cannot be taken retrospectively.
Compare the disk figure against what was advertised. A machine sold with fast storage that measures like ordinary storage is a configuration matter worth raising in the first week rather than the sixth month.
Decide what happens when nobody is watching
The provisioning is the moment to arrange the automatic behaviour, because afterwards it is never anybody's task.
systemctl list-unit-files --state=enabled --no-pager | head -20 systemctl is-enabled sshd nginx mysql 2>/dev/null grep -rn 'GRUB_TIMEOUT\|GRUB_DEFAULT' /etc/default/grub 2>/dev/null
Confirm every service you need starts on boot, and reboot deliberately once to prove it. A machine that has run for a year without a restart has never demonstrated that it comes back.
Check that the boot does not stop and wait for input, since a prompt on a machine you reach only over the network is an outage that requires the console to clear. Using IPMI and out of band management covers reaching it.