Most managed WordPress hosts run Nginx. That’s worth knowing before you start comparing, because it means “Nginx hosting” on its own tells you very little — it’s close to table stakes at this end of the market, and two hosts running the same web server can deliver very different results.
What actually separates them is everything around Nginx: how many caching layers sit in front of it, how PHP is resourced, whether the database can scale independently, and how much of the configuration you’re allowed to touch. This guide covers what Nginx genuinely does for a WordPress site, what it doesn’t, and the specific questions worth asking a host before you move.
Want the performance without the tuning? ConvesioHost runs every WordPress site on an auto-scaling container cluster with three caching layers and a 99.999% uptime guarantee — and migration is handled for you. See plans and pricing →
What “Nginx WordPress hosting” means
Nginx is a web server. It’s the software that receives a browser’s request and decides what to send back — a cached HTML file, an image, or a request passed to PHP to be rendered. “Nginx WordPress hosting” just means the host uses Nginx for that job rather than Apache.
The reason it became the default for high-traffic WordPress is architectural. Apache traditionally assigns a process or thread per connection, so memory use climbs with concurrency. Nginx uses an event-driven model where a small, fixed number of worker processes handle thousands of connections each, so it stays flat under load and is unusually good at serving static files quickly.
For the full technical comparison, see Apache vs Nginx: Comparing the Web Servers. The rest of this guide assumes you’ve settled that question and are choosing a host.
What Nginx does for your site — and what it doesn’t
It’s worth being precise here, because a lot of hosting marketing implies Nginx alone will make a slow WordPress site fast. It won’t.
What Nginx genuinely does well:
Working as a reverse proxy. Sitting in front of application servers, terminating SSL, and routing requests — which is what makes load-balanced and clustered setups possible.
Serving static files. Images, CSS, JavaScript and fonts go straight from disk to visitor with minimal overhead. On a media-heavy site this is most of your requests.
Handling concurrency. Thousands of simultaneous connections without the memory growth that used to force people onto bigger servers.
Serving cached pages. When a rendered page is already in the cache, Nginx can return it without ever waking PHP — typically single-digit milliseconds.
What Nginx does not do:
Cache anything by itself. Nginx can serve a cache; whether a useful one exists, what invalidates it, and whether logged-in users bypass it are all configuration decisions your host makes.
Speed up an uncached page. A page that misses the cache still has to run PHP and query the database. Nginx is waiting on those, not accelerating them. If your bottleneck is a slow plugin or an unindexed query, changing web server does nothing.
Fix a slow database. Most genuinely slow WordPress pages are slow in the database, which sits behind the web server entirely.
Add capacity. Nginx uses the resources it’s given more efficiently. It cannot give your site more PHP workers or more CPU.
The practical upshot: once you’ve confirmed a host runs Nginx — and at the managed end of the market, most do — that box is ticked and the interesting questions are all about what surrounds it.
The Questions That Actually Decide Performance
Ask a prospective host these. The answers tell you far more than the web server name does.
- How many caching layers are there, and what invalidates them? A serious setup has three: a page cache holding rendered HTML, a CDN serving static assets near the visitor, and an object cache holding database query results in memory. Ask what happens when you update a post — if purging is manual, or slow, you’ll be choosing between stale content and no cache at all.
- How is PHP resourced, and what happens when it runs out? PHP workers are the real ceiling on how many uncached requests your site can handle at once. When they’re saturated, requests queue and the site feels slow even though nothing has crashed. Ask how many you get, and — more importantly — whether they scale automatically under load or whether you have to upgrade plans.
- Is the database on the same machine as the web server? If it is, a traffic spike and a heavy query compete for the same resources. Separating them is what allows either to be scaled without touching the other.
- Can I edit the Nginx configuration? This one surprises people, and it matters more than it sounds — see the next section.
- What happens when a server fails? Not “what’s your uptime number,” but mechanically: does traffic move automatically, and does it move to another machine in the same building or a different data center?
- Is migration included, and who does it? Moving a WordPress site is straightforward until it isn’t. The difference between “we have a migration plugin” and “our engineers will move it for you” is significant.
- What’s the backup cadence, and where do backups live? Daily is common; more frequent database backups matter if you take orders. Backups stored on the same infrastructure they’re protecting aren’t really backups.
How Much Nginx Control Do You Actually Get?
Convesio sits in the ‘managed platform’ column here — Nginx is included and tuned at the platform level, with common rules available through support rather than direct config access.
Managed hosts differ enormously here, and it’s rarely on the pricing page. Three broad tiers:
| Unmanaged VPS | Managed WordPress host | Managed platform | |
|---|---|---|---|
| Who installs and tunes Nginx | You | The host | The host |
| Can you edit nginx.conf? | Yes, fully | Usually not — rules go through support | Usually not — common rules exposed in the dashboard |
| Custom redirects and headers | Anything you want | Often a support ticket | Dashboard, or a ticket |
| Who patches it | You | The host | The host |
| When something breaks at 2am | You | Their support | Their support |
| Best for | Teams with a sysadmin and unusual requirements | Most WordPress sites | Sites where traffic is spiky or business-critical |
WP Engine’s own support documentation, for example, confirms customers can’t directly edit nginx.conf — but it’s not purely a support-ticket process either. Common rule types (redirects, headers, access rules) are available self-service through WP Engine’s “Web Rules Engine” dashboard tool, while anything outside that scope still requires a support request, and not every rule type can be added at all.
This is not a criticism of managed hosting; it’s the trade you’re making, and it’s the right trade for most people. But if your site depends on a specific rewrite rule, a custom header, or a reverse proxy configuration, find out before you migrate whether you’ll be able to set it up yourself or will be filing a ticket every time it changes.
Switching Hosts Without Breaking Things
If you’ve decided to move, a few things save most of the pain:
- Inventory your custom server rules first. Rewrites, redirects, custom headers, IP blocks, anything in
.htaccessif you’re coming from Apache..htaccessfiles do not work on Nginx — every rule in them needs translating, and this is the single most common thing that silently breaks in a migration. - Check your caching plugin. Many hosts run their own caching at server level and either don’t need a plugin or actively conflict with one. Ask which plugins they support before you move, not after.
- Test before you point DNS. Any host worth using will let you run the site on a temporary URL first.
- Lower your DNS TTL a day ahead, so cutover propagates in minutes and rollback stays cheap.
- Test with caching switched on. Almost every “it worked in staging” incident comes from staging having caching disabled.
- Watch real user speed for a week, not just a one-off speed test on the homepage. Test a category page, a search result, and a logged-in page — the ones that can’t be cached.
Hosts that include white-glove migration do most of this for you, which is worth more than it sounds: the hard part isn’t copying files, it’s knowing which rules and plugins will break.
Where Convesio Fits
Convesio runs on Nginx — tuned, patched, and managed as part of the platform, so you get the performance characteristics above without touching a config file. The difference isn’t the web server; it’s everything Convesio layers around it.
- Three caching layers as standard — edge caching for rendered pages, a built-in CDN for static assets, and Memcached for objects and transients.
- Nginx, fully managed — no config file to edit, no patching, no 2am tickets when something needs tuning.
- PHP that scales in real time. Sites scale from a small number of workers into the double digits and burst well beyond that during spikes, without reprovisioning, plan changes or migration.
- A containerised cluster per site, with the database separated from the application layer so each can scale independently.
- Cross-data-centre failover. Every site has a redundant copy in a second data centre; if the primary fails, traffic moves automatically, and during a prolonged outage the secondary is promoted without anyone intervening.
- Backups that live elsewhere. Daily file backups plus database backups every two hours, taken on a replica so production isn’t affected, retained two weeks with monthly snapshots kept for a year.
- Automatic rollback on fatal errors — the platform reverts to the last working state rather than leaving a white screen up.
- A 99.999% uptime guarantee, unlimited visitors, and white-glove migration on every plan.
Plans start at $50/month, with dedicated CPU added as you grow. Compare plans and pricing →
Stop tuning web servers. ConvesioHost gives your WordPress site an auto-scaling cluster, three caching layers, and automatic failover — with the migration handled for you. See plans and pricing → or see how auto-scaling works →