Why self-host WordPress on a VPS
Shared hosting splits CPU, RAM and even the database with hundreds of other sites: your speed depends on your neighbors, and SSH access or fine server configuration are often locked down. A dedicated VPS gives you guaranteed resources, full control of PHP-FPM, the web server, the object cache (Redis) and the page cache. For an agency managing several client sites, it also means the ability to isolate everything in containers on a single machine, with backups and deployments under control, where shared hosting imposes its limits and its extra costs.
The gains of a WordPress on VPS
- Guaranteed CPU/RAM resources: no more slowdowns caused by neighbors
- Full control of PHP-FPM, the web server and extensions
- Redis object cache and page cache for response times cut in half
- Full SSH/WP-CLI access to automate maintenance and deployments
- Per-container isolation: several client sites on a single VPS
- Backups and security rules defined by you, without a per-site surcharge
Realistic prerequisites
A 2 vCPU / 2 GB RAM VPS comfortably handles a WordPress site with moderate traffic; move up to 4 GB with Redis, WooCommerce or several sites. You need Docker + Compose, a MariaDB or MySQL database, ideally Redis for the object cache, and a yourdomain.com domain with its SSL certificate. Plan for a bit of PHP tuning (upload_max_filesize, memory_limit) depending on your media and extensions.
Step-by-step deployment
Compose WordPress, MariaDB and Redis
In docker-compose.yml, declare wordpress:php8.3-fpm or wordpress:apache, a mariadb:11 service and redis:alpine. Persist wp-content and the database in named volumes, on an internal Docker network.
Fill in the database and secrets
Pass WORDPRESS_DB_* and strong passwords via environment variables. Add the security keys (salts) generated from the official WordPress API in WORDPRESS_CONFIG_EXTRA.
Launch and install WordPress
Start with docker compose up -d then open your domain for the installation wizard. Better: automate it via WP-CLI (wp core install) for reproducible deployments from one site to the next.
Set up the reverse proxy and SSL
Configure Nginx/Caddy in HTTPS in front of WordPress. Adjust client_max_body_size for uploads, enable gzip/brotli compression and caching of static assets (images, CSS, JS) with long Cache-Control headers.
Enable the Redis object cache
Install an object cache plugin (e.g. Redis Object Cache), point it to the redis service, and enable it: repeated database queries are served from memory, greatly relieving MariaDB.
Harden and back up
Disable file editing in the admin (DISALLOW_FILE_EDIT), limit login attempts, and schedule a nightly backup of wp-content + SQL dump to remote object storage.
For performance that rivals the best managed platforms, add a full page cache upstream of PHP: a plugin generating static HTML files served directly by Nginx (via try_files), or a FastCGI cache module. Your public pages then no longer touch PHP or MariaDB at all, which lets a modest VPS absorb thousands of simultaneous visitors, while keeping the back office and the cart (WooCommerce) excluded from the cache.
The official documentation
For advanced configuration and options specific to the tool, refer to the official WordPress documentation. This guide covers going live on a VPS; the vendor's docs remain the reference for fine-tuning, major upgrades and specific use cases.
