Which Cloud Provider for a WordPress Site

WordPress is a PHP application with a MySQL-compatible database, and its
resource profile is well understood. That makes this one of the easier provider
decisions, provided you are honest about which of two quite different situations
you are in.

What WordPress actually needs

Memory before CPU. PHP processes and the database both
consume memory, and running out of it is what takes a WordPress site down. CPU
is rarely the first limit for a content site.

Fast storage. The database is the usual bottleneck on a busy
site. Network-attached SSD storage is fine; the thing to check is whether the
volume’s throughput is capped by its provisioned size.

Outbound transfer. Media-heavy sites serve a lot of bytes.
An included transfer allowance is worth more here than a slightly better
processor.

Not much else. No managed queue, no data warehouse, no
Kubernetes. This is the significant point: WordPress uses almost none of what
distinguishes a hyperscaler.

The honest first question

Should you run it on cloud infrastructure at all, or buy managed WordPress
hosting?

Managed hosting handles updates, backups, caching and security at the
application layer, and for a site that is a business rather than a project, that
is frequently the correct answer. Running it yourself means you own PHP
versions, database tuning, caching configuration, TLS renewal, backups and the
security of a platform that is heavily targeted precisely because it is
popular.

Choose to self-host when you want control, when you are running several sites
and the economics change, when you have specific requirements managed hosts do
not accommodate, or when someone on the team genuinely enjoys this. Choose
managed hosting when nobody is going to own that work, because an unmaintained
WordPress install is a liability rather than a saving.

The rest of this assumes you have decided to run it yourself.

Where the value is

Since WordPress needs memory, storage and transfer rather than a service
catalogue, the value-focused providers fit it unusually well.

Hetzner
offers the strongest memory per unit of cost in the entry tiers, which is
precisely the resource WordPress consumes. For a European audience this is hard
to beat. The trade-offs are a narrower catalogue, email-based support and the
strictest registration process of the three.

DigitalOcean
is the most approachable, with documentation that is widely used as a general
Linux reference and that covers this exact deployment thoroughly. Per-second
billing makes experimenting cheap. You pay a modest premium over Hetzner for
that polish.

Linode
sits alongside DigitalOcean, with a $100 credit for new users that is enough to
evaluate properly before committing.

All three include outbound transfer allowances generous enough that a normal
content site never thinks about egress, which is a genuine and frequently
overlooked saving.

When a hyperscaler makes sense anyway

Three situations justify it. A site with genuinely spiky traffic, such as
one tied to broadcast or campaign events, benefits from real autoscaling. An
organisation already standardised on one platform gains from keeping everything
in one place. And a site with a global audience and real latency requirements
needs a footprint the smaller providers lack.

Outside those, a hyperscaler for a single WordPress site means paying in
money and complexity for elasticity that nothing is using.

A sensible starting configuration

• One instance with at least two gigabytes of memory for a small site, four if
  it is commercial or runs WooCommerce.
• Database on the same server initially. Split it out when measurement says
  to, not before.
• Object storage for media if the library is large, which keeps the server
  disk small and makes rebuilds easier.
• A CDN in front of static assets, which reduces both load and egress.
• Automated daily backups, stored somewhere other than the same server, and
  tested by actually restoring one.

The thing that matters more than the provider

Caching. A properly configured page cache changes the server capacity a
WordPress site needs by a large factor, and it is free. A cached site on a small
instance outperforms an uncached site on a much larger one, which means the
first response to “the site is slow” should be to check caching rather than to
resize. Choosing between these providers is a smaller decision than configuring
that correctly.