You have a VPS. The provider sent you an IP address, a root password, and maybe a link to a control panel. Now what?

This guide walks through the practical steps between receiving those credentials and having a working server that serves real traffic over HTTPS. It assumes you picked an unmanaged Linux VPS, which is what most entry-level and mid-range plans give you. If you need a refresher on what a VPS actually is, start there. If you are not sure whether your plan is managed or unmanaged, this breakdown of what each type covers will clarify what you are responsible for.

If you are still deciding on a provider, the VPS provider evaluation guide covers what to look for before you sign up. And if you are coming from shared hosting, the jump to a VPS is bigger than it looks at first. The steps below start after those decisions are made.

What You Need Before Logging In

Gather these before you start:

  • Your server's IP address and root login credentials (from your provider's dashboard or welcome email)
  • An SSH client on your local machine (Terminal on macOS/Linux, Windows Terminal or PuTTY on Windows)
  • A domain name pointed to your server, if you plan to serve a website (you can do this later, but it simplifies SSL setup if the DNS is ready)
  • 30 to 60 minutes of uninterrupted time (the first setup takes longer than subsequent ones, mostly because you are learning the environment)

You do not need prior Linux experience, but being comfortable typing commands into a terminal is the baseline.

First Login

Open your terminal and connect over SSH:

ssh root@YOUR_SERVER_IP

The first time you connect, your SSH client will ask you to verify the server's fingerprint. Confirm it. Type the root password when prompted.

Once you are in, confirm the operating system and version:

cat /etc/os-release

This tells you whether you are running Debian, Ubuntu, Rocky Linux, AlmaLinux, or something else. It matters because package manager commands differ between distributions.

Update the System Immediately

The OS image your provider used could be weeks or months behind on patches. Update everything before doing anything else.

On Debian or Ubuntu:

apt update && apt upgrade -y

On Rocky Linux, AlmaLinux, or RHEL:

dnf update -y

Reboot if the kernel was updated (reboot). This is not optional. Running a server with a stale kernel means security patches are loaded into memory only after the next restart, which defeats the purpose.

Security Foundations

A fresh VPS gets hit by automated port scans and brute-force login attempts within minutes of coming online. You need to close the obvious holes before doing anything else.

The short version:

  1. Create a regular user account and add it to the sudo group. Stop logging in as root directly.
  2. Set up SSH key authentication and disable password login. This eliminates the entire brute-force attack surface.
  3. Enable a firewall (ufw on Debian/Ubuntu, firewalld on RHEL-based systems). Allow SSH (port 22), HTTP (80), and HTTPS (443). Block everything else.
  4. Install fail2ban to automatically block IPs that repeatedly fail SSH login attempts.

Each of these steps has nuance. Rather than rushing through abbreviated instructions here, follow the full VPS security checklist, which covers all ten essential hardening steps in detail. Do this before deploying anything into production.

From this point forward, log in as your regular user and use sudo for administrative commands.

Point Your Domain to the Server

If you have a domain you want this server to host, update the DNS records now. SSL certificate provisioning (the next step after the web server) requires DNS to be working, and DNS propagation can take anywhere from a few minutes to several hours.

In your domain registrar or DNS provider's control panel, create an A record:

Record Type Name Value TTL
A @ YOUR_SERVER_IP 300 (5 min)
A www YOUR_SERVER_IP 300 (5 min)

The @ record covers yourdomain.com. The www record covers www.yourdomain.com. Set the TTL low during setup so changes propagate quickly. You can increase it later once everything is stable.

Verify propagation by running this from your local machine:

nslookup yourdomain.com

When it returns your server's IP address, DNS is ready.

Install a Web Server

Nginx is the most common choice for VPS setups. It is lightweight, handles static files efficiently, and works well as a reverse proxy for applications running behind it.

On Debian or Ubuntu:

sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

On Rocky Linux or AlmaLinux:

sudo dnf install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

If your firewall is active (it should be), confirm that HTTP traffic is allowed:

sudo ufw allow 'Nginx Full'      # Debian/Ubuntu
sudo firewall-cmd --permanent --add-service=http --add-service=https && sudo firewall-cmd --reload   # RHEL-based

Open a browser and navigate to http://YOUR_SERVER_IP. You should see the default Nginx welcome page. If you do, the web server is running and reachable.

If your domain's DNS has propagated, try http://yourdomain.com as well.

Set Up SSL with Let's Encrypt

There is no reason to run a public-facing site without HTTPS. Browsers flag HTTP sites as insecure, search engines penalize them, and users do not trust them. Let's Encrypt provides free, automatically-renewing certificates.

Install Certbot and the Nginx plugin:

sudo apt install certbot python3-certbot-nginx -y    # Debian/Ubuntu
sudo dnf install certbot python3-certbot-nginx -y    # RHEL-based

Request a certificate for your domain:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot will ask for an email address (for renewal notices) and whether to redirect HTTP to HTTPS. Choose yes for the redirect. It modifies the Nginx configuration automatically to serve traffic over TLS.

After it completes, visit https://yourdomain.com in your browser. You should see the padlock icon and the default Nginx page over a secure connection.

Certbot sets up a systemd timer to renew certificates automatically before they expire. Verify it is active:

sudo systemctl status certbot.timer

Deploy Something

Your server is reachable, secured, and serving HTTPS. The next step depends on what you are building.

Static site: Drop your HTML, CSS, and JavaScript files into /var/www/yourdomain.com/ and point Nginx's root directive at that directory. Edit the server block in /etc/nginx/sites-available/ (Debian/Ubuntu) or /etc/nginx/conf.d/ (RHEL-based), then reload Nginx with sudo systemctl reload nginx.

Application with a reverse proxy: If you are running a Node.js app, a Java service, a Python web framework, or anything else that listens on a local port, configure Nginx as a reverse proxy. In your server block, replace the static root directive with:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Change the port number to match your application. Reload Nginx afterward.

Database server: If your project needs PostgreSQL or MySQL, install it via your package manager, create a database and application user, and restrict access to localhost unless you have a specific reason to allow remote connections.

Each of these paths could fill its own article. The point here is that after the steps above, you have a foundation that supports any of them.

A Few Things People Forget

Automatic security updates. On Debian/Ubuntu, install unattended-upgrades and enable it. On RHEL-based systems, configure dnf-automatic. Critical patches should not wait for you to remember to log in.

Backups. Your provider may offer snapshot backups, but do not assume they are enabled by default. Check your control panel. If snapshots are not available or not frequent enough, set up your own backup process to an external location.

Monitoring. At minimum, know when your server is unreachable. An external uptime monitor (even a free one) that pings your domain every few minutes and alerts you by email will catch outages you would otherwise discover from user complaints.

Quick Reference

Step What you accomplish Approximate time
First login and OS check Confirm access and identify your distribution 5 minutes
System update Close known vulnerabilities from the provider image 5 to 15 minutes
Security foundations Non-root user, SSH keys, firewall, fail2ban 1 to 2 hours
DNS configuration Domain pointed at your server IP 5 minutes (plus propagation)
Web server install Nginx running and reachable on port 80 10 minutes
SSL with Let's Encrypt HTTPS working with automatic renewal 10 to 15 minutes
First deployment Your site or application live and serving traffic Varies

Where to Go From Here

The server is configured, secured, and serving traffic. That covers the foundation. Here is what to read next depending on what you are planning: