![[DoRoyal] Logo](https://cdn.doroyal.com/2026/08/DoRoyal_by_Sidular-1-scaled.png)
An unmanaged VPS gives you a clean server with dedicated resources and the freedom to configure it your way. That freedom is the point, but it also means the responsibility is yours. This guide to unmanaged VPS setup focuses on the work that matters before you point a domain, install an application, or invite traffic onto the server.
A VPS is a good fit when shared hosting limits your control, but you still want predictable costs and a smaller footprint than a dedicated server. It is less suitable if you do not have time to handle updates, security alerts, and recovery work. There is no shame in choosing managed hosting for a business-critical site. The right choice depends on who will maintain the system after launch day.
Start With a Clear Server Plan
Before logging in, decide what the VPS will run. A single WordPress site, several small PHP applications, a Node.js service, or a staging environment can all work well on a modest server. The software stack, expected traffic, and amount of stored data should drive your decisions about memory, storage, and CPU capacity.
For most web workloads, start with a current long-term-support Linux distribution. Ubuntu LTS and Debian are common choices because their package ecosystems and documentation are extensive. AlmaLinux is a sensible option when you prefer a Red Hat-compatible environment. Pick one you can support comfortably rather than switching distributions for marginal differences.
Write down a few operational details before you begin: the server IP address, the hostname you intend to use, the domain names involved, the application stack, and where backups will live. This sounds basic, but it prevents a common problem: configuring a server first and deciding how it should be organized later.
Guide to Unmanaged VPS Setup: Secure Access First
Your first login is usually through SSH as root, using the credentials supplied with the server. Change the initial password immediately if one was provided. Better yet, set up SSH key authentication from your local computer before doing anything else.
Generate a key pair locally if you do not already have one, then place the public key in the server’s authorized keys file. Once key-based login works, create a non-root administrative user and give that account sudo access. On Debian or Ubuntu, the basic pattern looks like this:
bash adduser adminuser usermod -aG sudo adminuser
Log in as the new user in a separate terminal before closing your root session. Confirm that sudo works. Only then should you consider changing SSH settings to disable direct root login and password authentication. Make those changes carefully. A typo in the SSH configuration can lock you out, so keep an existing session open while testing a new one.
Use a nonstandard SSH port only if it fits your security policy, but do not treat it as meaningful protection. SSH keys, restricted access, timely patching, and strong account practices do the real work. If your hosting account includes a firewall or console access option, know where it is before you need it.
Apply Updates Before Installing Applications
A newly provisioned image may already be behind on security patches. Update the operating system packages early, then set a reasonable routine for checking them. On Debian or Ubuntu, that commonly starts with:
bash sudo apt update sudo apt upgrade
On AlmaLinux, use the appropriate dnf commands instead. Do not paste commands intended for one distribution into another without checking what they do. Package names, service locations, and firewall tools vary.
Automatic security updates can reduce the risk of missed patches, especially for a small personal site. For custom applications, test updates in staging when possible. The trade-off is simple: fully manual updates give you more control, while automation reduces the chance that routine maintenance gets forgotten.
Set Up a Firewall and Basic Abuse Protection
A server connected to the internet will receive unsolicited login attempts. That is normal. Your job is to expose only the services you need.
For a typical web server, allow SSH, HTTP, and HTTPS. Block everything else by default. Ubuntu users often manage this with UFW; other distributions may use firewalld. Before enabling a firewall rule set, explicitly allow your SSH port. Otherwise, a firewall can turn a five-minute task into a support request.
Install and configure Fail2ban if you expose SSH or other login services. It can temporarily block IP addresses after repeated failed authentication attempts. It is helpful, not a replacement for SSH keys and strong credentials. Review its logs occasionally so you understand whether it is blocking real attacks or a legitimate user who mistyped a password.
Also check the provider-level network controls available with your VPS. A host firewall can provide another layer, particularly when you want to restrict administrative access to a known office IP or VPN range.
Build the Web Stack for the Site You Actually Have
The standard web stack is not always the best stack. Nginx is efficient for static files and reverse proxy use cases. Apache remains practical when an application depends on .htaccess rules or familiar shared-hosting behavior. PHP-FPM is generally preferable to running PHP through an older embedded module, while Node.js applications commonly sit behind Nginx.
Keep the first deployment simple. Install the web server, database engine if required, the right language runtime, and only the extensions your application needs. Every extra service adds update work and another possible failure point.
Create separate system users and separate site directories when hosting more than one project. Avoid placing application files in a shared writable directory. Set file ownership deliberately, keep configuration files containing passwords out of public web paths, and limit write permissions to directories that genuinely need them, such as uploads or cache folders.
For a WordPress site, this means using a unique database and database user, setting proper file permissions, and protecting the WordPress configuration file. It also means keeping plugins and themes under control. A VPS does not make outdated application code safe.
Add HTTPS Before Going Live
Set DNS records only after the web server is ready to answer for the domain. Then install a TLS certificate and redirect HTTP traffic to HTTPS. Test the certificate renewal process rather than assuming it will work indefinitely.
If you use a reverse proxy, CDN, or external DNS provider, document which service controls each layer. Many site outages come from a change made in the wrong dashboard, not from a complicated server problem.
Treat Backups as a Recovery System
A snapshot is useful, but it is not a complete backup strategy. Snapshots can help you recover a whole server after a bad update or configuration change. They are less convenient when you only need to restore one database table, one site file, or yesterday’s version of a configuration file.
Use both application-aware backups and off-server storage. For a database-backed site, back up the database separately from the file system. Store copies outside the VPS so a server failure, accidental deletion, or compromised account does not remove every copy at once.
A practical schedule might include daily database backups, daily or weekly site file backups depending on how often content changes, and a periodic server snapshot before major upgrades. The exact frequency depends on how much data you can afford to lose. A brochure site may tolerate a weekly file backup. An online store usually cannot.
Most importantly, perform a restore test. Download a backup, restore it to a test location, and confirm that the site and database work together. A backup that has never been restored is only an assumption.
Monitor the Small Things That Become Big Problems
You do not need an enterprise monitoring platform for every VPS, but you do need visibility. Check disk space, memory pressure, CPU usage, service status, certificate expiration, and backup results. Disk exhaustion is especially common because logs, cached files, database growth, and old backups accumulate quietly.
Use log rotation, review web server error logs after deployments, and watch for repeated authentication failures. Set alerts where possible for low disk space and failed backups. These are ordinary operational checks, but they catch many issues before visitors notice them.
Keep a small server notes file with installed services, configuration changes, renewal dates, backup locations, and recovery steps. If another developer needs to help later, or if you revisit the VPS six months from now, those notes save real time.
DoRoyal’s unmanaged VPS plans are best approached with this same mindset: practical resources are valuable when paired with a clear maintenance routine. Build the server in stages, test each change while access is still easy, and leave yourself a documented path back when something needs repair.
