How to Point a Domain to a VPS and Set Up SSL
Find your VPS IP, create DNS A and AAAA records, write an Nginx server block, and install a free Let's Encrypt certificate with Certbot and auto-renewal.
Find your VPS IP, create DNS A and AAAA records, write an Nginx server block, and install a free Let's Encrypt certificate with Certbot and auto-renewal.
A practical, end-to-end walkthrough to deploy a web app on a VPS with Nginx and Docker on Ubuntu, including HTTPS and keeping it running.
A plain guide to cloud hosting: how your site runs across a pool of machines, how pooled resources and scaling work, and the honest pros and cons.
A deep, vendor-neutral checklist for evaluating any web host, with exactly how to test each criterion before you buy and the red flags to watch for.
Shared hosting vs VPS is a timing question. Here are the signs you have outgrown shared hosting, what changes on a VPS, and how to switch without downtime.
To point a domain to a VPS and set up SSL, you do four things in order: find your server's public IP, create a DNS A record at your registrar that maps the domain to that IP, configure a web server like Nginx to answer for the domain, then install a free Let's Encrypt certificate with Certbot to serve the site over HTTPS. The whole sequence takes about fifteen minutes of work, plus some waiting for DNS to update. None of it requires paying for a certificate.
This guide walks through each step on an Ubuntu VPS running Nginx, from the DNS records you create at your registrar to a working https:// site with an automatic HTTP-to-HTTPS redirect and a certificate that renews itself. If you are still setting the server up, our guide on deploying a web app to a VPS with Nginx and Docker covers the steps before this one, and the Ubuntu server hardening guide covers locking it down after. Not sure which VPS to run? Start with how to choose a VPS.
Before you start, make sure you have these in place:
sudo privileges on the server.Your VPS public IP is the address the rest of the internet uses to reach your server, and it is what the DNS record points at. Most providers show it in their control panel next to the server. You can also read it from the server itself, which avoids copying the wrong one.
From an SSH session on the VPS, run one of these:
curl -4 ifconfig.me
That prints your public IPv4 address. If your VPS also has IPv6, get that address too:
VPS, cloud, or dedicated? What each one is, what it costs in money and effort, and how to pick based on traffic, resilience, and budget.
ip -6 addr show scope global
Look for the address on your main network interface. Write both down. The IPv4 address goes in an A record, and the IPv6 address, if you have one, goes in an AAAA record. A common mistake is grabbing a private address like 10.x.x.x or 192.168.x.x, which only works inside a local network. Use the public address your provider assigned.
A DNS A record maps a domain name to an IPv4 address, and an AAAA record does the same for IPv6. You create them at whoever runs your DNS, usually the registrar where you bought the domain, or a DNS provider like Cloudflare if you moved it there. This is the step that connects the name people type to the server you just set up.
In your DNS provider's dashboard, find the DNS or "manage records" section and add records like this:
@ (this represents the bare domain, example.com), Value: your IPv4 address, TTL: leave the default or set 3600.www, Value: the same IPv4 address. This handles www.example.com.@ and www pointing at your IPv6 address.The @ symbol is a convention most providers use for the root domain. Some want the full domain typed out instead, and a few use a blank name field. Add records for both the bare domain and www so the site works either way.
TTL, or time to live, is how many seconds resolvers are allowed to cache the record before checking again. A lower TTL means changes take effect faster, at the cost of slightly more lookups. If you know you will be changing records soon, drop the TTL to 300 a day ahead of time so the old value expires quickly.
After you save a record, it does not appear everywhere at once. DNS propagation is the time it takes for resolvers around the world to pick up the change, and it depends mostly on TTL. According to Cloudflare's DNS documentation, TTL controls how long resolvers cache a record before fetching a fresh copy. In practice an A record change is often visible within minutes to a couple of hours, though providers quote a conservative ceiling of up to 24 to 48 hours (Network Solutions). Do not panic if your domain does not resolve right away. Check progress with a tool like whatsmydns.net, which queries the record from many locations, or from your own machine:
dig +short example.com A
If that returns your VPS IP, the record is live where you are. Once it resolves, move on. Waiting longer will not change the next steps.
An Nginx server block (the equivalent of a virtual host) tells the web server which domain it should answer for and where the files live. Without one matched to your domain, Nginx serves its default page instead of your site. You create a config file, point it at your site's content, enable it, and reload.
Create a config file for your domain. Replace example.com with your own throughout:
sudo nano /etc/nginx/sites-available/example.com
Add a server block. This serves static files from a directory and answers for both the bare domain and www:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example.com/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
The listen [::]:80 line accepts IPv6 connections, which pairs with your AAAA record. The server_name line is what matches incoming requests to this block. Adjust root to wherever your site's files are, or replace the location block with a proxy_pass if you are running an app behind Nginx.
Create the content directory and a placeholder page so there is something to serve:
sudo mkdir -p /var/www/example.com/html
echo "<h1>It works</h1>" | sudo tee /var/www/example.com/html/index.html
Enable the site by linking it into sites-enabled, test the configuration, then reload Nginx:
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
The nginx -t step matters. It checks the config for syntax errors before you apply it, so a typo does not take the running site down. If it reports syntax is ok and test is successful, the reload is safe. Visit http://example.com in a browser, and you should see the placeholder page. If you do, DNS is pointing correctly and Nginx is answering.
Certbot is the tool that obtains and installs a free certificate from Let's Encrypt, a nonprofit certificate authority. It proves you control the domain, gets a certificate valid for ninety days, edits your Nginx config to use it, and sets up automatic renewal. The recommended way to install Certbot on Ubuntu is through snap, per the official Certbot instructions.
Remove any old Certbot from the apt repositories, then install the snap and link the command so it is on your path:
sudo apt-get remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
If snap is not already installed, follow snapcraft's install guide for your system first. With Certbot in place, run it with the Nginx plugin:
sudo certbot --nginx
Certbot reads the server_name values from your config, asks which domains to cover, asks for an email for expiry notices, and has you agree to the Let's Encrypt terms. It then validates each domain over port 80, fetches the certificate, and rewrites your server block to serve HTTPS on port 443. When it finishes, it confirms the certificate is installed.
Because the --nginx plugin edits your config for you, it will offer to add an automatic redirect from HTTP to HTTPS. Accept it. That single choice means anyone visiting http://example.com is sent to the secure version, and you do not have to write the redirect by hand. If you prefer to only fetch the certificate and edit Nginx yourself, use sudo certbot certonly --nginx instead.
Let's Encrypt certificates last ninety days, so renewal has to be automatic or the site eventually breaks. The good news is the snap install sets this up for you. It installs a systemd timer that runs Certbot twice a day, and each run renews any certificate within thirty days of expiry (Certbot documentation). You do not configure anything. You just confirm it works.
Check that the renewal timer is active:
sudo systemctl list-timers | grep certbot
You should see an entry for snap.certbot.renew.timer with a next-run time. Then do a dry run, which goes through the full renewal process against the staging servers without touching your live certificate:
sudo certbot renew --dry-run
If it reports success for your domain, automatic renewal is working and you can leave it alone. The dry run is the one verification worth doing now, because it surfaces problems while you are paying attention, instead of in ninety days when the certificate quietly fails to renew.
Verifying takes a browser and one command. Open https://example.com and look for the lock icon in the address bar, which means the certificate is valid and trusted. Then open http://example.com (plain HTTP) and confirm the browser jumps to the https:// version automatically. That redirect is what the Certbot Nginx plugin added for you.
You can also check from the command line. This requests the plain HTTP URL and shows the redirect:
curl -I http://example.com
A working setup returns a 301 Moved Permanently with a Location header pointing at https://example.com. To confirm the certificate itself, fetch over HTTPS:
curl -I https://example.com
A 200 OK with no certificate warning means the secure site is live. From here, your domain points at your VPS, traffic is encrypted, the redirect catches anyone arriving over plain HTTP, and the certificate renews on its own. Re-running sudo nginx -t after any future config change is a habit worth keeping, since it catches mistakes before they reach visitors.
You now have a domain pointed at a VPS, a working Nginx server block, and a free certificate that keeps itself current. The natural next steps are hardening the box so it is not running with defaults, and deciding what serves behind Nginx, whether that is static files, a reverse proxy to an app, or a container. The Ubuntu server hardening guide covers the firewall, SSH, and updates that should follow any new public server.
The best infrastructure tends to be the kind you stop thinking about: a certificate that renews quietly, a config that fails loud in testing instead of silent in production, and a setup simple enough that next year's you can still read it.