How to Install Ubuntu Server: Initial Server Setup Steps

How do you install Ubuntu Server and what does the process involve?

To install Ubuntu Server, you download the official ISO from ubuntu.com, verify its signature and checksum, and run the text-based installer to set language, network, storage, user profile and OpenSSH. After the first login, you harden the system with updates, SSH keys, UFW and automatic security updates.

We are Talha Aslan and team, a digital marketing and web team, not a hosting company. That is why every command in this guide comes from Canonical's official Ubuntu documentation rather than from claims about servers we run. We also avoid version numbers on purpose. Pick the current LTS release when you start, and check the release cycle page for support dates.

The work splits into three phases:

• Preparation: download the ISO, verify the signature and SHA256 checksum, and prepare a bootable USB drive or virtual machine.
• Installer: choose language, keyboard, network, storage layout, user profile and the OpenSSH server option.
• First configuration: apply updates, set up a sudo user and SSH keys, enable the firewall, then check time sync, hostname, swap and Fail2ban.

We explain the reason behind each step as well. If you know why a command matters, you can make the right call on a different provider or a newer release. First-timers should read from top to bottom. If you have done it before, jump straight to the checklist near the end.

What do you need before you install Ubuntu Server?

Ubuntu's basic installation tutorial recommends at least 2 GB of RAM and 5 GB of disk space. Supported architectures are amd64, arm64, ppc64el and s390x. However, those numbers cover the operating system only. Once you add a web server, a database and a cache, your resource needs grow quickly.

For a physical machine, you write the ISO to a USB drive. For a virtual machine, you attach the ISO to the virtual optical drive. On a rented VPS, on the other hand, you usually skip this phase entirely; we cover that case in its own section below.

Before you start, write down the following:

• The hostname you want and your admin username.
• Network details: DHCP, or a static IP with gateway and DNS servers.
• The public SSH key from the computer you will connect from.
• A strong password. Our password generator can help with that.

Not sure which kind of server to rent? Read our comparison of VPS, VDS and cloud servers first. That way you install on the right platform from day one.

How do you download and verify the Ubuntu Server ISO?

Download the ISO only from ubuntu.com or releases.ubuntu.com. Then save the SHA256SUMS and SHA256SUMS.gpg files into the same folder. Verification answers two questions. Did the download arrive intact? And did Ubuntu really sign it?

First, check the signature:

gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

If GPG reports a missing key, the official tutorial shows how to fetch the keys from keyserver.ubuntu.com and compare fingerprints. Once the signature checks out, verify the checksum:

sha256sum -c SHA256SUMS 2>&1 | grep OK

You should see your ISO file name followed by OK. If you do not, delete the file and download it again. The full walkthrough lives in Ubuntu's official verification tutorial.

Skipping this step is tempting. Still, an ISO from a broken mirror or a half-finished download causes confusing errors halfway through the installer. A tampered image is worse, because it puts the lowest layer of your server at risk. In short, five minutes of checking can save hours of debugging.

Which language, keyboard and network options should you choose?

When you boot from the USB drive or virtual drive, the text-based installer appears. The first screen asks for a language. Many admins pick English on servers, because error messages are easier to search for. That said, it is purely a preference.

If a newer installer build is available, the installer may offer to update itself. With a working internet connection, accepting the update makes sense. Next, choose your keyboard layout carefully. A wrong layout means your password characters will not match later.

The following screen asks for the installation type. The standard Ubuntu Server option suits most use cases. On the network screen, the installer tries DHCP first. For a static IP, select the interface and enter the IPv4 settings by hand. For example, with addresses from the documentation range:

• Address: 192.0.2.10/24
• Gateway: 192.0.2.1
• DNS servers: the values your provider gives you

Leave the proxy field empty unless you sit behind a corporate proxy. On the mirror screen, the installer suggests an archive address. We explain how mirror choice affects download speed in our Linux package mirror guide.

Which storage option should you pick in the installer?

The guided storage screen suggests using the entire disk by default. On a single-disk machine that will only run Ubuntu, this is usually the right starting point. The same screen also offers to set up the disk as an LVM group.

LVM makes it easier to grow logical volumes and take snapshots later. So if you are unsure, we suggest leaving LVM on. Disk encryption with LUKS, by contrast, protects against physical access. However, it asks for a passphrase at every boot, so a remote server then needs out-of-band console access.

Custom partitioning only makes sense with a clear reason. For instance, you might want database files on a separate disk. With several disks, you will also see software RAID options; our RAID levels guide compares them.

Finally, read the summary screen with care. Once you confirm, the installer wipes the selected disk. Therefore, double-check disk sizes and model names, especially on machines with more than one drive.

When the installation finishes, the installer asks you to remove the install medium and reboot. If you forget the USB drive, the machine may boot straight back into the installer. On a virtual machine, simply detach the ISO.

What matters on the profile and OpenSSH screens?

On the profile screen, you enter your name, the server name, a username and a password. The user you create here gets sudo rights. Ubuntu keeps the root password locked by default, so you handle admin work through this user and sudo.

Choose a short, descriptive server name such as web01. Avoid easy-to-guess usernames like admin or test. Also pick a long password that you do not reuse anywhere else.

The installer may then show an Ubuntu Pro screen. You can skip it for now and revisit it after setup. The screen that really matters is the SSH screen. Tick Install OpenSSH server. Otherwise you cannot reach the machine remotely and will have to go back to the console.

The same screen lets you import your public key from GitHub or Launchpad. If your key already lives on one of those accounts, this option saves time. In that case, you can also consider turning off password login for SSH right away. On the snaps screen that follows, select only the packages you actually need. You can install everything else later with apt or snap.

Do you need to install Ubuntu Server yourself on a VPS?

In most cases, no. VPS providers usually offer a ready-made Ubuntu image. You pick the release, the provider boots the server within minutes, and you receive an IP address plus login details. As a result, you never see ISO verification, partitioning or the installer screens.

This convenience has side effects. For example, some images allow root login with a password, while others accept SSH keys only. Disk layout, swap and network settings also depend on the provider. So do not assume anything on first login; check everything.

To be honest, if you use a VPS, you can skip the installer part of this guide and go straight to first configuration. The preparation and installer sections are for physical servers, home labs and virtual machines. The update, SSH, firewall and automatic update steps, however, matter just as much in both scenarios.

We list what to look for in a provider in our guide to choosing web hosting. Console access, snapshots and backups are the features that rescue you when a configuration step goes wrong.

How do you update packages after the first login?

Once the server is up, connect over SSH from your computer. Replace the sample address with your own server address:

ssh deploy@192.0.2.10

Your first job is to refresh the package lists and install pending updates:

sudo apt update
sudo apt upgrade

This pulls in every security fix released since the install media came out. Finish it before you install any service. If the kernel or core libraries changed, the system will want a reboot.

To find out whether a reboot is pending, check for this file:

ls /var/run/reboot-required

If it exists, reboot at a convenient time. Also run autoremove now and then to clear out dependencies you no longer need. These steps look trivial. Yet an outdated server stays exposed to known vulnerabilities, no matter how carefully you configured everything else.

How do you create a sudo user and restrict root login?

If you used the installer, you already have a sudo user. If you logged in to a VPS image as root, create a separate user first:

adduser deploy
usermod -aG sudo deploy

Open a new terminal, log in as that user, and test a sudo command. Only after that test succeeds should you restrict root login. Otherwise you might close your only way in.

Ubuntu's OpenSSH configuration contains an Include line at the top of the main file. Because of it, sshd reads every file in the sshd_config.d directory. Writing your settings to a separate file is therefore cleaner than editing the main file:

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

Add the line PermitRootLogin no. Then save and test the configuration:

sudo sshd -t

If the test returns no errors, restart the service. The official docs use systemctl restart ssh.service for this. Keep your current session open and try a fresh login from a second window. If something breaks, you can still fix it from the open session.

How do you set up SSH key authentication?

Password-based SSH stays open to brute-force attempts. Key-based login largely removes that risk. First, generate a key pair on your own computer:

ssh-keygen -t ed25519

We recommend protecting the key with a passphrase. Next, copy the public key to the server:

ssh-copy-id deploy@192.0.2.10

The official docs also remind you that group and others must not have write access to the authorized_keys file. After copying, confirm that you can log in with the key.

Once key login works, you can turn off password login. Add PasswordAuthentication no to the hardening file you created earlier. Cloud images sometimes ship extra files in sshd_config.d. If one of them sets the same option to a different value, the result may surprise you. Read every file in that directory, then run sshd -t again.

For details, see the Ubuntu OpenSSH server documentation. For extra changes such as a new SSH port, follow the current official docs closely, because recent releases handle the SSH service differently.

If you connect from several computers, create a separate key for each one. Then, if you lose a laptop, you remove only that key from authorized_keys and keep the others. Never place a private key on the server, in an email or in a shared folder.

How do you enable UFW without locking yourself out?

According to Ubuntu's firewall documentation, UFW starts out disabled. The most common mistake is enabling it before allowing SSH. Your session can then drop, and the provider's web console becomes your only way back in.

Here is the safe order. First, list the registered application profiles:

sudo ufw app list

Then allow the SSH profile:

sudo ufw allow OpenSSH

Only after that rule exists should you enable the firewall and check its status:

sudo ufw enable
sudo ufw status verbose

A web server also needs HTTP and HTTPS rules. For instance, Nginx and Apache add their own UFW profiles, which then show up in the app list output. The Ubuntu firewall documentation explains these commands.

To review existing rules, ufw status numbered shows them with numbers, which makes deleting a stale rule easy. If you use IPv6, also confirm that rules exist for both protocols. Our IPv6 test tool shows whether your connection uses IPv6. On cPanel servers, many admins prefer CSF over UFW; see our CSF firewall guide.

How do you set the time zone and NTP sync?

Server time drives the accuracy of logs, certificate checks and cron jobs. Even a drift of a few minutes can break TLS handshakes or two-factor codes.

To see the current state, run:

timedatectl

The output shows your time zone and whether the system clock is synchronized. To change the zone, use timedatectl set-timezone with a value such as Europe/London. First, find the exact name with timedatectl list-timezones.

Some teams keep every server on UTC instead. That makes it easier to compare logs from machines in different regions. If you manage several servers, consider that approach as well.

We cover how NTP works, which time sources to use and how to troubleshoot sync problems in our NTP time sync guide. We will not repeat it here. For now, just confirm that synchronization is active.

How do you manage automatic security updates?

The Ubuntu Server docs state that Ubuntu applies security updates automatically through the unattended-upgrades package, which comes installed by default. Still, checking its status on a provider image is a good habit.

If the package is missing, install it:

sudo apt install unattended-upgrades

Two files control its behavior:

• /etc/apt/apt.conf.d/20auto-upgrades: turns automatic updates on or off and sets how often they run.
• /etc/apt/apt.conf.d/50unattended-upgrades: defines allowed sources, the package blocklist and reboot behavior.

Automatic reboot is off by default. If you turn it on, the server restarts by itself after kernel updates. So it makes sense to set a reboot time during low-traffic hours. To preview the effect of your changes, run a dry run:

sudo unattended-upgrade -v --dry-run

You will find the logs in the /var/log/unattended-upgrades directory. The Ubuntu automatic updates page has the full option list.

How do you check the hostname and swap?

To change the server name later, use hostnamectl:

sudo hostnamectl set-hostname web01

Then update the old name in /etc/hosts too. Otherwise sudo may print name resolution warnings. If the hostname will map to a domain, verify the DNS record with our DNS lookup tool.

Swap is disk space that acts as overflow when memory runs out. Depending on the install type and the provider image, your server may or may not have swap. To check, run:

swapon --show
free -h

If the first command prints nothing, no swap is active. On small-memory servers, that can lead to processes being killed during memory spikes. We cover creating a swap file and choosing its size in a separate swap and SSH hardening article in this series. Here, a quick check is enough.

Should you install Fail2ban?

Every server with SSH open to the internet receives automated login attempts. With password login turned off, those attempts mostly fail. However, they still flood your logs. They also remain a risk for other services, such as a web panel or a mail server.

Fail2ban watches log files and temporarily bans an IP address after a set number of failed attempts. That makes it a valuable extra layer, especially for services where you cannot turn off passwords entirely.

We walk through installation, jail configuration and working alongside UFW in our Fail2ban setup guide, so we will not repeat it here.

One warning: add your own static IP to the ignore list so you never ban yourself. Also keep in mind that Fail2ban does not replace the firewall. The two work together.

How do the ways to install Ubuntu Server compare?

You can reach the same result by different routes. The table below summarizes three common scenarios in terms of responsibility and control:

The key row is initial hardening. Whichever route you take, updates, SSH and firewall setup stay your responsibility. Unless you pay for a managed service, the provider will not do them for you.

Which services should you add after you install Ubuntu Server?

Once the basic security steps are done, the server is ready for its real job. Which services you add depends on its role. A website typically needs a web server, an application runtime and a database.

One principle matters here: install only what you need. Every new package is another component to patch and another possible attack surface. Writing your install list in advance is far easier than cleaning up later.

We have separate guides for common setups:

• For a database, see installing MySQL on Ubuntu and tuning performance.
• For a Next.js app, see deploying to a VPS with PM2, Nginx and SSL.
• For containers, start with our Docker guide.

After each new service, review your UFW rules. For example, if the database only serves an app on the same machine, there is no need to expose its port. That keeps the attack surface small.

How do you monitor server health after setup?

Installation happens once, but maintenance never stops. You do not need heavy monitoring software for routine checks. A few built-in commands already give you a solid picture.

Use df -h for disk usage and free -h for memory. To list failed services, run:

systemctl --failed

You can also read system logs with journalctl. For instance, add -u ssh to see recent entries for the SSH service. That way you spot failed logins and configuration errors quickly.

Turn these checks into a weekly habit. When a disk fills up, the database cannot write, logs disappear and the site throws odd errors. If your site slows down, our article on server-side causes of a slow website covers the usual suspects.

When should you leave server setup to your hosting provider?

Not every business needs to run its own server. For a company website or a small online store, managed hosting or shared hosting is often the safer choice. Experienced staff then handle updates, backups and firewall rules for you.

We suggest leaving setup and maintenance to a provider in these cases:

• Nobody on your team is comfortable with the Linux command line.
• Nobody has the time to monitor the server and follow updates.
• You handle personal or payment data and have compliance duties.
• You run a store where every outage turns directly into lost revenue.

Ask yourself one honest question: who will respond when something breaks at midnight? If the answer is unclear, a managed option is probably wiser. On the other hand, a test server is the best way to learn without risking a live system.

If you build software, ship apps with Docker or need a custom stack, your own VPS gives you flexibility. We like to discuss this decision openly during web projects. Our web design service also covers which platform your site should run on.

What should you check after you install Ubuntu Server?

When setup is complete, go through this list in order. Each item maps to a step in this guide:

1. You verified the ISO signature and SHA256 checksum (ISO installs only).
2. You ran apt update and apt upgrade and rebooted if needed.
3. A non-root sudo user exists, and you tested it.
4. SSH key login works; password login and root login are off.
5. sshd -t returns no errors.
6. UFW is active, SSH is allowed, and no unneeded port is open.
7. The time zone is right and clock sync is active.
8. unattended-upgrades runs, and its logs appear regularly.
9. Hostname and /etc/hosts match.
10. You checked the swap status.
11. Fail2ban runs if needed, with your own IP on the ignore list.
12. A backup plan exists.

People often forget that last item. No matter how well you configure a server, a single mistake can wipe data without a backup. Our website backup strategy guide covers frequency and storage location.

What are the most common first setup mistakes?

The biggest risk, which the official docs also stress, is locking yourself out. The OpenSSH documentation warns that if SSH is your only way in, a bad sshd setting can leave you unable to reconnect.

Here are the mistakes we see discussed most often:

• Enabling UFW before allowing SSH.
• Turning off password login before testing key login.
• Restarting sshd without running sshd -t first.
• Closing your current session before testing the new setting.
• Postponing updates and never rebooting for months.
• Leaving unneeded services and ports open.

The shared fix is simple: test every change from a second session. Also find out in advance how to reach your provider's web console. Then, even in the worst case, you still have a way in.

If the server will host a public site, set up HTTPS properly as well. Our SSL certificate guide explains the certificate types.