Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The reliable path is: provision an Ubuntu VPS, create a sudo-capable non-root account, install Nginx, open the firewall without locking out SSH, upload files to a domain-specific web root, point both DNS hostnames at the VPS, and use Certbot to enable HTTPS. This guide walks through that sequence with commands you can run on a new server.
What you are building
A virtual private server (VPS) is a Linux virtual machine that you administer remotely. Unlike shared hosting, you are responsible for the operating system, firewall, web server, updates, certificates, backups, and recovery access. That control is useful for a first site, but one incorrect firewall or Nginx change can make the site or your remote access unavailable.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11
The finished setup has these components:
- An Ubuntu server with a normal deployment account that can use
sudo. - Nginx listening on port 80 and, after TLS is installed, port 443.
- Website files in
/var/www/example.com/html. - An Nginx server block matching
example.comandwww.example.com. - DNS A records for both names pointing to the VPS public IPv4 address.
- A Let’s Encrypt certificate managed by Certbot.
- A documented backup and recovery route through the provider console.
Use example.com below as a placeholder. Replace it consistently with your real domain in commands, paths, Nginx configuration, and certificate requests.
Choose and provision the VPS
Decide what matters before ordering
For a first brochure site, blog, or small static application, the important choice is a current Ubuntu image and a provider that gives you dependable console access. Compare providers on the operational features below rather than assuming a plan name or price will remain unchanged.
#1 Best Overall
| Decision area | What to verify | Why it matters after launch |
|---|---|---|
| Operating-system image | Current Ubuntu LTS image and an upgrade path | Package security updates and predictable Nginx instructions depend on a supported release. |
| Account and SSH workflow | SSH-key support, a provider console, and a way to reset access | The console is your fallback when SSH configuration or the firewall is wrong. |
| Network controls | Public IPv4, inbound and outbound rules, and documented port controls | DNS and certificate validation require the public address and reachable web ports. |
| DNS tools | Clear controls for A records and record changes | You must direct the apex and www hostnames to the server. |
| HTTPS automation | Whether standard ports 80 and 443 can receive inbound traffic | Certbot’s normal Nginx challenge cannot complete if validation traffic is blocked. |
| Backups and snapshots | Snapshot creation, retention, restore procedure, and extra cost | A snapshot gives you a recovery point before major upgrades or configuration work. |
| Support and region | Support hours, incident history, and a region close to your audience | Latency and recovery time affect the real user experience. |
| Recurring cost and quotas | Current monthly price, transfer allowance, storage, and renewal terms | Prices and quotas change; verify the current plan page before committing. |
Provision the machine
- Select an Ubuntu image offered by the provider and a region appropriate for your audience.
- Choose SSH-key authentication when the panel offers it. If you must use a password temporarily, change it after the first login.
- Record the public IPv4 address, hostname, server label, and provider-console URL in your deployment notes.
- Keep the provider’s recovery console available in a separate browser tab. Do not close it until SSH and the firewall have been tested.
Sign in through the console or SSH as the initial account supplied by the provider. Do not make a habit of running the website as the root user. The initial setup should create a normal account with administrative privileges and then use that account for routine work.
Secure the first login and update Ubuntu
Create a sudo-capable account
If the provider did not create a normal administrative user, create one while you still have the initial access:
Free tools Windows power users keep installed
One-click scans. No signup required.
sudo adduser deploy
sudo usermod -aG sudo deployReplace deploy with the account name you intend to use. Sign out and sign back in as that user so the new group membership is active. Confirm that administrative commands work:
sudo whoamiThe expected output is root. Keep the original provider account or console recovery route until you have successfully logged in as the new user with the authentication method you intend to use.
Apply current package updates
Refresh package indexes and install available updates before adding the web server:
sudo apt update
sudo apt upgradeRead any prompts carefully. If Ubuntu reports that a reboot is required, reboot from the console or SSH session and reconnect before continuing:
sudo rebootUsing current packages reduces the chance that a later Nginx or Certbot installation depends on outdated libraries. Repeat the update process regularly as part of maintenance.
Install Nginx and configure the firewall
Install and check Nginx
sudo apt update
sudo apt install nginx
sudo systemctl status nginxThe status command should show the service as running. At this point Nginx normally serves its default page on the VPS address. Do not delete that default configuration yet; it provides a useful fallback while you build the domain-specific site.
Rank #2
Allow SSH before enabling UFW
Ubuntu’s uncomplicated firewall (UFW) can protect the host, but enabling it before allowing your current SSH service can terminate your access. Add the SSH rule first:
sudo ufw allow OpenSSHAllow the Nginx profile that matches the traffic you need. During the initial HTTP-only test, Nginx HTTP is sufficient; once HTTPS is ready, Nginx Full permits both HTTP and HTTPS:
Recommended Free Tools
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status verboseWhen UFW asks for confirmation, verify that the SSH rule is listed before accepting. If your provider or organization uses a nonstandard SSH port, allow that port instead of relying on the OpenSSH profile. Keep port 80 open for normal HTTP access and certificate validation, and port 443 open for encrypted traffic.
Create the website files
Make a domain-specific web root
Keeping each site in its own directory prevents files from unrelated sites from being served by mistake:
sudo mkdir -p /var/www/example.com/html
sudo chown -R deploy:deploy /var/www/example.com/html
sudo chmod -R 755 /var/www/example.comUse the account that will upload or edit the site in place of deploy. The recursive ownership command gives that account control of the content while leaving the parent directory under administrative control.
Add a test page
Create a minimal page so you can distinguish an Nginx routing problem from an application problem:
nano /var/www/example.com/html/index.htmlPaste and save:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Example.com</title>
</head>
<body>
<h1>Example.com is online</h1>
<p>Nginx is serving this page from the VPS.</p>
</body>
</html>For a static site, replace this file with your generated files. For a dynamic application, Nginx will later proxy requests to the application process; the server block and DNS steps remain the same, but the application must be running and listening on its local port.
Create and enable the Nginx server block
Write the domain configuration
Ubuntu stores site definitions in /etc/nginx/sites-available. Create a file named after the domain:
sudo nano /etc/nginx/sites-available/example.comUse this HTTP configuration for the first test:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example.com/html;
index index.html index.htm;
location / {
try_files $uri $uri/ =404;
}
}The server_name line is what lets Nginx select this site when a request contains either hostname. The root points to the directory you created, and try_files serves an existing file or directory and returns a 404 for an unknown path instead of exposing an arbitrary location on the server.
Enable the block safely
Create the enabled-site symlink, test the complete Nginx configuration, and reload only if the test succeeds:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginxsudo nginx -t is a required checkpoint after every configuration edit. It catches syntax errors before a reload can disrupt a running service.
Test the intended page before removing the default site
At this stage, DNS may not yet point to the VPS. You can test with the server’s address and the correct Host header from a machine that has network access:
curl -I -H 'Host: example.com' http://YOUR_SERVER_IPReplace YOUR_SERVER_IP with the public IPv4 address. A successful response should come from your new server block, and a browser pointed at the domain should show the test page once DNS resolves.
Disable the default site only after the new block works:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorssudo rm /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginxIf the domain still displays the default page, check that the symlink exists, the server_name values exactly match the hostname in the browser, and the requested address resolves to this VPS.
Point the domain to the VPS
Create both required A records
At the registrar or DNS host that is authoritative for your domain, create:
| Hostname | Record type | Value | Purpose |
|---|---|---|---|
example.com (the apex) |
A | Your VPS public IPv4 address | Routes the bare domain to Nginx. |
www.example.com |
A | The same VPS public IPv4 address | Routes the www hostname and allows one certificate to cover both names. |
Some DNS panels display the apex as @; use the panel’s documented notation. If you deliberately configure IPv6, add an AAAA record only when the VPS has a working public IPv6 address and Nginx, UFW, and the provider network all permit it. A stale or incorrect AAAA record can send some visitors to a different destination.
Wait for resolution and verify it
DNS changes do not become visible everywhere at the same instant. Check both names from your workstation or a DNS lookup service and confirm that they return the VPS address:
dig +short example.com A
dig +short www.example.com ADo not request the certificate until both names resolve correctly and inbound ports 80 and 443 are permitted. Certificate validation has to reach the server named in the request; a partially updated record can cause a challenge failure even when the site works from one network.
Enable free HTTPS with Let’s Encrypt and Certbot
Install the Nginx integration
Install Certbot and its Nginx plugin using Ubuntu’s package system:
sudo apt update
sudo apt install certbot python3-certbot-nginxRequest a certificate for both hostnames and allow Certbot to edit the Nginx configuration:
sudo certbot --nginx -d example.com -d www.example.comFollow the prompts for an email address and the terms, then choose the redirect option when asked whether HTTP requests should be redirected to HTTPS. Certbot should obtain the certificate, add the TLS settings to the matching server block, and reload Nginx.
Let’s Encrypt certificates are valid for 90 days. The practical benefit of Certbot is automated renewal, not a certificate that lasts indefinitely. Confirm the installed certificate and the redirect:
curl -I http://example.com
curl -I https://example.com
sudo certbot certificatesThe HTTP response should redirect to an HTTPS URL, and the certificate listing should include both requested names and an expiration date.
Test renewal before relying on automation
Run a renewal simulation:
sudo certbot renew --dry-runA successful dry run demonstrates that the renewal mechanism can complete with the current configuration. Keep port 80 reachable even when you prefer HTTPS-only browsing, because the standard HTTP-01 validation method may need it for future renewals. Monitor renewal logs or your provider’s documented renewal status rather than assuming a timer will always succeed.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Use DNS-01 when HTTP validation cannot work
If inbound HTTP/HTTPS traffic cannot reach the server, or you need a wildcard certificate such as *.example.com, use the DNS-01 challenge. Certbot or its DNS plugin asks you to publish a verification value as a DNS TXT record. The certificate authority checks that record to prove control of the domain. DNS-01 requires access to the authoritative DNS service and a procedure for creating and removing TXT records; it is not a workaround for an incorrectly pointed A record on an ordinary single-host certificate.
Verify the complete launch
Run checks in this order
- Resolve
example.comandwww.example.comto the VPS public address. - Open the site in a private browser window and confirm the intended page appears, not the Nginx default page.
- Request the HTTP URL and confirm it redirects to the HTTPS URL.
- Inspect the browser’s certificate details and confirm that the name covers the hostname you entered.
- Run
sudo nginx -tand confirm that the syntax test reports success. - Run
sudo systemctl status nginxand confirm the service is active. - Run
sudo ufw status verboseand confirm SSH, HTTP, and HTTPS are allowed as intended. - Run
sudo certbot renew --dry-runand record the result in your maintenance notes.
When the browser shows the wrong page
- Default Nginx page: verify the enabled symlink, the exact
server_name, and whether the default site is still winning the request. - Connection timeout: check the provider’s network firewall, UFW rules, and whether the DNS record points to the current VPS address.
- 404 for the home page: confirm that
/var/www/example.com/html/index.htmlexists and that therootdirective uses the same path. - 502 Bad Gateway: this indicates a proxy target or application process problem; a static site should not have a proxy directive in its server block.
- Certificate challenge failure: verify both A records, port 80 reachability, and that another server block is not answering for the requested names.
When Nginx will not reload
Do not repeatedly reload a configuration that has failed validation. Run:
sudo nginx -tRead the reported file and line number, correct the syntax, and run the test again. Common causes include a missing semicolon, an unmatched brace, a duplicated directive, or a typo in the certificate path. Only after a successful test should you run:
sudo systemctl reload nginxMaintain the VPS after launch
Patch and monitor the host
Schedule regular package maintenance with a change window that allows a reboot when Ubuntu requires one. Check Nginx status after updates and review logs when users report errors. Keep a written inventory of the domain names, server IP, DNS host, SSH account, firewall rules, and certificate renewal method.
Back up what you cannot recreate
A provider snapshot can restore the whole machine, while an application-level backup should protect the website files, uploads, database, and any secrets needed to rebuild the service. Test that you can restore a backup; a backup that has never been restored is only an assumption. Take a snapshot before major operating-system, Nginx, or application changes, and understand the provider’s retention and restore charges.
Preserve recovery access
Keep the provider console credentials and recovery procedure in a secure password manager. Never remove the last working administrative route while experimenting with SSH or UFW. If you do lock yourself out, use the console to correct the firewall or SSH configuration, then reconnect normally and document the fix.
Quick Recap
A reusable launch checklist
- Ubuntu VPS provisioned and public IPv4 address recorded.
- Provider recovery console tested or confirmed available.
- Normal sudo-capable account created and tested.
- Package indexes and installed packages updated.
- Nginx installed and running.
- SSH allowed before UFW was enabled.
- Required Nginx HTTP/HTTPS firewall profile allowed.
/var/www/example.com/htmlcreated with appropriate ownership and permissions.- Test
index.htmlserved from the intended root. - Server block enabled through
sites-enabled. sudo nginx -tpassed before every reload.- A records for the apex and
wwwresolve to the VPS. - Certbot certificate covers both names.
- HTTP redirects to HTTPS.
- Renewal dry run succeeds.
- Backups, snapshots, patching, and console recovery are documented.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
