Moving a WordPress site from shared hosting to its own virtual private server is one of the best upgrades you can make. You get dedicated resources, full control over the software stack and, if you host several sites, a much lower cost per site. Many of the sites I manage run on servers I’ve built this way.
But a VPS comes with responsibility. Nobody patches it for you, nobody configures the firewall and nobody notices if backups stop working. A badly set up server is far riskier than a basic shared hosting plan.
This guide walks through the process I use to build a WordPress server on a fresh Ubuntu LTS VPS, using the LEMP stack: Linux, Nginx (pronounced “engine-x”, hence the E), MariaDB or MySQL and PHP. The commands are for Ubuntu, but the steps translate to other distributions with small changes.
Choosing the server
For a single business site with moderate traffic, a VPS with 2 CPU cores and 2 to 4 GB of RAM is a comfortable starting point. WooCommerce stores, membership sites and servers hosting several sites need more memory, mostly for PHP processes and the database.
Choose a data centre close to most of your visitors, and use the current long-term support release of Ubuntu, which receives security updates for years.
Step 1: First login and system updates
Log in as root using the credentials or SSH key provided, then update everything:
Set the timezone, which makes logs and scheduled tasks easier to read:
Use your own timezone, or UTC if the server serves several regions.
Step 2: Create a non-root user
Working as root all the time is risky. Create a regular user with sudo privileges:
Copy your SSH key to the new user, then log in as that user in a new terminal before going further, to make sure it works.
Step 3: Secure SSH
SSH is the front door to your server, and it gets attacked constantly. In /etc/ssh/sshd_config, make these changes:
This disables root login and passwords, allowing only key-based login. Restart SSH with systemctl restart ssh, but keep your existing session open until you’ve confirmed you can log in from a new terminal. Locking yourself out of a fresh server is a rite of passage nobody needs.
Step 4: Set up the firewall
Ubuntu includes UFW, a simple front end for the firewall. Allow only what you need:
If you install Nginx after enabling the firewall, the Nginx Full profile becomes available once Nginx is installed, so you may need to run that line afterwards. Allowing only SSH, HTTP and HTTPS closes off everything else.
Step 5: Install fail2ban
fail2ban watches log files and blocks IP addresses that show malicious behaviour, such as repeated failed SSH logins:
The default configuration protects SSH. Later, you can add jails for WordPress login failures.
Step 6: Enable automatic security updates
Security patches should be applied promptly, even when you’re busy. Unattended upgrades handle that:
This applies security updates automatically. Kernel updates still require a reboot, so check occasionally whether one is pending.
Step 7: Install Nginx
Visit your server’s IP address in a browser, and you should see the Nginx welcome page.
Step 8: Install the database
MariaDB and MySQL both work well with WordPress. I usually use MariaDB:
The secure installation script removes anonymous users and test databases and restricts remote root login. Accept its recommendations.
Then create a database and user for WordPress:
Each site should have its own database and user. That way, a problem with one site’s credentials doesn’t expose others.
Step 9: Install PHP
Install PHP-FPM and the extensions WordPress commonly needs. Use a currently supported PHP version available for your Ubuntu release:
Check which version was installed with php -v. Some setups use a third-party repository to get newer PHP versions than the distribution provides.
Tune PHP settings
In the PHP-FPM php.ini file, adjust a few settings for WordPress:
Create a pool for the site
Rather than running every site under the same user, create a dedicated system user and PHP-FPM pool for each site. This isolates sites from each other. Copy the default pool file, rename it, and change the pool name, user, group and socket path to match the site. Then restart PHP-FPM.
Step 10: Install WordPress
Create the site directory, owned by the site’s user, and install WordPress with WP-CLI:
Run WP-CLI commands as the site’s user rather than root, so files get the right ownership. WP-CLI will generate a random admin password if you don’t set one and display it once, so note it in your password manager.
Step 11: Configure Nginx for the site
Create a server block for the site in /etc/nginx/sites-available, link it into sites-enabled, and include the essential WordPress rules: the try_files permalink line, PHP passed to the site’s PHP-FPM socket, PHP blocked in uploads and sensitive files denied. My separate guide on Nginx configuration for WordPress covers this in detail.
Test and reload:
Step 12: Point the domain and add SSL
Update the domain’s DNS A record to point to your server’s IP address. Once it resolves, use Certbot to get a free Let’s Encrypt certificate:
Certbot updates the Nginx configuration and sets up automatic renewal. Confirm renewal works with certbot renew –dry-run.
Step 13: Set file permissions
Make sure files are owned by the site user and permissions are sensible:
The 600 permission works here because PHP-FPM runs as the site’s own user, which also owns the file. If your setup differs, adjust accordingly.
Step 14: Replace WP-Cron with a system cron
By default, WordPress runs scheduled tasks during page visits. On a server you control, it’s better to run them on a real schedule. Add this to wp-config.php:
Then add a cron job for the site user:
Step 15: Add caching
Install Redis for a persistent object cache:
Then use a Redis object cache plugin in WordPress to connect to it. For page caching, either use Nginx FastCGI caching or a caching plugin with Nginx rules.
Step 16: Set up backups
Backups are not optional on a VPS. At a minimum:
- Daily database dumps and file backups, sent off the server to separate storage with different credentials.
- Provider-level snapshots before major changes.
- Enough history to go back several weeks.
- Regular restore tests.
A simple approach is a script that dumps the database, compresses the site files and uploads both to object storage, run nightly by cron. Many backup tools automate this with encryption and retention rules.
Step 17: Monitoring
Set up:
- External uptime monitoring with alerts.
- Disk space alerts, because full disks cause strange failures.
- Log review, or at least a habit of checking error logs when something seems off.
- Resource monitoring for CPU, memory and load.
Ongoing maintenance
A server needs regular attention: applying updates, checking backups, reviewing logs, renewing anything that doesn’t renew automatically and planning PHP upgrades before old versions reach end of life. If you don’t have time for that, consider a managed server service or have someone maintain it for you.
Document everything
Write down what you installed, which versions, where configuration files live, how backups work and how to restore them. Store the notes somewhere safe, away from the server itself. When something goes wrong at an awkward hour, or when someone else needs to take over, clear documentation turns a stressful scramble into a calm, step-by-step recovery.
Revisit the notes whenever you change something.
Good notes are what make a server maintainable by someone other than you.
Frequently asked questions
Is a VPS faster than shared hosting?
Usually, yes, because resources aren’t shared with hundreds of other sites, and you can tune the stack for WordPress. But a poorly configured VPS can be slower than good managed hosting.
Should I use a control panel?
Control panels make management easier, especially for multiple sites, but add overhead and their own security considerations. For a small number of sites, a clean manual setup is lean and easy to understand. Choose based on your comfort and needs.
How many sites can one VPS host?
It depends on traffic and resources. A modest server can host many small brochure sites, but a single busy store might need a server to itself. Monitor memory and CPU as you add sites.
What’s the biggest mistake people make with a VPS?
Not maintaining it. Unpatched servers, no off-site backups and no monitoring are far more common causes of disasters than any configuration detail.
Final thoughts
A well-built VPS gives WordPress room to breathe: dedicated resources, a tuned stack and full control. The key steps are securing access first, isolating each site, installing a lean LEMP stack, adding SSL, caching and a real cron, and then backing up and monitoring everything. Build it carefully, document what you did and maintain it regularly, and your server will run your sites quietly for years.
