WordPress on Kamatera: fast, but you are the sysadmin

A $4 Kamatera server will serve a WordPress site faster than most entry-level shared hosting, and it will also make you responsible for everything shared hosting was quietly doing for you. Whether that is a good deal depends on one question: do you want to be the person who notices that PHP 8.2 reached end of life?

This piece is about that trade rather than about whether WordPress runs — it runs fine. What follows is what you gain, what you inherit, and when a managed host is simply the better buy.

Why a VPS is faster than shared hosting for WordPress

Shared hosting puts hundreds of sites on one machine and divides the resources between them, which works until one of your neighbours gets traffic. The slow afternoon that has nothing to do with anything you changed is the defining experience of cheap shared hosting.

On a VPS the memory and CPU are allocated to you. Combined with NVMe storage and a PHP-FPM configuration you chose, the practical result is a quicker and — more importantly — a more consistent time to first byte. Consistency is the part that matters: Core Web Vitals measure real visits, and a host that is fast on average but occasionally terrible scores worse than one that is merely fine all the time.

Being straight about the size of the win: against good managed WordPress hosting, a self-managed VPS is not dramatically faster, because managed hosts run page caching and a CDN in front of everything. The gap is against cheap shared hosting, which is what most people are leaving.

What a WordPress site actually needs

The $4 plan's 1 GB of RAM will run WordPress. It will not run WordPress plus MySQL plus a few plugins plus a backup job at the same time without reaching for swap.

• A small site or a staging copy. The base plan — 1 vCPU, 1 GB. Fine, and genuinely better than shared hosting at the same price.
• A real production site. 2 Type B cores and 4 GB of RAM, with 60 GB of disk. This is the build most people should start from, and it lands in the low thirties a month.
• WooCommerce. Add memory before cores — a shop's database is the bottleneck, and cart and checkout pages cannot be page-cached. 8 GB is not excessive.

Keep the boot disk modest and put uploads on a second volume. Kamatera's boot volumes expand but never shrink, so an oversized one is a permanent charge at $0.05 per GB per month.

How to run it without living in the terminal

Nobody should hand-compile nginx to run a blog. Two routes make this reasonable:

1. A control panel. CyberPanel, CloudPanel or HestiaCP are free, install in one command, and give you site creation, TLS certificates, database management and scheduled backups through a browser. This is the sensible default and it closes most of the gap to managed hosting. cPanel and Plesk do the same with a monthly licence on top, which is worth it only if you already know them.
2. Docker. WordPress, MariaDB and a reverse proxy as three containers, with Caddy handling certificates automatically. Cleaner to move between hosts and easier to version, and it assumes you are comfortable when a container will not start. The same approach as our n8n self-hosting guide, which walks the Docker and Caddy setup through step by step.

Either way, start from the hardened setup rather than installing WordPress on a fresh root-login box. A WordPress site is the single most probed thing on the internet.

What you inherit on day one

This is the list managed hosting exists to absorb, and all of it becomes yours:

• Updates. WordPress core, plugins and themes, plus the operating system, PHP, MySQL and nginx underneath. Unattended security upgrades handle the OS; the rest is you.
• Backups that are somewhere else. A snapshot on the same provider is not a backup — it survives your mistake and not the provider's. Something offsite, tested at least once.
• TLS renewal. Automatic with any of the panels above, right up until the day it is not, and nobody is watching the certificate but you.
• Email. A new VPS IP has no sending reputation, so WordPress's password-reset and order-confirmation mail lands in spam. You need a relay — a transactional provider wired in through SMTP. Budget for it; it is the single most-forgotten piece of a self-hosted WordPress migration.
• Security. Fail2ban, a firewall that only exposes 80, 443 and your SSH address, and some discipline about plugins. The firewall guide covers the network half.

Moving an existing site across

Migrating is where most of the pain in this project actually is, and it is mostly avoidable with one decision: move the site first, change the DNS last.

1. Build the new server and get a copy of the site running on it before touching the domain. Your control panel will have an import, or use a migration plugin, or do it by hand — files with rsync, database with mysqldump. Either way, the goal is a working copy nobody is looking at yet.
2. Test it through your hosts file, not through a temporary subdomain. Pointing a staging. subdomain at the new server means WordPress generates links for that subdomain, and search-and-replacing them afterwards is how sites end up with mixed URLs in serialised post meta. Editing your own machine's hosts file lets you load the real domain against the new IP, with no URL changes anywhere.
3. Drop the DNS TTL to 300 seconds a day before you switch. Otherwise some visitors keep hitting the old server for hours, writing comments and orders into a database you are about to abandon.
4. Issue the TLS certificate before the switch if you can. With Caddy or a panel using HTTP validation you cannot, so expect a minute or two of certificate warnings immediately after the DNS change — do it at a quiet hour.
5. Keep the old host running for a week. It is a few pounds for a safety net while you find the thing nobody thought about, which is usually email or a cron job.

The thing that is genuinely harder on a VPS than on managed hosting: there is no rollback button. Managed hosts keep a restore point and undo a bad migration in a click. Here, your rollback is the old server, which is the reason to keep it.

When managed hosting is the right answer

Buy managed WordPress hosting if your site makes money and you are not the person who should be fixing it at 2am; if you need staging, one-click restores and a support desk that will actually look at your install; or if you simply do not want this to be a hobby. Those are good reasons and none of them are a failure of nerve.

Kamatera's own answer is its managed tier at $50 per server per month — more than the server, but less than most managed WordPress plans, and it covers the OS and the stack rather than WordPress itself. Read the boundary carefully: managed here means the machine, not your plugins. For a middle ground that provides managed staging and automated caching on cloud infrastructure starting at $11/mo, our Cloudways review and Cloudways WordPress setup tutorial examine whether paying a hosting layer is worth the markup.

So should you host WordPress on Kamatera?

Yes, if you already administer Linux servers and the control you get is worth the chores — you will have a faster, more predictable site for less money than a comparable managed plan, and you can put it in a data centre near your readers rather than wherever your host has capacity.

No, if WordPress is the thing you care about and servers are not. The money saved is small and the time cost is not, and a managed host doing it properly is a perfectly respectable purchase.

If you are still curious, the 30-day trial is a reasonable way to find out which camp you are in — build the site, run it for a few weeks, and see whether the maintenance list feels like work or like Tuesday. Our full Kamatera review covers the billing rules to know before you start.