Ubuntu VPS Server

Choose an Ubuntu VPS server for your project

An Ubuntu VPS gives you a virtual machine running Ubuntu, with the resources and access included in your plan. With a self-managed server, you install and maintain your software. If you need someone else to operate it, confirm the scope of a managed service before buying.

Use the Ubuntu VPS Hosting comparison for checked configurations and running costs. This page takes the next step: choosing a deployment route and verifying a first website.

Compare published requirements and total costs →

Choose an Ubuntu image for your application

Compare a plain Ubuntu installation with the application images published by VDSina ↗. Check the base OS and first setup steps before choosing resources. Catalogue and provider help reviewed on 12 October 2026.

Application labels below follow the catalogue: “Ubuntu 22” and “Ubuntu 24” are provider labels. Confirm the exact release and software version in your order. A listed image is not a measured capacity recommendation.

The download includes your selected image, next steps and items still to confirm. Use the comparison link to carry your selection into the budget checker.

Observed 1 GB FASTPANEL server

We read the system information and current resource counters of one existing Ubuntu server on 12 October 2026 at 18:18:52 UTC. The account lists the FASTPANEL (Ubuntu 22) image. This is an existing installation with its own services and stored data; it does not represent a fresh image.

What this establishes: this particular 1 GB-class server has Ubuntu 22.04.5 and the listed services running. This initial read-only snapshot did not measure traffic or application capacity. The separate HTTP test below checks static HTML delivery on this installation. These results do not establish a minimum plan for FASTPANEL or any other template, or current availability when ordering.

The FASTPANEL plan and budget comparison covers 2, 4 and 8 GB-class offers. Its compatibility status remains unconfirmed until the actual template requirements and chosen offer are verified.

Check the order, access and recovery options

Use these published conditions alongside the image you choose. They describe the provider’s service; application setup and capacity still depend on your project.

Location and trial

The reviewed Standard offer is in the Netherlands. The provider offers daily billing and says there is no free trial. Confirm the selected data centre and amount due in the order form.

Initial login and recovery console

Provider help says access messages are available under Support → Tickets. For VNC, open My Servers, select the server, then Access → VNC. Confirm this recovery route before changing SSH or firewall settings.

Your own installation image

The ISO guide allows an upload, a download URL or an ISO-library image, with a maximum image size of 8 GB. It says uploaded images are not validated. Installation is completed through VNC; using your own ISO does not establish application compatibility.

Administration and migration

The published support article quotes $100 per hour for administration. It offers a site transfer without a labour charge when the work takes at most one hour and the balance has been funded for one month of the ordered plan. Request confirmation of scope through the account before relying on that offer.

Snapshots and restore destination

Provider snapshots are an additional paid service, with scheduled creation available. The snapshot guide requires a new restore destination to be in the same data centre as the copy and to have a disk quota at least as large as the snapshot. Network settings may need adjustment through VNC.

Copies you can take with you

The provider documents downloading a server backup as a compressed disk image. Keep an independent copy and test application and database recovery. A stored provider snapshot alone does not confirm a successful application restore.

Review backup retention, scaling and cancellation conditions →

Pick the right setup path

Prepare the server, domain and recovery access

Plan a fresh Ubuntu 24.04 VPS with a public IPv4 address, SSH on port 22, a sudo-capable initial account and a domain you control. Generate your SSH key in the next section before provisioning. If the empty server already exists, use the alternative key-installation path through your working access. Client commands use Bash on Linux, macOS or WSL; server commands run inside SSH. Stop if the example paths belong to an existing deployment.

Replace every 203.0.113.10 with your server address and every app.example.com with your hostname. Both are documentation examples. The initial username below is ubuntu; substitute the provider's account. Open the recovery console before changing access or firewall settings. Check the provider's firewall instructions for this image before using the UFW branch below; Oracle Cloud Ubuntu images require a different approach.

Create a key before provisioning, or add it through working access

On your computer, create a dedicated key and choose a passphrase. If the filename exists, choose another name throughout. The .pub file is public; keep the private file on your computer.

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

For a new VPS: now create the Ubuntu 24.04 server and supply this public key in the provider's SSH-key field. Confirm the initial username, then continue below with host-fingerprint verification. Skip the existing-server commands.

For an already-created, empty VPS: keep your working SSH session open. From another terminal on your computer, copy the new public key using the authentication that already works. Replace existing_vps_key with the filename of your current private key. If your established access uses a password or SSH agent, omit -i ~/.ssh/existing_vps_key; do not change the server's authentication policy.

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Inside the existing server session, validate the uploaded public-key file and append it to the initial account's authorized_keys. The append preserves existing entries; the extra newline also handles a file whose final line had no newline. This is for your own initial account. If you have no working access, use the provider's recovery process before continuing.

if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    printf '\n' >> ~/.ssh/authorized_keys
    cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
fi

For either path, before accepting a first connection compare its host-key fingerprint with the matching host public key in the trusted recovery console. For an Ed25519 host key, run this in that console:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

On your computer, open a fresh connection using the new key. Keep any original access open until this succeeds.

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

From another terminal on your computer, copy the public key for the separate administrator created next. Recopying this temporary public-key file is fine if the existing-server path already uploaded it.

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Create an administrator and test it separately

On the server, check getent passwd deploy first. No account should be returned. If deploy already exists, choose an unused username and substitute it throughout before proceeding, including home paths and group names. This avoids replacing another user's key file.

Confirm the image and resources, review upgrades, then create the administrator. Set a strong password for its sudo prompts. The install commands give the account ownership of its key file with restricted permissions.

cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys

Open another terminal on your computer and connect as the new administrator:

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

Inside that new server session, run sudo. It should print root after accepting deploy's password. Continue here when both checks work. Keep the original access available.

sudo whoami

Install Nginx and use the firewall supported by your image

On the server, install Nginx first. Guest firewall settings and the provider's network firewall both affect access; keep the recovery console and working SSH session available while adjusting them.

sudo apt install nginx
sudo systemctl enable --now nginx

In the provider firewall, permit TCP 22 from your administration location and TCP 80/443 for website visitors. If SSH uses another port, preserve that rule. Network rules alone do not open ports blocked by the guest firewall.

Oracle Cloud Ubuntu images: skip the entire UFW block below. Oracle warns that using UFW can interfere with essential image firewall rules and prevent booting. Preserve the supplied iptables rules, including those protecting iSCSI boot and block volumes. Configure OCI security lists or network security groups and the documented guest-firewall rules for HTTP/HTTPS. Do not flush the existing rules or replace the image's firewall packages.

UFW branch for other fresh Ubuntu images: use these commands only when the provider supports UFW and the image does not require a different managed firewall setup. Permit the actual SSH port before enabling it; this example assumes port 22.

sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

After either firewall path, verify a fresh SSH login. An already-open session does not test a new connection. The external HTTP check in the next section must also succeed before requesting a certificate. Keep existing login methods available while diagnosing access problems.

Publish a page in its own Nginx site

On the server, create a new document root and configuration. Substitute your hostname inside the block. Keep the quoted EOF markers: they prevent the shell from expanding Nginx variables such as $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="en"><title>First deployment</title><h1>Ubuntu VPS is serving this page</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    root /var/www/first-site;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t

On the server, reload only if the configuration test succeeds:

sudo systemctl reload nginx

From your computer, request this hostname at the server's address before changing DNS. Expect your heading, rather than the default Nginx welcome page.

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

Connect DNS and issue the HTTPS certificate

Create a DNS A record for the hostname pointing to the VPS IPv4 address. Publish an AAAA record only when IPv6 works on this server. A stale AAAA record can send visitors and certificate validation elsewhere. This example assumes DNS points directly to the VPS without a proxy.

On your computer, request http://app.example.com/ without --resolve. Continue when it returns your page. On the server, install the Ubuntu archive version of Certbot and its Nginx plugin. These packages require Ubuntu's Universe repository; resolve any package-not-found error before continuing.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timer

Follow the email and terms prompts. Certbot edits this site's configuration and enables an HTTP-to-HTTPS redirect. Confirm the renewal timer is scheduled; if inactive, enable it with sudo systemctl enable --now certbot.timer. Keep port 80 reachable for HTTP certificate validation and renewal.

Validate from outside and after reboot

On your computer, check the redirect, certificate and content. HTTP should redirect to HTTPS; HTTPS should succeed and display your heading. Do not add curl's -k option: it hides certificate validation failures.

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

While this is still a test deployment, run sudo reboot on the server. Reconnect as deploy when it returns, check systemctl is-active nginx, and repeat the external HTTPS request. Reboot deliberately closes SSH sessions; use the console if the machine fails to return.

Diagnose a failed check and preserve the deployment

Scroll sideways to see the full table →

For a failed login, follow the SSH error diagnosis to separate network, service and key problems before changing access settings.

Keep site files, Nginx configuration, DNS records and rebuild steps outside the VPS. Restore them on a separate machine before relying on the process. Certificate private keys need protected storage if backed up. Add availability and certificate-expiry alerts; one successful check does not monitor tomorrow's renewal.

Start with the file backup and restore exercise for a static page and Nginx configuration. It checks an independent copy without overwriting your working site; full recovery also needs the remaining assets, certificates and service configuration.

This deployment serves static files. A database or application runtime needs its own service configuration and backup method. Use the hosting requirements and cost comparison when adding those components.

Keep your launch checklist

Run each check in the walkthrough, then mark what you have confirmed. Each item includes the expected result and where to look if it fails. These are your own checks; this page does not connect to your server.

0 of 9 checks marked complete. Work through the unchecked items.

Your checklist stays in this page session and resets on reload. Save a text copy to keep it. No server address, password or private key is requested.

What to maintain after the first launch

Assign an owner and a recovery procedure before real visitors depend on the server. A working first page is only the start.

• Updates: check the automatic-update configuration and logs on your actual image. Ubuntu’s unattended-upgrades configuration controls what is applied; application and third-party repositories need separate attention. Plan reboots when required.
• Disk and logs: watch free space, log growth and backup failures. Set useful alerts for your workload instead of relying on the server booting successfully.
• HTTPS: preserve the renewal schedule and required network access; check the hostname again after DNS or firewall changes.
• Recovery: repeat the relevant restore check after major application changes. A static-file restore does not validate a database, secrets or the whole operating system.
• Costs: review storage, traffic, retained copies and unused resources. Confirm what must be deleted to end billing before removing anything you still need.

For connection failures, use the SSH troubleshooting guide. For image changes, use the Ubuntu compatibility guide.

Ubuntu VPS server questions

Scope and verification

The command walkthrough targets a fresh Ubuntu 24.04 LTS server, SSH on port 22 and direct DNS for one static Nginx website. Oracle Cloud Ubuntu images use the separate firewall route described above. We have not run this recipe on every provider image or measured application capacity.

Documentation reviewed: Ubuntu Server OpenSSH, firewall, Nginx and automatic updates; Certbot user guide; Ubuntu Certbot package information; Oracle Cloud platform-image guidance; Docker Engine firewall limitations; Hestia installation requirements. Review date: 12 October 2026.

Written for a fresh Ubuntu 24.04 VPS with direct DNS and SSH on port 22. Follow the firewall branch supported by your provider; Oracle Cloud Ubuntu images must skip UFW. These are documentation-based examples; the complete procedure has not been tested on every provider image.