A colleague pinged me about a site where the caching plugin had stopped existing. Not deactivated. Gone from the plugin list, gone from the filesystem. Nobody on the team had touched it.<\/p>\n\n\n\n
The host had removed it. It was on their disallowed list, a routine scan found it, and the platform did exactly what its documentation said it would do. Everyone had agreed to that when they signed up. Nobody had read it.<\/p>\n\n\n\n
That incident is the whole managed WordPress hosting vs VPS argument in miniature, and it has almost nothing to do with page speed. Both models can serve a fast WordPress site. They differ on which failures land on you, which land on someone else, and which ones stay invisible until the worst possible moment.<\/p>\n\n\n\n
This post compares the two the way I’d compare them for a client: an honest profile of each, the costs that never appear on the invoice, a procedure for modelling the real number, and the decision rules I actually use. No benchmark charts, because your theme and your plugin count will dominate anything the host does.<\/p>\n\n\n\n
Most comparisons frame this as control versus convenience. True, but useless, because it doesn’t tell you what to buy. The framing that predicts regret is: when something breaks, whose problem is it, and how fast can they fix it?<\/p>\n\n\n\n
Split the failure surface into layers and the answer gets concrete:<\/p>\n\n\n\n
The bottom two rows never move. A managed platform will not make your bloated page builder fast, and it will not stop a vulnerable plugin from being exploited. It moves the middle three rows off your plate and charges you in money and in flexibility.<\/p>\n\n\n\n
The strongest argument isn’t performance. It’s that the boring, high-consequence work gets done by people whose job it is, on a schedule, whether or not you remember.<\/p>\n\n\n\n
If nobody on your team wants to own a Linux box, that list is decisive. The rest of this section is about what you’re trading away.<\/p>\n\n\n\n
This is the cost that bites hardest, because it doesn’t look like a technical constraint until the invoice arrives.<\/p>\n\n\n\n
Most managed plans meter “visits” rather than bandwidth or CPU, and the definition is narrower than it sounds. WP Engine defines a billable visit<\/a> as one unique IP address logged per day, with static assets like images, CSS and JavaScript excluded, and known and suspected bot user agents filtered out. Kinsta counts<\/a> the sum of unique IPs seen within each 24-hour period across the plan, and also sells bandwidth-metered plans as an alternative. Flywheel filters IPs belonging to known bots, spammers and attackers before counting.<\/p>\n\n\n\n Three consequences follow, and they’re the ones people miss:<\/p>\n\n\n\n A VPS has the opposite failure mode. Bad traffic costs you CPU and RAM, not money, right up until it exhausts them and the site falls over. One model converts load into a bill, the other converts it into an outage. Pick the one you’d rather explain to whoever owns the site.<\/p>\n\n\n\n Managed hosts publish disallowed plugin lists and they enforce them. WP Engine documents that disallowed plugins are found by periodic scans of the site’s filesystem, the owner is notified, and the plugin is removed. That’s not a threat, it’s the operating model, and it’s why the incident I opened with was nobody’s fault.<\/p>\n\n\n\n The banned categories are consistent across vendors, and the reasoning holds up in each case:<\/p>\n\n\n\n None of that is unreasonable. The problem is when a plugin your business depends on lands in one of those buckets, or when a host adds something to the list later. Before migrating, read the current disallowed list for that specific host and diff it against your live active plugins. Ten minutes, and it’s the highest-value thing you can do in a hosting evaluation.<\/p>\n\n\n\n A managed WordPress platform runs WordPress. If your project also needs a Node service, a Python worker, a queue, or a self-hosted analytics instance, that’s a second bill somewhere else. On a VPS those things are free in cash terms because you already own the machine. They cost you memory and attention instead. Whether that’s a good trade depends on whether you were going to need them anyway.<\/p>\n\n\n\n Here’s the one that actually ends projects. Backups on a self-managed VPS fail silently. The cron entry runs, the exit code goes nowhere, the destination bucket quietly rejects writes after a credential rotation, and nothing tells you. You find out the day you need it, which is also the day you have no other option.<\/p>\n\n\n\n The fix isn’t a better tool. Restic and BorgBackup are both excellent and neither will save you. The fix is a restore drill on a schedule, into a scratch directory, where you verify the data is actually there.<\/p>\n\n\n\n Adjust the repository path and database names to your own. The shape is the point: restore somewhere harmless, then check a row count that would be non-zero on a healthy site. A backup you haven’t restored is a hypothesis, not a backup. Uptime checks from something like UptimeRobot tell you the site is down; they tell you nothing about whether you can get it back.<\/p>\n\n\n\n The second invisible cost is the gap between “updates are available” and “updates are applied and the affected services have actually restarted”. Upgrading a package without restarting the process leaves the old, vulnerable code resident in memory. That’s why security scanners and package managers disagree so often.<\/p>\n\n\n\n Run those on any VPS you inherited from someone else. The output is usually educational. Then there’s the WordPress layer, which stays yours regardless of hosting model:<\/p>\n\n\n\n Sticker price comparisons are how people talk themselves into the wrong answer in both directions. This procedure produces a number you can defend.<\/p>\n\n\n\n Step two is worth doing properly, because it’s the number nobody has. On Nginx with the standard combined log format, this gets you close:<\/p>\n\n\n\n Field positions assume the combined log format; adjust the column numbers if you’ve customised This gets presented as two options. There are four, and the middle two get skipped far too often.<\/p>\n\n\n\n If you’re leaning toward a VPS mainly because managed pricing looks steep, look at options two and three before committing to a bare Linux box.<\/p>\n\n\n\n These are the rules I apply, in order. The first match usually settles it.<\/p>\n\n\n\n For one site, usually not once you price your own time honestly. For several sites, usually yes, and the gap widens with each site you add. The crossover sits somewhere around three to five sites for most people, depending on what your hours are worth and how much the sites change.<\/p>\n\n\n\n They measure different things. Analytics counts browser sessions that executed its JavaScript, so it misses anything blocking scripts and misses non-browser clients entirely. Your host counts requests reaching the server, deduplicated by IP per day. Bot filtering closes some of the gap but never all of it. The two numbers are not supposed to match.<\/p>\n\n\n\n Generally no. Managed WordPress platforms run WordPress and nothing else. A background worker, a separate API, a queue or a self-hosted analytics instance needs a VPS or a second platform. Factor that second bill into the comparison.<\/p>\n\n\n\n It depends on the host, but the documented pattern at WP Engine is that periodic filesystem scans detect it, you get notified, and the plugin is removed. Check the specific host’s current policy and enforcement mechanism before migrating, and check it against your live plugin list rather than what you assume is installed.<\/p>\n\n\n\n You need caching. Whether it’s a plugin is a design choice. The strongest setup is full-page caching at the web server or CDN layer plus a persistent object cache in Redis or Memcached, which handles the repeated database queries page caching can’t touch. A page cache alone leaves logged-in traffic and admin requests hitting the database on every load.<\/p>\n\n\n\n It’s real, but the scope varies enormously and the word isn’t standardised. Ask specifically: who applies OS security patches, who restarts services afterwards, who owns backups and where they live, whether restores are tested, and whether the WordPress stack is in scope or the coverage stops at the operating system. Get the answers in writing before comparing prices.<\/p>\n\n\n\n Moving files and the database is the easy part. The work is everything the platform did invisibly: redirect rules living in the host’s dashboard, cache purging behaviour, transactional email, TLS renewal, and any deployment workflow tied to the platform. Plan a parallel run with low DNS TTLs rather than a cutover, and keep the old plan alive until the new one has survived a full traffic cycle.<\/p>\n\n\n\n Managed WordPress hosting vs VPS isn’t a performance question, and it isn’t really a price question either. It’s a question about which failures you’re equipped to own.<\/p>\n\n\n\n Managed hosting converts operational risk into a predictable bill and a set of constraints you have to live inside. A VPS converts that bill into flexibility plus a standing obligation to do the boring work: patch, restart, and prove your restores actually restore. Both are defensible. What isn’t defensible is buying a VPS because it looked cheap and then skipping the work, which is the most common failure in this whole category and the one that ends with a rebuild from a backup nobody ever tested.<\/p>\n\n\n\n Run the restore drill. Whatever you choose.<\/p>\n\n\n\n Most of the hosting work I get asked for is one of these. If it looks like your situation, I can help:<\/p>\n\n\n\n Send me something concrete and I’ll tell you what I see: an access log sample, your current plan and traffic numbers, your active plugin list, or the output of the commands above. That’s usually enough for a straight answer before either of us talks about scope.<\/p>\n\n\n\n\n
The plugin policy is a real constraint<\/h3>\n\n\n\n
\n
You get one shape of application<\/h3>\n\n\n\n
Running WordPress on your own VPS, assessed honestly<\/h2>\n\n\n\n
Where it genuinely wins<\/h3>\n\n\n\n
\n
The failure that stays invisible: the backup you never restored<\/h3>\n\n\n\n
# Restore the newest snapshot into a scratch path, never over the live site\nrestic -r \/srv\/backups\/wp restore latest --target \/tmp\/restore-drill\n\n# Confirm the dump is real and not a zero-byte file or a truncated\n# write from a run that died halfway through\nls -lh \/tmp\/restore-drill\/db\/\nhead -n 20 \/tmp\/restore-drill\/db\/site.sql\n\n# Load into a throwaway database and count what came back.\n# If wp_posts is empty, your backups have been failing for weeks.\nmysql -u drill -p drill_db < \/tmp\/restore-drill\/db\/site.sql\nmysql -u drill -p -e \"SELECT COUNT(*) FROM drill_db.wp_posts;\"<\/code><\/pre>\n\n\n\nPatching debt compounds quietly<\/h3>\n\n\n\n
# RHEL family (AlmaLinux, Rocky, CentOS Stream)\n# What security updates are outstanding?\nsudo dnf updateinfo list security\n\n# After applying them: does anything still need a restart?\n# Exit 0 means no reboot required, exit 1 means reboot required.\nsudo dnf needs-restarting -r\n\n# Debian and Ubuntu: what would unattended-upgrades actually do?\nsudo unattended-upgrade --dry-run --debug<\/code><\/pre>\n\n\n\n# Do the core files match the official checksums for this version?\n# A mismatch means a modified core file or an active compromise.\nwp core verify-checksums\n\n# How many plugins are behind?\nwp plugin list --update=available --format=count\n\n# Which tables are eating the disk? Usually wp_options, wp_postmeta,\n# or a logging plugin nobody remembers installing.\nwp db size --tables --format=table<\/code><\/pre>\n\n\n\nModel the cost before you argue about it<\/h2>\n\n\n\n
\n
# Unique client IPs in the log. A rough upper bound on metered \"visits\".\nawk '{print $1}' \/var\/log\/nginx\/access.log | sort -u | wc -l\n\n# Closer to how hosts count: ignore static assets, since most platforms\n# exclude images, CSS and JS from billable visits.\nawk '$7 !~ \/.(css|js|png|jpg|jpeg|gif|svg|webp|woff2?|ico)$\/ {print $1}' \n \/var\/log\/nginx\/access.log | sort -u | wc -l\n\n# What is actually hitting you? User agents by request count.\n# If the top entries are crawlers, that is your overage risk.\nawk -F'\"' '{print $6}' \/var\/log\/nginx\/access.log | sort | uniq -c | sort -rn | head -20<\/code><\/pre>\n\n\n\nlog_format<\/code>. The third command is the interesting one. If crawlers dominate your traffic, visit-metered hosting will charge you for whatever the host’s filtering misses, and that’s a risk you can quantify before signing up rather than after.<\/p>\n\n\n\n
\n\n\n\nThe middle ground worth looking at first<\/h2>\n\n\n\n
\n
How I’d decide between managed WordPress hosting vs VPS<\/h2>\n\n\n\n
\n
Arguments that don’t survive contact<\/h2>\n\n\n\n
\n
Frequently asked questions<\/h2>\n\n\n\n
Is a VPS actually cheaper than managed WordPress hosting?<\/h3>\n\n\n\n
Why does my managed host report more visitors than Google Analytics?<\/h3>\n\n\n\n
Can I run other applications alongside WordPress on managed hosting?<\/h3>\n\n\n\n
What happens if I install a disallowed plugin?<\/h3>\n\n\n\n
Do I still need a caching plugin on a VPS?<\/h3>\n\n\n\n
Is managed VPS hosting a real middle ground or just marketing?<\/h3>\n\n\n\n
How hard is migrating from managed hosting to a VPS?<\/h3>\n\n\n\n
The one thing worth remembering<\/h2>\n\n\n\n
\n\n\n\nNeed a second opinion on your hosting decision?<\/h2>\n\n\n\n
\n