Host WordPress on your own VPS

Why self-host WordPress on a VPS

The gains of a WordPress on VPS

• CPU/RAM allocated to your machine: fewer 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

Step-by-step deployment

1. 01

   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.

2. 02

   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.

3. 03

   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.

4. 04

   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.

5. 05

   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.

6. 06

   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.

7. 07

   Logging in for the first time

   Open the site URL: WordPress starts its five-minute installation — language, site title, then the creation of YOUR administrator username with the password and e-mail address of your choice. Finish it without delay; an unfinished installation is there for the taking by the first visitor.

PHP alert of 21 Oct 2026 (PHP2Shell): updating WordPress does not fix PHP

Check, then fix, in five moves

1. 08

   Read the PHP version actually being served

   The most reliable place is WordPress itself: Tools > Site Health > Info > Server shows the PHP version executing your pages. On a VPS without Docker, be wary of php -v: it queries the command-line binary, which can be a different version from PHP-FPM, the one serving your visitors. Ask the service itself with php-fpm -v (or php-fpm8.3 -v on Debian and Ubuntu).

2. 09

   Check the version inside the container

   With Docker, run docker compose exec wordpress php -v: the image ships a single PHP, so this result holds for the container's FPM or mod_php. Compare it to the patched versions above, staying on the same branch (8.3.x must reach 8.3.36, not 8.4.27).

3. 10

   Pull the updated image

   Run docker compose pull && docker compose up -d. The pull downloads the latest image published for your tag (for example wordpress:php8.3-fpm), and up -d recreates the container on it. Your named volumes keep wp-content and the database. If php -v still shows an old version, the patched image is not yet published for that tag: check back later, or move to another PHP branch if your site supports it.

4. 11

   Restart PHP-FPM

   Updating a package or files does not change the code already loaded by running processes. On a classic server, restart the service with systemctl restart php8.3-fpm (adapt the version number); with Docker, recreating the container is enough, otherwise docker compose restart wordpress. A plain reload is less reliable than a restart when you need every worker renewed.

5. 12

   Look for signs of exploitation

   An update closes the door; it does not tell you whether someone already walked in. Go through the Nginx or Apache access and error logs (docker compose logs --since 72h wordpress with Docker) looking for PHP-FPM worker crashes, repeated out-of-memory messages and unusual high-volume requests. Inside wp-content, list recently modified .php files with find wp-content -name '*.php' -mtime -7, especially under uploads, where no script should live. At the slightest doubt, restore from a clean backup and change passwords and salts.

6. 13

   Automate the check with WP-CLI and cron

   Note that wp --info reports the command-line PHP version, not the PHP-FPM one: keep it for scripts, not for judging web exposure. Instead, schedule a weekly cron job that runs docker compose pull, then compares the output of docker compose exec wordpress php -v with the expected version and emails you on any mismatch. That way the next PHP security alert no longer depends on your memory.

7. 14

   Verify again

   Reopen Site Health and rerun php -v in the container: both must show a patched version. Write the date in your maintenance log, and repeat the routine for every new PHP security release.