Self-hosting WordPress is neither a stylistic exercise nor a marginal saving: it is a trade-off between the comfort of a managed platform and control over your own stack. This guide describes the configuration that holds on a virtual private server, the components it relies on, and the points where self-hosting costs more than it returns.
What “self-hosting” covers
Three models coexist, and confusing them distorts every cost comparison.
| Model | What you manage | Relevant when |
|---|---|---|
| Shared hosting | Nothing beyond the site | One site, low traffic, no systems skills |
| Managed WordPress | The site and its content | Comfortable monthly budget, no appetite for systems work |
| Self-administered VPS | System, web server, database, backups, security | Several sites, terminal skills, need for control |
The third model is only reasonable once you can read an Nginx configuration and an error log. Below that, the apparent saving is paid for in downtime.
The stack that holds
The panel: light rather than exhaustive
Legacy panels charge a licence, hold 1.5 to 2 GB of memory before serving a page, and interpose an abstraction between the operator and the server. On a VPS you administer yourself, that abstraction becomes the main obstacle to diagnosis.
The components and their roles
- Nginx at the front, with a readable and overridable virtual host.
- PHP-FPM, with a version per site — essential to run an older PrestaShop alongside a recent WordPress.
- MariaDB or MySQL, chosen explicitly at installation.
- Redis for object caching: this is the component producing the clearest gain on WordPress, ahead of any page cache.
- One page cache — Nginx FastCGI cache, or a reverse proxy. One only, never two.
- Let’s Encrypt with automatic renewal.
The rule that prevents the most outages: one layer per function. Two page caches unaware of each other produce stale pages nobody knows how to purge.
The stacked-layers trap
This is the most frequent error on installations that have been running for a while. A page cache in a plugin, a second in a reverse proxy, a third at the CDN provider, plus an asset-rewriting module: each caches correctly, none knows how to purge the others. The symptom is always the same — a deployed change that stays invisible.
A sound configuration comes down to three decisions: one object cache (Redis), one page cache (a single one, purged on publication), and one minifier (one, or none).
Security: a baseline, not a fortress
Most of what hits a small site is automated noise. Three components cut it: an application firewall, network-level banning, and revocable credentials for integrations.
Backups: the only measure that repairs
Every other measure prevents; only backup repairs. Three requirements make it useful:
- Off the production server — a backup on the same machine protects against nothing.
- Encrypted, with the passphrase stored somewhere other than the backup tool.
- Restored at least once. A backup never restored is a hypothesis, not a guarantee.
What self-hosting does not solve
- Round-the-clock availability: without on-call cover, a night-time incident lasts until morning.
- Sudden traffic spikes: a single VPS has a ceiling, and multi-node orchestration is another discipline.
- Email: running your own sending server exposes you to disproportionate deliverability problems. Delegating to a specialised service remains the right call — see the deliverability guide.
Steering after launch
A self-hosted site is monitored on three axes only: availability, response time, and volume of application errors. The rest is editorial steering, covered in GA4 and Search Console.
Articles in this section
- CloudPanel: self-hosted WordPress without a heavyweight panel
- WordPress hardening: the minimal security baseline
- Command-line tools for web development
This page is updated as articles are published in the DevOps & servers and Security sections.