Ubuntu Server First Steps After Install

A fresh Ubuntu server is usable, but not ready. The gap between “installed” and “safe to expose” is where most avoidable problems start.

If your goal is a stable VPS, app node, or web server, the first hour matters more than the distro choice. These are the Ubuntu server first steps after install that reduce risk, cut noise later, and give you a clean base for production.

Start with updates and a reboot plan

First, log in and update the package index and installed packages:

sudo apt update && sudo apt upgrade -y sudo apt autoremove -y 

If the kernel or core libraries changed, schedule a reboot. On a brand-new server, rebooting early is better than forgetting and carrying pending updates into deployment.

You should also confirm the OS version and hostname so inventory stays clean:

lsb_release -a hostnamectl 

If the hostname is generic, change it now. It saves time later when logs, SSH prompts, and monitoring all start to look the same.

Create a non-root user and lock down SSH

Running everything as root is fast for five minutes and expensive after that. Create a sudo user:

adduser deploy usermod -aG sudo deploy 

Then add your SSH key to that user:

mkdir -p /home/deploy/.ssh nano /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Before changing SSH settings, open a second session and confirm the new user can log in. Only then edit `/etc/ssh/sshd_config`.

In most cases, disable password authentication and root SSH login:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Then reload SSH:

systemctl reload ssh

Changing the SSH port is optional. It reduces low-value bot noise, but it is not a real security control by itself. Key-based auth and disabled root login matter more.

Configure the firewall early

If UFW is available, use it unless you already manage firewall policy elsewhere.

Allow SSH first, then enable the firewall:

sudo ufw allow OpenSSH
sudo ufw enable sudo ufw status

If this server will run a web stack, allow only what is needed, usually `80/tcp` and `443/tcp`. Avoid opening database ports to the public internet unless there is a clear reason and access restriction.

This is also the point where hosting context matters. If you are deploying on a VPS, network controls at the provider layer can complement UFW. If you are still selecting infrastructure, best VPS hosting for developers is worth reviewing alongside your server hardening checklist.

Check time sync, swap, and basic health

Bad time causes bad logs, failed tokens, and broken automation. Verify time sync:

timedatectl

Ubuntu usually enables `systemd-timesyncd` by default. Confirm NTP is active. If your workload is sensitive to time drift, this is not optional.

Next, check memory and disk so you know what you actually installed:

free -h 
df -h 
lsblk 

If the server is very small and has no swap, consider adding a swap file. That is not a substitute for enough RAM, but it can prevent abrupt failures during package installs, updates, or short spikes.

Install only the services you need

Do not preload a full stack “just in case.” Every package increases update surface, service sprawl, and troubleshooting time.

For example, if the server is for a reverse proxy, install only Nginx and supporting tools. If it is for containers, install Docker or your runtime, then stop. If it is for application hosting, decide whether you want system packages, containers, or a control panel before layering tools together.

If you prefer panel-driven management, review what is a web hosting control panel? before committing to a manual stack. Mixing both approaches later often creates avoidable drift.

Set up basic intrusion protection and logging

For internet-facing SSH, Fail2ban is still useful:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

The default SSH jail is often enough to start. You can tune bantime and retry limits later.

Also check logs now, while the system is quiet:

journalctl -p 3 -xb
systemctl --failed

A clean baseline makes future problems easier to spot. If something is failing on day one, fix it before adding workloads.

Prepare backups before deployment

Backups should exist before the first live change, not after the first mistake. At minimum, decide what needs protection: configs, app data, databases, and uploaded files. Then decide where backups go and how restore testing will happen.

Snapshots are useful for fast rollback, but they are not the same as application-aware backups. If this server will host a production site or store business data, use both where possible.

If you are migrating onto the server, build backup and rollback into the move itself. Zero downtime site migration playbook covers the operational side that people usually postpone until traffic is already flowing.

Final checks before going live

At this stage, verify four things: you can log in as a sudo user with SSH keys, root SSH is disabled, only required ports are open, and the server is fully updated. Then capture the state – hostname, IPs, open ports, installed services, and backup method – in your own notes.

That last step sounds minor. It is not. Good server administration is mostly controlled repetition.

A clean Ubuntu install becomes reliable when the first changes are deliberate. Keep the base small, secure access first, and add services only when the role is clear.