First VPS Setup Guide: From Order to a Live HTTPS Site

Your first VPS is not a complicated machine. It is an empty one that becomes your responsibility. Between placing the order and serving a site over HTTPS there are about ten steps, always in the same order. This guide takes them one at a time, with the exact command, the check that follows, and the mistake that costs an evening. No Linux background is assumed: if you can open a terminal, you can do this.

Before You Order: Plan, Name, Access

Choose a first VPS for what you will run on it, not for the largest configuration in the catalog. A brochure site or a test environment fits in 1 GB of RAM; a store with a database and background jobs deserves 2 to 3 GB. All five NVMe plans below share the same foundation — KVM, one dedicated IPv4, unlimited bandwidth, root access, automatic backups, a firewall with DDoS protection, 24/7 monitoring, support 6 days a week, and a 99.9% SLA on infrastructure — and differ only in resources.

Delivery is quoted at under fifteen minutes after ordering, and billing is monthly: start on the plan that fits and move up later without a painful migration. Current prices are on the Open Vista pricing page. The datacenter is in New York, the only production location today; a Rabat site is announced but not open yet. Before you pay, gather four things.

1. The domain name, at a registrar you control: no name, no TLS certificate.
2. An SSH client: built-in terminal on macOS and Linux, PowerShell on Windows, or PuTTY.
3. A password manager for the root password and your keys.
4. A clear hostname, such as web-01.

The First Fifteen Minutes: Log In, Create an Account

The management panel gives you the IPv4 address and the root password, and doubles as your fallback: web console, reboot, reinstall, DNS. That is where you will go if a change cuts off SSH, so keep it open in a browser tab.

First login, as root, from your workstation:

ssh root@YOUR_IP

Accept the fingerprint, then immediately create a working account: staying logged in as root is the most avoidable cause of incidents.

• adduser your_name creates the account and asks for a password.
• usermod -aG sudo your_name grants the right to administer the machine.
• ssh-keygen -t ed25519 -C "you@yourdomain.com" generates a key pair on your workstation.
• ssh-copy-id your_name@YOUR_IP puts the public key on the server.

Then open a second session with that account without closing the first: that is your safety net before hardening SSH with two directives and a service restart.

Turn Off Password Logins

In /etc/ssh/sshd_config.d/99-hardening.conf, add PermitRootLogin no and PasswordAuthentication no, then run sudo systemctl restart ssh. Test in a new terminal before closing the old one: a typo there can lock you out, and the panel becomes your only door. Once the key is in place, password attacks have nothing left to knock on.

Updates, Firewall, and Login Attempts

Patch Before You Install Anything

A fresh VPS rarely ships fully patched. Three commands are enough on Debian or Ubuntu; elsewhere only the package manager changes.

• apt update refreshes the list of available packages.
• apt full-upgrade -y installs the updates, kernel included.
• apt install unattended-upgrades enables automatic security patches.

If the kernel changed, reboot: a server on an old kernel keeps the vulnerabilities you just fixed.

Open Only What You Serve

Three ports are enough: SSH for you, HTTP and HTTPS for visitors. Everything else stays closed by default, and a port opened just in case always ends up scanned.

• ufw allow OpenSSH keeps the door you come in through.
• ufw allow 80/tcp and ufw allow 443/tcp open the web.
• ufw enable turns filtering on, ufw status verbose shows the result.

Order matters: allow SSH before enabling the firewall, or you are cut off instantly. If you get it wrong, the web console is the way back in.

Slow Down the Bots Guessing Passwords

A server exposed to the internet sees login attempts within hours. apt install fail2ban bans addresses that fail several times, and fail2ban-client status sshd shows the blocks. With key authentication this is a seatbelt: useful, never enough on its own.

DNS and Certificates: A Name, Then a Lock

The Records to Create

Two A records are enough: the bare domain and the www subdomain, both pointing at the VPS IPv4. Propagation takes minutes to hours depending on the TTL. dig +short yourdomain.com must return your address: until it does, do not request a certificate, the validation will fail.

The Certificate and Its Renewal

Let's Encrypt installs with one command. apt install certbot python3-certbot-nginx, then certbot --nginx -d yourdomain.com -d www.yourdomain.com: the certificate is issued and HTTP-to-HTTPS redirection is offered. Then check renewal, not just issuance: systemctl status certbot.timer must be active, and certbot renew --dry-run simulates the rotation. A forgotten certificate expires after ninety days and takes the site down without warning. For company validation, DV, OV, EV and wildcard certificates remain available.

Your First Site, Backups, Monitoring

Serve a Page, Then Check It

apt install nginx then systemctl status nginx: the default page already answers on the IPv4. Next, create your site in /etc/nginx/sites-available, enable it, and run nginx -t before every systemctl reload nginx. That syntax check takes one second and prevents a full outage caused by a forgotten brace.

An Untested Backup Is Not a Backup

Automatic backups are included on every plan, which says nothing about their contents. Change a test file, restore it, time it, and repeat every quarter. Keep a copy off the VPS too: a backup stored on the machine it protects covers neither a deleted account nor a lost server.

What Monitoring Covers, and What It Does Not

24/7 monitoring and the 99.9% SLA cover infrastructure: the machine answers, the network carries traffic, the hypervisor holds. They do not watch your application. A PHP error, an expired certificate, a full disk remain yours. Three checks are enough to start: homepage returns HTTP 200, certificate valid beyond thirty days, disk below 80%. Support runs six days a week, so keep that nuance for anything sensitive.

FAQ

How long does a first setup take?

Delivery is quoted at under fifteen minutes. Then allow twenty to thirty minutes for the account, keys and firewall, plus DNS propagation, from minutes to hours. The certificate takes a few minutes once the name resolves.

Can I run a site without a domain name?

Yes, for testing: the IPv4 alone shows the default page. But TLS requires a name, and an IP changes if you reinstall. Register the domain before the site goes live.

What if the firewall locks me out?

Use the panel's web console: it depends on neither SSH nor the server's own filtering. From there you can fix the rule, reboot, or reinstall as a last resort. That is why you check it works before touching the firewall.

Are automatic backups enough?

They cover the loss of the machine, not human error or a compromise. They replace neither a restore test nor an off-site copy. The 99.9% SLA covers infrastructure, not the availability of your application.

Your VPS Is Ready: the Checks to Repeat

A first VPS comes up in one evening, and the same checks return every month afterward: updates applied, firewall still limited to three ports, certificate renewing, backup restored at least once, disk below 80%. If one of those five slips, the rest can wait.

To go further, browse the Open Vista guides, compare configurations on the NVMe VPS server range, then order: delivery takes under fifteen minutes. And if you would rather not administer the machine, tell us: we will say honestly whether a VPS is what your project needs, or whether simpler hosting is enough.