Ubuntu 24.04 LTS (Noble Numbat) is the most popular Linux distribution for cloud servers — and for good reason. Long-term support until 2029, a massive package ecosystem, and a community that has produced documentation for virtually every use case imaginable. If you're launching your first VPS or your fiftieth, Ubuntu 24.04 is the safe, sensible default.

But spinning up a VPS and actually setting it up properly are two different things. A fresh Ubuntu server is a blank canvas — it needs user accounts, firewall rules, timezone configuration, and security hardening before it's ready for production workloads. Skip these steps and you're building on a shaky foundation.

This guide walks you through every step of configuring a brand-new Ubuntu 24.04 VPS from your very first SSH connection to a fully updated, firewall-protected server ready for whatever you want to deploy. Whether that's a web server, a Docker host, a development environment, or a database backend — this is where you start.

MassiveGRID Ubuntu VPS includes: Ubuntu 24.04 LTS pre-installed · Proxmox HA cluster with automatic failover · Ceph 3x replicated NVMe storage · Independent CPU/RAM/storage scaling · 12 Tbps DDoS protection · 4 global datacenter locations · 100% uptime SLA · 24/7 human support rated 9.5/10

Deploy a self-managed VPS — from $1.99/mo
Need dedicated resources? — from $8.30/mo
Want fully managed hosting? — we handle everything

Prerequisites: What You Need Before Starting

Before you begin, you'll need:

Why Ubuntu 24.04 LTS Specifically?

Ubuntu releases come in two flavors: regular releases (supported for 9 months) and LTS releases (supported for 5 years, with extended security maintenance available for 10 years). For a server, you always want LTS. Ubuntu 24.04 LTS ships with:

The LTS designation means you'll receive security patches until April 2029 without needing to upgrade your OS version — critical for production servers where stability matters more than bleeding-edge features.

Step 1: Connecting via SSH for the First Time

SSH (Secure Shell) is how you'll interact with your server. It provides an encrypted connection between your local machine and the VPS. The connection method differs slightly depending on your operating system.

From macOS or Linux

Your operating system includes a built-in SSH client. Open your terminal (Terminal.app on macOS, or any terminal emulator on Linux) and run:

ssh root@YOUR_SERVER_IP

Replace YOUR_SERVER_IP with the actual IPv4 address of your VPS. For example:

ssh root@203.0.113.42

On your first connection, you'll see a fingerprint verification prompt:

The authenticity of host '203.0.113.42 (203.0.113.42)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other name.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes and press Enter. This adds the server's key to your ~/.ssh/known_hosts file so future connections are verified automatically. Then enter your root password when prompted.

From Windows

Windows 10 and 11 include OpenSSH as a built-in optional feature. Open PowerShell or Windows Terminal and use the same command:

ssh root@YOUR_SERVER_IP

If ssh isn't recognized, you can install OpenSSH via Settings > Apps > Optional Features > Add a feature > OpenSSH Client. Alternatively, use PuTTY — enter your server IP in the "Host Name" field, ensure port 22 is selected, and click "Open."

Using an SSH Key Instead of a Password

If you configured an SSH key during VPS provisioning (recommended), specify it with the -i flag:

ssh -i ~/.ssh/my_vps_key root@YOUR_SERVER_IP

We'll cover SSH key authentication in detail in our security hardening guide.

Troubleshooting SSH Connections

If your connection times out or is refused, check these common issues:

For verbose connection output that helps diagnose issues, add the -v flag:

ssh -v root@YOUR_SERVER_IP

This prints each step of the SSH handshake, showing exactly where the connection fails.

Step 2: Creating a Non-Root User with Sudo Privileges

Running everything as root is a security risk. A single mistyped command — rm -rf / instead of rm -rf ./ — and your entire server is gone. The standard practice is to create a regular user account and grant it sudo (superuser do) privileges for when you need elevated permissions.

Create a new user (replace deploy with your preferred username):

adduser deploy

You'll be prompted to set a password and fill in optional profile information (full name, room number, etc.). The password is required; everything else can be left blank by pressing Enter.

Now add this user to the sudo group:

usermod -aG sudo deploy

Verify the user has sudo access by switching to the new account:

su - deploy

Then run a command with sudo:

sudo whoami

If the output is root, sudo is working correctly. From now on, you'll SSH into the server as this user instead of root:

ssh deploy@YOUR_SERVER_IP

If you're using SSH key authentication, copy your authorized keys to the new user:

# As root, copy the authorized_keys file
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Understanding sudo

When you run a command with sudo, you're temporarily borrowing root-level permissions for that single command. The system logs every sudo invocation (in /var/log/auth.log), creating an audit trail of who did what and when. This is far safer than running everything as root, where there's no distinction between routine commands and dangerous operations.

By default, after you enter your sudo password, it's cached for 15 minutes — subsequent sudo commands during that window won't prompt for a password again. This behavior is configurable via /etc/sudoers (always edit with visudo, never directly).

Step 3: System Updates and Package Management

A freshly provisioned VPS may be days or weeks behind on security patches, depending on when the base image was built. Your first task after login should always be updating the system.

Update the Package Index

sudo apt update

This downloads the latest package lists from Ubuntu's repositories. It doesn't install anything — it just refreshes the local database of available packages and their versions.

Upgrade Installed Packages

sudo apt upgrade -y

This installs newer versions of all packages currently installed on the system. The -y flag auto-confirms the installation prompt. On a fresh server, this typically updates 20-80 packages and takes a few minutes.

If the update includes a new kernel, you'll need to reboot:

sudo reboot

Wait 30-60 seconds, then reconnect via SSH.

Clean Up Unused Packages

sudo apt autoremove -y

This removes packages that were installed as dependencies but are no longer needed (e.g., old kernel versions after an upgrade). It's housekeeping — not strictly necessary but good practice.

Install Essential Utilities

A few packages that aren't included by default but you'll almost certainly need:

sudo apt install -y curl wget git unzip htop net-tools software-properties-common
Package Purpose
curl / wget Download files and make HTTP requests from the command line
git Version control — needed for cloning repos and deploying code
unzip Extract .zip archives
htop Interactive process viewer (much better than plain top)
net-tools Includes ifconfig, netstat, and other network utilities
software-properties-common Adds add-apt-repository for managing PPAs

Understanding APT: Ubuntu's Package Manager

APT (Advanced Package Tool) is Ubuntu's package management system. It resolves dependencies automatically — when you install Nginx, APT also installs the libraries Nginx depends on. A few important distinctions:

Always run apt update before apt install or apt upgrade. Without a fresh package index, you might install outdated versions or encounter "package not found" errors.

Step 4: Setting Hostname, Timezone, and Locale

These settings seem minor, but they affect logging, cron jobs, email headers, and how your server identifies itself on the network.

Set the Hostname

The hostname is your server's name on the network. Choose something meaningful — the project name, server role, or a naming convention you can maintain as you add more servers:

sudo hostnamectl set-hostname web-prod-01

Verify it:

hostnamectl

You should see output like:

 Static hostname: web-prod-01
       Icon name: computer-vm
         Chassis: vm
      Machine ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
         Boot ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  Virtualization: kvm
Operating System: Ubuntu 24.04 LTS
          Kernel: Linux 6.8.0-xx-generic
    Architecture: x86-64

Also update /etc/hosts so the hostname resolves locally:

sudo nano /etc/hosts

Add or update the line with your server's IP and hostname:

127.0.0.1       localhost
YOUR_SERVER_IP  web-prod-01

Set the Timezone

Servers should generally run in UTC so that log timestamps are consistent and unambiguous, especially if you have servers in multiple regions. Most VPS providers set this by default, but verify:

timedatectl

If the timezone isn't UTC, set it:

sudo timedatectl set-timezone UTC

To see all available timezones if you have a reason to use a different one:

timedatectl list-timezones

Also ensure NTP synchronization is active (it should be by default on Ubuntu 24.04):

sudo timedatectl set-ntp on

This uses systemd-timesyncd to keep your system clock synchronized. Accurate time is important for TLS certificates, log correlation, and cron job scheduling.

Verify Locale Settings

The locale controls language, character encoding, and formatting conventions. For servers, en_US.UTF-8 is the standard:

locale

If you see warnings or need to change it:

sudo locale-gen en_US.UTF-8
sudo update-locale LANG=en_US.UTF-8

Step 5: Basic UFW Firewall Configuration

Ubuntu's Uncomplicated Firewall (UFW) is a frontend for iptables that makes firewall management straightforward. A properly configured firewall is your first line of defense against unauthorized access.

Check if UFW is installed (it comes pre-installed on Ubuntu 24.04):

sudo ufw status

Before enabling the firewall, you must allow SSH — otherwise you'll lock yourself out of the server:

sudo ufw allow OpenSSH

Set the default policies — deny all incoming traffic, allow all outgoing:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Now enable the firewall:

sudo ufw enable

You'll see a warning: "Command may disrupt existing ssh connections. Proceed with operation (y|n)?" Type y. Your existing SSH session will remain connected because you already allowed SSH traffic.

Verify the rules:

sudo ufw status verbose

Expected output:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

If you plan to run a web server, also allow HTTP and HTTPS now:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

For a more detailed firewall configuration — including rate limiting and port-specific rules — see our Ubuntu VPS Security Hardening Guide.

Step 6: Enabling Automatic Security Updates

Security vulnerabilities are discovered constantly. Automatic updates ensure critical patches are applied even if you're not actively monitoring the server.

Install the unattended-upgrades package (usually pre-installed on Ubuntu 24.04):

sudo apt install -y unattended-upgrades

Enable it:

sudo dpkg-reconfigure -plow unattended-upgrades

Select "Yes" when prompted. This configures the system to automatically install security updates from the Ubuntu:24.04/noble-security origin.

Verify the configuration:

cat /etc/apt/apt.conf.d/20auto-upgrades

You should see:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

This means the system checks for updates daily and installs security patches automatically. For more granular control — like enabling automatic reboots when kernel updates require them — see the /etc/apt/apt.conf.d/50unattended-upgrades configuration file, which we cover in our security hardening guide.

Step 7: Understanding Your Infrastructure — What MassiveGRID Handles

At this point, your Ubuntu VPS is configured at the operating system level. But there's an entire infrastructure layer beneath your VM that determines the reliability and performance of everything you just set up. Understanding what your hosting provider handles — and what they don't — matters.

Proxmox HA Cluster: Automatic Failover

On MassiveGRID, your VPS doesn't run on a single physical server. It runs on a Proxmox High Availability (HA) cluster — a group of interconnected hypervisor nodes. If the physical hardware hosting your VM fails (power supply, motherboard, drive controller), the Proxmox HA manager automatically migrates your VM to a healthy node in the cluster.

This happens at the infrastructure level. You don't need to configure anything. Your VM restarts on different hardware, with the same IP address, same disk contents, same configuration. Downtime from hardware failure is measured in seconds to minutes, not hours.

Ceph 3x Replicated NVMe Storage

Your VPS disk isn't a single NVMe drive that could fail and take your data with it. MassiveGRID uses Ceph, a distributed storage system that maintains three copies of every block of data across different physical drives and servers. If a drive fails, Ceph continues serving data from the remaining replicas and automatically re-replicates to restore the three-copy redundancy.

This means your filesystem — everything from /etc/ configuration files to your application data in /var/ — is protected against hardware failure without you needing to configure RAID or manage backups at the storage level. (You should still maintain application-level backups, of course.)

Independent Resource Scaling

Traditional VPS plans bundle CPU, RAM, and storage into fixed tiers. Need more RAM? You have to jump to a higher plan that might give you more CPU than you need, wasting money.

On MassiveGRID, resources scale independently. Need 8 GB of RAM but only 2 vCPUs? Configure exactly that. Need 200 GB of NVMe storage but minimal RAM? Done. You pay for what you use, not for a pre-packaged bundle. This is particularly useful as your server's needs evolve — a database server needs different resource ratios than a build server or a web application.

If your workload outgrows shared vCPUs and you need guaranteed CPU performance, consider upgrading to a Dedicated VPS (VDS) where CPU cores are exclusively allocated to your VM with no "noisy neighbor" contention.

Step 8: Verify Everything Is Working

Let's do a final check to confirm your server is properly configured:

# Check hostname
hostnamectl | grep "Static hostname"

# Check timezone
timedatectl | grep "Time zone"

# Check firewall
sudo ufw status

# Check automatic updates
systemctl status unattended-upgrades

# Check available disk space
df -h /

# Check memory
free -h

# Check CPU info
nproc

If everything looks correct, your Ubuntu 24.04 VPS is ready for the next step.

What to Do Next

Your server is updated, secured with a firewall, and configured with a non-root user. The foundation is solid. Where you go from here depends on what you want to build:

Each of these guides picks up where this one leaves off, assuming a properly configured Ubuntu 24.04 server.

Quick Reference: Essential Commands Cheat Sheet

Task Command
Connect to server ssh deploy@YOUR_SERVER_IP
Update packages sudo apt update && sudo apt upgrade -y
Check disk space df -h
Check memory usage free -h
View running processes htop
Check firewall status sudo ufw status
View system logs sudo journalctl -xe
Restart a service sudo systemctl restart <service>
Check open ports sudo ss -tulnp
Reboot the server sudo reboot

Not Ready to Manage a Server Yourself?

Server administration isn't for everyone, and there's no shame in that. If you'd rather focus on your application while someone else handles OS updates, security patches, firewall rules, performance tuning, and 24/7 monitoring, MassiveGRID's Managed Dedicated Cloud Servers include full server management. You get dedicated resources with the same Proxmox HA and Ceph storage infrastructure, plus a team of engineers handling everything at the OS and infrastructure level.