How to Set Up a VPS

VPS setup has three distinct phases with different purposes. The initial configuration phase establishes security and operational foundations: SSH hardening, firewall rules, user accounts, automatic updates. The application setup phase installs and configures the software stack the application needs. The operational setup phase establishes the ongoing systems that keep the server running: monitoring, backup schedules, log management. Skipping or compressing any phase creates technical debt that surfaces as an incident.

The first session on a new VPS should establish the security baseline before any application is deployed. Create a non-root sudo user. Add the SSH public key to that user's authorized_keys. Disable root login in the SSH configuration. Disable password authentication. Restart SSH and verify the new configuration works from a separate terminal before closing the existing session — locking yourself out of a new VPS is a common and easily preventable mistake.

Firewall configuration follows. The default should be deny-all inbound, with explicit allow rules for SSH, HTTP (80), and HTTPS (443). Any other ports should be added only when the specific service that requires them is configured. UFW on Debian/Ubuntu makes this a three-command process. The principle — deny by default, allow explicitly — is more important than the specific tool.

Automatic security updates prevent the most common category of VPS compromise. Unattended-upgrades on Debian/Ubuntu, dnf-automatic on Fedora — these apply security patches without requiring manual attention. They are not a substitute for regular manual updates of application software and non-security packages, but they close the most frequently exploited vulnerability window.

The application stack installation follows the security baseline. Web server, runtime, database, application code, process manager — each in the order that the application's dependencies require. Running the application as a non-root user, with a process manager that restarts it after crashes and enables it on boot, is the operational baseline that most unmanaged VPS tutorials skip or defer.

Monitoring and backups are almost always the last item on the setup list and the first to be omitted when the application is running and attention moves elsewhere. A server with no monitoring runs until it doesn't, with no warning. A server with no backups loses everything on the first serious failure. These are not advanced operational concerns — they are the basic requirements for running a server that doesn't eventually cause a crisis. Setting them up in the first week, while the deployment is fresh, is significantly easier than setting them up during an incident.

Manual setup — SSH in, run commands, configure by hand — is appropriate for a first VPS or a single-server deployment. It builds understanding of what the server is doing and why. The cost is that the configuration exists only in the server's state, not in version-controlled files. Rebuilding the server requires repeating the process from memory or from notes, which is imprecise and slow.

Configuration management tools — Ansible playbooks, shell scripts, Docker Compose files — encode the setup process in files that can be version-controlled, shared, and repeated exactly. The cost is the overhead of writing and maintaining the configuration files, which is higher than running commands interactively. For a single server that won't need to be rebuilt, this overhead may not be justified. For a team managing multiple servers, or for any server that may need to be rebuilt quickly, the investment pays for itself at the first rebuild.

Control panels — cPanel, Plesk, Webmin, CyberPanel — provide a graphical interface for server configuration that reduces the Linux expertise requirement. What you give up is configuration transparency — the panel configures things in its own way, which may conflict with manual configuration and creates dependencies on the panel's own software. For teams comfortable with the panel's model, the tradeoff is often favorable. For teams that may need to understand and modify the server's configuration directly, the panel's abstractions can become obstacles.