How to Set Up a New VPS: A First-Day Security Checklist for Canadian Small Businesses

Short answer: Setting up a new VPS takes about an hour of careful work. Make the decisions that are hard to undo before you order: managed or self-managed, operating system, control panel and data centre. Once the server is running, update it, create a named admin user with sudo, switch SSH to key-only logins, turn on a firewall that allows only the ports you use, add brute-force protection and automatic security updates, and only then install your web stack. After that, point DNS at the server, automate TLS certificates, set up backups you have actually restored from, and add monitoring that alerts a person. Keep a second SSH session or your provider’s browser console open whenever you change SSH or firewall settings, so a typo can’t lock you out.

A new virtual private server is a blank Linux machine on the public internet, and automated scanners will start trying its SSH port within minutes. This guide is for Canadian small businesses and the people who look after their servers, typically after moving up from shared hosting. It goes through the first day in order, explains why each step matters, and gives the commands for Ubuntu, Debian and AlmaLinux/Rocky Linux, with links to the official documentation behind each one. Where it helps, it notes what 4GoodHosting’s VPS plans say they include, so you can see which steps a provider might handle for you.

What should you decide before you order a VPS?

Some choices can be changed later with little effort, such as adding RAM or CPU. Others mean rebuilding the server from scratch. Settle these four first.

Managed or self-managed: who will do the sysadmin work?

With a self-managed (unmanaged) VPS, you or your developer handle everything inside the operating system: updates, firewall, users, the web server, and fixing things when they break. A managed VPS moves some or all of that to the provider. The line between the two differs from host to host, so check the plan description rather than relying on the label. 4GoodHosting’s data centre page gives the same advice: operating-system maintenance, firewall configuration and resource planning are all part of running a server, and you should confirm which of those tasks the provider handles and which belong to your team.

If nobody on your team is comfortable at a Linux command line, a managed plan or a control panel will cost less than an outage. If you have that skill in-house, self-managed gives you full control. 4GoodHosting’s article on whether self-managed VPS hosting is worth it covers the trade-off in more detail.

How much CPU, RAM and storage do you need?

Size the server to the workload you have now, with some headroom. Upgrading a VPS is usually much easier than moving a site. If you are leaving shared hosting because of resource limits, the signs and the order of options are covered in p4e’s guide to knowing when to upgrade your hosting plan. If page speed is the reason, read how a VPS affects page speed first. More RAM won’t fix a slow theme or uncached database queries.

Which operating system should you choose?

Pick a long-term-support release that will still be getting security updates well into the server’s expected life. If your control panel or application has requirements, those come first. Here are the support windows published by the projects themselves:

Sources: Ubuntu release cycle, Debian releases, Debian LTS, AlmaLinux release notes. Rocky Linux is also RHEL-compatible; check the Rocky Linux project’s own release pages for its support dates.

Three practical rules:

• Use a release that is still in standard support. Ubuntu’s LTS releases get five years of standard security maintenance. Debian’s cycle is about three years of full support followed by two years of LTS. Building a new server on a release in its final year means doing a major upgrade almost immediately.
• Do not build on CentOS Linux. The CentOS Project ended CentOS Linux 8 on December 31, 2021 and moved to CentOS Stream. If a provider’s form still lists “CentOS”, ask which release it means. For a RHEL-style server, AlmaLinux or Rocky Linux are the usual replacements.
• If you want cPanel, pick an OS that cPanel supports. cPanel’s system requirements list AlmaLinux, CloudLinux, Rocky Linux and Ubuntu, but not Debian. For a longer comparison of distributions on a Canadian VPS, see 4GoodHosting’s guide to the best operating system for Canadian VPS hosting.

Control panel or command line?

Decide this before you touch the server. cPanel’s installation guide says to install cPanel & WHM only on a freshly installed operating system. It also says there is no uninstaller: removing it means reformatting the server. If you want a panel, order the VPS with the panel included or install it first, before following the hardening steps below. The panel will manage its own web server, mail, DNS and firewall settings.

Which data centre location?

Choose the region closest to most of your visitors and your team, and keep in mind where your data will be stored. For most Canadian businesses that means Vancouver for western Canada and Toronto for central and eastern Canada. Also note where backups are stored, since some plans keep them in a different facility from the server.

Step 1: How do you log in to a new VPS for the first time?

After you order, the provider sends the server’s IP address and either a root password or an option to add an SSH public key. Some providers also give you a browser-based console. Before you start, find that console or recovery access in your dashboard. It is your way back in if an SSH or firewall change goes wrong.

The safest first login uses an SSH key from the start. If your provider lets you paste a public key at order time, do that. Otherwise, log in once with the temporary password and switch to keys in Step 4.

ssh root@203.0.113.10

(Replace the documentation IP 203.0.113.10 with your server’s address.) The first time you connect, SSH shows the server’s host key fingerprint. If the provider’s dashboard or console shows the fingerprint, compare the two before typing “yes”. Then change the temporary root password immediately with passwd, or remove it once key logins work.

Ubuntu images often skip the root account entirely. Ubuntu’s user management documentation explains that root is disabled by default and the first user is put in the sudo group. Provider images vary, so you may receive either a root login or a named user.

Step 2: Why update the server before anything else?

Provider templates are built at a point in time, and security fixes have usually been released since. Install them before you open any services.

Ubuntu and Debian:

sudo apt update
sudo apt full-upgrade
sudo reboot

AlmaLinux and Rocky Linux:

sudo dnf upgrade --refresh
sudo reboot

Reboot if a new kernel was installed, then log back in. Also set the hostname and time zone now (hostnamectl set-hostname and timedatectl set-timezone America/Toronto or America/Vancouver). Log timestamps that match your office make troubleshooting much easier.

Step 3: How do you create an admin user with sudo?

Do day-to-day administration as a named user who uses sudo when it needs elevated rights. Avoid working as root. Ubuntu’s documentation notes that sudo records which user ran which administrative command, so you keep accountability even with several admins. Ubuntu 25.10 and later use sudo-rs, a reimplementation of sudo, by default. The commands are the same.

Ubuntu and Debian:

adduser alex
usermod -aG sudo alex

AlmaLinux and Rocky Linux (the admin group is wheel):

useradd -m alex
passwd alex
usermod -aG wheel alex

On a minimal Debian install where a root password was set, sudo may not be installed. Run apt install sudo as root first. Then open a new terminal, log in as the new user, and confirm sudo whoami returns “root” before going further. Create a separate account for each person who needs admin access. Shared logins make it impossible to tell who changed what.

Step 4: How do you set up SSH keys and turn off password logins?

Brute-force password guessing is the most common attack on a new server, and SSH keys remove it as a risk. On your own computer (not the server), generate a key. Ubuntu’s OpenSSH server guide recommends Ed25519 for its shorter keys and lower computational requirements, with RSA as an alternative for older systems.

ssh-keygen -t ed25519 -C "alex@yourcompany.ca"
ssh-copy-id alex@203.0.113.10

Protect the private key with a passphrase when ssh-keygen asks. The ssh-keygen manual explains the options. ssh-copy-id adds your public key to ~/.ssh/authorized_keys on the server. If you copy keys by hand, make sure only your user can write to that file, as Ubuntu’s guide describes (chmod go-w ~/.ssh/authorized_keys). Test that you can log in with the key before you change anything else.

Next, tell the SSH daemon to accept keys only. OpenSSH’s sshd_config manual shows that PasswordAuthentication defaults to yes and PermitRootLogin defaults to prohibit-password, which still allows root to log in with a key. For a small business server with named admin users, turn both off:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Put these lines in the file:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Why a separate file, and why “00”? Ubuntu’s guide explains that the main config includes /etc/ssh/sshd_config.d/*.conf at the very top. Because OpenSSH uses the first value it reads for most directives, settings in that directory override the main file. Some images ship their own file in that directory, for example one created by cloud-init that turns password logins back on. A file that sorts first is read first and wins. To check the settings that will actually apply, run:

sudo sshd -t
sudo sshd -T | grep -Ei "passwordauthentication|permitrootlogin|kbdinteractive"

sshd -t checks the syntax. Never restart SSH if it reports an error. If both commands look right, keep your current session open, restart the service, and test from a second terminal:

sudo systemctl restart ssh      # Ubuntu and Debian
sudo systemctl restart sshd     # AlmaLinux and Rocky Linux

From the second terminal, check that key login as your admin user works, and that ssh root@... and password logins are refused. Close the first session only after that. Moving SSH to a non-standard port cuts down log noise but adds no real security. If you do it, remember to open the new port in the firewall, and on RHEL-family systems tell SELinux about it, before you restart SSH.

Step 5: How do you configure the firewall?

Use a default-deny policy for incoming traffic and allow only what you use: SSH, plus HTTP and HTTPS once a website is running. Allow SSH before you enable the firewall.

Ubuntu and Debian use UFW. Ubuntu’s firewall documentation describes it as Ubuntu’s default firewall configuration tool. Debian may need apt install ufw first.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

If your office has a static IP address, you can limit SSH to it. Ubuntu’s documentation shows the form sudo ufw allow proto tcp from 198.51.100.7 to any port 22. Do this only if you have console access as a fallback, because home and mobile IP addresses change.

AlmaLinux and Rocky Linux use firewalld. Its documentation explains the difference between the runtime configuration and the permanent one. Use --permanent so changes survive a reboot, then reload:

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

On most RHEL-family images, SSH is already allowed in the public zone. Confirm it appears in --list-all before you log out. Never expose database ports (3306, 5432) or admin dashboards to the whole internet. If you need remote database access, use an SSH tunnel or a VPN.

The server firewall is only one layer. Many providers also filter at the network edge for DDoS attacks. That helps against floods but doesn’t replace the server firewall.

Step 6: How do you stop brute-force login attempts?

Key-only SSH already makes password guessing useless. A tool such as fail2ban still helps: it cuts log noise and protects any other service that does accept passwords, such as mail or a panel login. Its project page explains that it scans log files such as /var/log/auth.log and bans IP addresses with too many failed login attempts, by updating firewall rules to reject them for a set time.

sudo apt install fail2ban        # Ubuntu and Debian
sudo dnf install epel-release && sudo dnf install fail2ban   # AlmaLinux and Rocky Linux

Never edit jail.conf directly. Create /etc/fail2ban/jail.local and enable the SSH jail:

[sshd]
enabled = true
maxretry = 5
bantime = 1h

If your distribution logs to the systemd journal instead of /var/log/auth.log, add backend = systemd to the jail. Then run sudo systemctl enable --now fail2ban and check it with sudo fail2ban-client status sshd. Be careful with very long ban times if staff connect through shared office or mobile networks. A ban hits everyone behind that IP address.

Step 7: How do you keep security updates automatic?

Unpatched software is the easiest way into a server. The Canadian Centre for Cyber Security puts “Automatically patch operating systems and applications” second in its baseline controls for small and medium organizations, and recommends automatic patching wherever possible.

Ubuntu: Ubuntu’s automatic updates guide says security updates are applied automatically through the unattended-upgrades package, which is installed by default. Two details matter. Packages from repositories you add yourself are not included unless you configure them. And automatic reboots are optional, so a kernel update may sit until someone reboots. Choose a reboot time when traffic is low, or schedule reboots yourself.

Debian: install and enable the same tool:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

AlmaLinux and Rocky Linux: use dnf-automatic. Its documentation shows that apply_updates defaults to False, which means updates are downloaded but not installed until you change the setting. In /etc/dnf/automatic.conf, set apply_updates = yes (and upgrade_type = security if you want security fixes only), then enable the timer:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Automatic OS updates do not cover WordPress, plugins, Composer or npm packages. Those need their own schedule. 4GoodHosting’s piece on website patch management covers that application layer.

Step 8: Should you install a control panel or a web stack?

If you chose cPanel or another panel, install it now, on the freshly built server. The panel handles the web server, PHP versions, databases, mail and often its own firewall integration. From then on, make changes through the panel. Editing files the panel manages by hand can be overwritten on the next update.

Without a panel, install only what the site needs:

Habits that prevent most problems:

• Bind the database to localhost (the default in most packages) and run mysql_secure_installation or the MariaDB equivalent.
• Give each site its own system user and database user, so a hacked plugin on one site can’t read another site’s files.
• Use the distribution’s packages where you can, so unattended-upgrades or dnf-automatic patch them. Software added from other repositories or installed by hand has to be tracked separately.
• Remove what you do not use: sample sites, default pages and unused services (ss -tulpn lists what is listening).

Step 9: How do you point your domain at the new VPS?

If the site is moving from another host, build and test it on the VPS first. You can preview it by temporarily adding the domain to your computer’s hosts file. Then:

1. Lower the DNS TTL a day or two ahead. Google’s guidance on changing hosting without changing URLs recommends lowering the TTL so the new records spread faster. A value of 300 seconds is common during a move.
2. Update the A record (and the AAAA record if the server has IPv6) to the VPS address. Leave MX and email-related records alone unless email is moving too.
3. Keep the old hosting running until traffic and logs show visitors have moved, and until you have confirmed nothing still points at it.
4. Raise the TTL again once everything is stable.

Step 10: How do you add a free SSL certificate and keep it renewing?

Let’s Encrypt issues free domain-validated certificates, and Certbot is the most common client on a VPS without a panel. Select your web server and OS on Certbot’s instructions page for the exact install method. The usual flow is sudo certbot --nginx or sudo certbot --apache, followed by sudo certbot renew --dry-run to test renewal. Panels such as cPanel usually handle certificates automatically.

Two details catch people out:

• Validation needs port 80, or DNS. Let’s Encrypt’s challenge types documentation says the HTTP-01 challenge can only be done on port 80. Keep 80 open (and redirect it to HTTPS) even if the site is HTTPS-only. For wildcard certificates, or for servers that can’t be reached on port 80, use the DNS-01 challenge through your DNS provider’s API.
• Certificate lifetimes are getting shorter. Let’s Encrypt has announced that it will issue 64-day certificates by default from February 10, 2027, and its plan to reach 45 days moves to 45-day certificates on February 16, 2028. It advises against manual renewal. Renewal should be automated, use ACME Renewal Information (ARI) where your client supports it, or otherwise happen about two-thirds of the way through the certificate’s life, not at a fixed 60 days. Add certificate-expiry checks to your monitoring (Step 12).

Step 11: What backups does a new VPS need?

Set up backups before the site goes live, not after the first incident. A provider snapshot copies the whole disk at a moment in time, which is very useful before upgrades and risky changes. It is not a full backup strategy on its own if it is stored on the same platform and kept for only a few days. A sound plan has at least one copy away from the server, versioned history, database dumps that are consistent, and a restore you have actually tested.

Cover these on a VPS:

• Files: web roots, uploads and /etc (your configuration).
• Databases: scheduled dumps (mysqldump or mariadb-dump, pg_dump), not only raw copies of data files.
• Off-server copies: for example, encrypted copies to object storage with a tool such as restic or Borg, kept separate from the server’s own credentials.
• Retention and restore tests: enough history to go back past a problem nobody noticed for days, plus a timed restore at least once a quarter.

For a full plan with schedules, tools and restore testing, see p4e’s website backup strategy guide.

Step 12: What should you monitor on a VPS?

Monitoring is only useful if an alert reaches someone who will act on it. At a minimum, cover:

4GoodHosting’s article the case for website monitoring explains why external checks belong alongside the server’s own graphs.

How do you go beyond the basics with a hardening baseline?

The steps above cover the most common attacks. For a formal baseline, two free references are worth knowing:

• CIS Benchmarks. The Center for Internet Security publishes CIS Benchmarks: consensus-based configuration recommendations for many products, including Ubuntu, Debian and RHEL-family systems. Use the Level 1 profile as a checklist rather than applying every item blindly, because some items can break hosting software.
• Canadian Centre for Cyber Security. The Cyber Centre’s top 10 IT security actions include patching operating systems and applications, managing administrative privileges, hardening operating systems and applications, and isolating web-facing applications. Its baseline controls for smaller organizations call for two-factor authentication on system administrator and cloud administration accounts, and for keeping internet-facing servers separate from the corporate network.

In practice, that means turning on two-factor authentication for your hosting account, control panel and DNS registrar. Those logins can rebuild or redirect your server no matter how well SSH is locked down. 4GoodHosting’s article on data security best practices for VPS servers covers more of the same ground.

First-day VPS setup checklist

What do 4GoodHosting’s VPS plans include for setup?

4GoodHosting is a Canadian host, and its VPS pages describe several options that relate to the steps above. These details come from the company’s live product pages. Confirm current specifics with them before ordering, because product pages change.

• Operating systems and access: the Linux VPS hosting page lists full root access over SSH, Proxmox-based virtualization, and current catalogue choices of AlmaLinux, Rocky Linux, Ubuntu and Debian. It says available versions and compatible cPanel combinations are shown during ordering. The general VPS page also lists Windows VPS plans.
• Control panels: on Linux you can order without a panel or add a paid cPanel/WHM licence tiered by account count, with Softaculous as an option. The VPS overview lists Plesk as an option on Windows.
• Managed vs self-managed: the Linux VPS page describes managed support tiers ranging from basic Level 1 support to Level 3 managed support that includes onsite backups, VPS security and hardening, and script or software installation. It also offers optional security scanning and patching. The VPS overview describes a self-managed option and a fully managed option.
• Launch Assist: the VPS overview describes Launch Assist as sysadmin support, data migration and server setup, and says it is included with purchases of cPanel or Control Web Panel. It also lists free website transfers.
• Recovery and backups: the overview mentions automatic snapshot backups kept for 7 days, on-demand snapshots, a recovery console and a browser-based terminal, plus optional automatic daily backups with up to 14 days of retention. The Linux VPS page notes that backups are separate from the RAID 10 storage. Retention wording differs between pages, so confirm which backup option your plan includes.
• Network and monitoring: the overview lists DDoS filtering and monitoring with alerts on uptime, CPU, RAM and storage.
• Locations: infrastructure in Vancouver and Toronto. The overview notes that setup can take up to 24 hours in some cases.

Even with a managed plan, ask the provider which of the twelve steps they do and which stay with you. Application updates, user accounts for your staff, and restore testing usually stay with you.

Frequently asked questions

How long does it take to set up a VPS?

Hardening a fresh server (updates, user, SSH keys, firewall, fail2ban, automatic updates) takes about an hour for someone who has done it before. Installing the web stack, moving a site and cutting over DNS can take anything from an afternoon to a few days, depending on site size and DNS TTLs.

Is Ubuntu or AlmaLinux better for a small business VPS?

Both are solid choices. Ubuntu LTS has the most tutorials and community answers, and ships unattended-upgrades by default. AlmaLinux suits teams used to Red Hat tools and has long security support. If you want cPanel, both appear on cPanel’s supported list. Pick the one your administrator knows best.

Do I still need a firewall if my provider has DDoS protection?

Yes. Network-level DDoS filtering absorbs floods of traffic. A server firewall controls which services anyone can reach at all. You want both.

Should I disable root login over SSH?

For a server run by named admins with sudo, yes: set PermitRootLogin no. OpenSSH’s default, prohibit-password, already blocks root password logins but still allows root keys. Turning it off completely means every admin action can be traced to a named account.

Can I install cPanel on a VPS that is already running websites?

cPanel’s installation guide says to install only on a freshly installed operating system, and it has no uninstaller. Plan for a new server, then migrate the sites onto it.

Is a provider snapshot enough as a backup?

Not by itself. Snapshots are great for quick rollbacks, but you also need off-server copies with longer history, consistent database dumps and tested restores.

Do I need to manage Let’s Encrypt renewals myself?

Certbot and control panels renew automatically once set up. Your job is to check that renewal actually works (certbot renew --dry-run) and to monitor expiry, especially as Let’s Encrypt moves to 64-day and then 45-day certificates.

Key takeaways

• Decide first: managed or self-managed, a supported OS release, panel or not, and location. Installing cPanel later means rebuilding the server.
• Lock down access: a named sudo user, Ed25519 keys, no password or root SSH login, checked with sshd -t and sshd -T while a second session stays open.
• Default-deny firewall: allow 22, 80 and 443 only; UFW on Ubuntu and Debian, firewalld on AlmaLinux and Rocky Linux.
• Automate patching: unattended-upgrades or dnf-automatic with apply_updates = yes, plus a separate schedule for application updates.
• Automate TLS renewal: keep port 80 open for HTTP-01 and plan for shorter certificate lifetimes from 2027.
• Test your backups: keep copies off the server and do a restore.
• Monitor with alerts that reach a person: uptime, disk, certificates and backup jobs.

Sources

• Ubuntu Server documentation: OpenSSH server, Firewalls, Automatic updates, User management
• Canonical: Ubuntu release cycle
• Debian: Releases, Long Term Support
• AlmaLinux: Release notes and support dates
• The CentOS Project: CentOS Linux EOL
• OpenBSD manual pages: sshd_config(5), ssh-keygen(1)
• firewalld: Open a port or service
• DNF: DNF Automatic
• fail2ban: Project repository
• cPanel: System requirements, Installation guide
• Let’s Encrypt: Challenge types, Decreasing certificate lifetimes to 45 days, 64-day certificate lifetimes coming Feb 2027
• EFF: Certbot instructions
• Google Search Central: Changing your web hosting and SEO
• Center for Internet Security: CIS Benchmarks
• Canadian Centre for Cyber Security: Top 10 IT security actions (ITSM.10.089), Baseline cyber security controls for small and medium organizations

About the author: This article was written by the team at 4GoodHosting, a Canadian web hosting company operating since 2002 with servers in Vancouver and Toronto. This article is a guest contribution to P4 Emachines.