How to host a domain on your VPS

Hosting a domain on a VPS is two separate jobs that both have to be done for the site to actually appear: DNS has to point the domain at your server's IP address, and the web server on that IP has to be configured to answer for that specific domain name. Skip either half and you get either nothing at all, or the wrong site.

Step 1: point the domain at your server

At wherever the domain's DNS is managed — your registrar, or your host if the domain uses their nameservers — create or edit an A record:

This step is identical whether the server behind it is a VPS or any other kind of hosting — see pointing a domain to your hosting and what DNS actually is if any of this is unfamiliar. Give it time to spread before assuming something is broken — DNS changes are not instant everywhere at once.

Step 2: configure the web server to answer for the domain

A web server can host more than one domain on a single IP address, and it uses the domain name in the incoming request to decide which site's files to serve. Until you configure that mapping explicitly, the server just serves its default page regardless of what domain pointed at it.

Nginx: a server block

Create a config file for the domain:

sudo nano /etc/nginx/sites-available/example.com

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

Enable it by linking it into sites-enabled, then test and reload:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

On RHEL-family systems, Nginx does not use the sites-available/sites-enabled convention by default — place the server block directly in /etc/nginx/conf.d/example.com.conf instead, then run the same nginx -t and reload.

Apache: a virtual host

sudo nano /etc/apache2/sites-available/example.com.conf

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/public

    <Directory /var/www/example.com/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Enable the site and reload:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

On RHEL-family systems there is no a2ensite — save the file directly into /etc/httpd/conf.d/example.com.conf, run apachectl configtest, then reload httpd.

Create the document root and set ownership

sudo mkdir -p /var/www/example.com/public
sudo chown -R $USER:$USER /var/www/example.com/public

Put an index.html file there to confirm the config is working before you deploy anything more complex to it.

Choosing a canonical version of the domain

With both example.com and www.example.com pointing at the same server, decide which one is canonical and redirect the other to it — serving identical content at both addresses without a redirect is worth avoiding, since it splits how visitors and search engines treat what is really one site. In the Nginx server block, redirect the non-preferred version:

server {
    listen 80;
    server_name www.example.com;
    return 301 http://example.com$request_uri;
}

In Apache, the equivalent uses mod_rewrite inside the virtual host:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ http://example.com$1 [R=301,L]

Once HTTPS is in place — covered next — update these redirects to point at the https:// version, so visitors land on the final, secure, canonical address in a single hop rather than being redirected twice.

Checking it worked

Visit the domain in a browser, but do not treat your own browser as a reliable test — it caches DNS answers and can show you a stale result. A more direct check:

curl -H "Host: example.com" http://your-server-ip/

This sends a request straight to your server's IP but tells it to respond as if the request came in for example.com — it confirms the web server config is correct independently of whether DNS has finished spreading yet.

Next: add HTTPS

A domain serving plain HTTP is not finished — browsers actively warn visitors away from sites without a valid certificate, and most modern web features require HTTPS outright. Once the domain is confirmed working over HTTP, install a free Let's Encrypt certificate for it; the certbot tooling that guide covers can even reconfigure the Nginx or Apache config above automatically to redirect HTTP to HTTPS.