Cloudways vs DigitalOcean for WordPress: I Benchmarked Both

No. Cloudways owns no data centers: it rents servers from other providers and installs its own managed stack on top, and it has been a DigitalOcean company since 2022 (a $350 million acquisition). It offers other cloud providers besides DigitalOcean, and which ones are available to new signups has changed over the years, so check the current list when you sign up. DigitalOcean is the default and the one benchmarked here.

It depends on the droplet, and on which part of the site. On cached pages Cloudways beats an untuned droplet comfortably, because its stack is pre-optimized while a default droplet install has no caching set up at all. On anything that has to run PHP, checkout and wp-admin, it finished behind both droplets, tuned and untuned alike. A tuned droplet leads on every test here (see the benchmarks above).

Not for the pages themselves. Cloudflare’s free tier does not cache HTML by default, so a spike still lands on your server either way: it neither saves an untuned box nor flatters a tuned one. A tuned droplet or Cloudways handles the spike comfortably (see Benchmark 1); an untuned box runs out of CPU roughly twelve times sooner, with or without Cloudflare in front. Where a CDN does help is asset bandwidth: serving everything yourself, a 2 Gbps port sustains roughly 150 complete first-visit page loads per second before transfers start to slow, and they slow rather than error.

The main trade-offs: no root access, so a few server-level tasks have to go through support; PHP is set per server rather than per site; it costs roughly 2.1 to 2.3 times a comparable DigitalOcean droplet; and dynamic, uncached pages render slower than on an equivalently-sized tuned droplet. You accept those in exchange for not managing the server yourself.

No. You get command-line SSH access and SFTP access to your application, but not full root on the server, so system-level changes like installing custom packages or editing certain server configs go through Cloudways support. If unrestricted root control is a requirement, a self-managed droplet is the better fit. If you decide to go this route, the guide on creating your first DigitalOcean Droplet walks through the initial setup.

Yes, but it is unmanaged. A droplet runs WordPress perfectly well and gives you the most performance per dollar, but you set up and maintain the web stack, caching, security, and updates yourself. It is a great fit if you want control and are comfortable on the command line, and more work than you may want if you are not.

Yes, though it is the workload where the managed stack costs you most: with a hundred concurrent shoppers, the checkout page loaded in about 1.3 seconds on a tuned droplet against nearly 11 on Cloudways. Size the plan by CPU cores, not RAM. Note that Cloudways’ WooCommerce option installs plain WordPress, so you add WooCommerce yourself either way. See the WooCommerce verdict above for how to choose between them.

Yes. Cloudways provides a free WordPress migration plugin that moves an existing site for you, or you can rebuild manually. Moving off a self-managed droplet is usually far less work than it sounds.

Neither hosts mailboxes, and DigitalOcean blocks outbound SMTP on ports 25, 465 and 587 on every droplet by default, so on both you send transactional email (password resets, order receipts) through a service like SendGrid, Mailgun, or Amazon SES, wired up with a WordPress SMTP plugin. On a droplet that is one more thing you set up; Cloudways has a one-click Elastic Email add-on, though it is billed per email like most of its extras (premium CDN, off-server backups). Either way, plan on a dedicated email service rather than the server itself.

All three ran an identical site (WordPress 7.0, WooCommerce 10.8.1, the twentytwentyfive theme, 22 posts and 200 products, 50 customer accounts, over HTTPS) on matched 8 GB / 4 vCPU DigitalOcean Basic instances in London: three regular droplets per droplet arm, and the matching Cloudways-on-DigitalOcean plan. Two things differ besides the stack, and both favor the droplets slightly: the droplets ran Debian 13 on PHP 8.4, while Cloudways ships Debian 12 on PHP 8.2, its current default. Everything else in the setup is the stack and who maintains it:

The CPU lottery. Cloudways runs on DigitalOcean, so the silicon is the same class, but DigitalOcean assigns identical plans to whatever physical CPU is free, and the clock speed you draw is luck. That lottery is real: three draws for one slot returned 1,995, 2,294 and 2,494 MHz inside two minutes. So every server was clock-checked before it was used, and any that drew a different chip was destroyed and redrawn: five were discarded to seat six droplets. Every server behind the numbers here, both droplet arms and every Cloudways server, ran at 2294.6 MHz, so nothing is clock-adjusted. Each droplet figure is the median of three independently provisioned servers with the full range reported. Matching the clock controls which chip you get, not how busy its host is. Steal was sampled on the twelve droplets under a sustained shopper load, and it varied a lot: on the cached test three of six tuned servers came in above 10% and were dropped before the median was taken. The store test is the exception, and it is worth stating plainly. Two of its three tuned servers also ran above 10%, at 13% and 24%, and they were kept: discarding them would have left a single server and no range at all. Their figures sit inside the published range, which is why the range is printed beside every median rather than the median alone.

Load + controls. The two capacity tests (store and dashboard) were driven by k6 from a separate droplet per target in the same region, one dedicated load generator each, with target CPU sampled during a sustained shopper pass on each droplet. Load-generator CPU was not sampled; at the 25 to 65 requests a second these runs actually produced, a 4 vCPU generator is nowhere near its own ceiling. The cached-page test is the exception: it runs wrk on the server itself against 127.0.0.1, deliberately, because a cached page is served fast enough that any network in the path becomes the thing you are measuring. Worker count is the obvious objection, so it was tested directly. Cloudways runs its PHP pool at pm=ondemand with max_children=20, read off the box, against 16 static workers on the tuned droplet. Held down to Cloudways’ own 20 workers on the same WooCommerce funnel, a tuned droplet still served 870 requests a second against 463 in an earlier campaign, so roughly twice the dynamic throughput at matched pools. That is a throughput test rather than a checkout-latency one, so read it as evidence that the stack differs, not as a full account of the gap: a smaller pool also deepens the queue once a lot of shoppers arrive at once, which is why the gap widens with concurrency. Worth noting that the tuned droplet ran 16 workers against Cloudways’ 20, so it was not out-provisioned. Sixteen is low for an 8 GB box, and deliberately reported rather than tidied up: the tuned servers were restored from a snapshot built on a smaller machine, so the pool never scaled to the hardware it ran on. The tuned arm was therefore under-provisioned on the one setting that matters most here, and still finished ahead.

What this does not settle. Each platform was tested as it ships, which is the comparison a buyer actually faces, but it means the droplets carry a newer runtime as well as a leaner stack: PHP 8.4 on Debian 13 against Cloudways’ PHP 8.2 on Debian 12. This campaign did not separate how much of the margin belongs to each. Cloudways was also measured on three servers for checkout and one for the cached and editor tests, so those two figures are the least settled numbers here. And while the droplet checkout runs kept their full distribution, tight enough that the 95th percentile sits close to the typical checkout, only the 95th percentile was retained for Cloudways, so its spread between a typical and a slow checkout is not something this campaign can show you.

Tool: wrk, run on the server itself over HTTPS, against a real cached post of roughly 80 KB rather than a stub file. The exact command was wrk -t4 -c100 -d12s --latency https://127.0.0.1/hello-world/, with -H 'Host: <site hostname>' set so the vhost returned the cached page rather than a redirect. Each box served a single site behind a self-signed certificate, so there was no second virtual host for the loopback request to land on by mistake. The cache was warmed with ten requests before each run, and the page size was recorded with every run, so a fast-but-empty result would be obvious in the data rather than hidden: 85,312 bytes on the tuned droplet, 82,120 on Cloudways, and about 78,700 untuned, where a redirect or error page would have been a few hundred. Only Cloudways emits a cache-hit header to check directly; both droplet arms serve their cached file without one. Running on the box is deliberate: a cached page comes back so fast that a load generator on the other side of a network measures the network instead of the server. Off the box the tuned droplet settles at about 2,900 a second, and that is the network port giving out rather than the server. Cloudways lands near 2,170 off the box against 2,206 on it, under two percent apart, which is the opposite situation: it is still the server, because at that rate it is only moving about 178 MB a second against a pipe that carries roughly 236. The off-box figure came from a homepage burst on a second Cloudways server, so it is a corroboration from a different tool and machine rather than a repeat of the same test. Tested at 4 vCPU only. Cached throughput scales roughly with core count, so read every figure here as a 4 vCPU figure rather than a verdict for every plan size.

At 12,118 pages a second the tuned droplet is moving about a gigabyte a second, roughly four times what a droplet’s network port carries, which is why the figure is headroom rather than a delivery rate. Six tuned servers were measured across two separate draws about ten hours apart the same day; three of them recorded CPU steal above 10% and were discarded. The figure is the median of the three that passed (10,566 to 13,164). All three discarded servers came in below the published median, and the spread between the two draws is the host lottery in a single number. Untuned is three servers (982 to 1,335) and Cloudways is one server across three runs (2,077 to 2,249). The pages differ slightly in weight, 85 KB tuned against 82 KB Cloudways and 79 KB untuned, which flatters the lighter two by a few percent.

The result is about cache architecture, not raw speed. The tuned droplet’s Nginx FastCGI cache answers a cached request without starting PHP at all, which is what buys it about twelve thousand pages a second on four cores. Cloudways sits in the middle for one identifiable reason: Varnish, which its servers run by default. On the same server in the same session, Varnish serving gave 2,206 pages a second; with the server-level cache stopped the same test fell to 422 and every cache header disappeared, so 5.2 times the throughput came from that layer. Because every cache header went with it, this measures the whole server-level cache rather than Varnish separated from Breeze underneath it. The untuned droplet also has a page cache, but it sits behind stock Apache with mod_php, and that is where its ceiling comes from: the box sat pinned at 100% CPU while serving 1,021 pages a second. Every arm returned every request without error; the difference is throughput, not stability. None of this bites at everyday traffic, it only shows in a spike. SpinupWP’s own Varnish against Nginx FastCGI test finds the same ordering, independently of this one.

Tool: k6, with scripts I wrote, shaped after the browse-and-buy workload the Review Signal WordPress benchmarks use. The workload is a realistic browse-and-buy funnel (home, browse products, add to cart, cart, checkout) with 2 to 6 seconds of think-time between actions; one virtual user equals one shopper. Concurrency was stepped through 16, 60, 100 and 140 shoppers, recording the slowest-typical checkout at each step rather than stopping at a threshold, so the whole curve is visible and not just the point where it crosses a line. “Slowest-typical” throughout this article means the 95th percentile: nineteen of every twenty checkout page loads were faster than the figure shown, and it is the number a real customer notices, not the average that hides the bad ones. Zero failed requests on any step reported here. Cart and checkout are never cacheable on any host. Measured August 2026 at 4 vCPU, one dedicated load generator per target, three servers per arm. The headline figure is the slowest-typical checkout with 100 shoppers active at once. One property of the script is worth stating: every shopper reaches the checkout on their first pass, so the measurement is a synchronised rush rather than a steady trickle. That is the harshest moment a store sees, and it falls hardest on a platform that starts PHP workers on demand rather than keeping them warm, which is how Cloudways is configured. All three arms were measured with the identical script.

The August campaign measured checkout page-load time rather than a shopper ceiling: 1,342 ms tuned, 5,125 ms untuned, 10,649 ms Cloudways, each the median of three servers. Worker count is only part of it and the runtime difference is covered in the environment note above. The ordering holds the whole way up the ramp, not just at the headline figure. Slowest-typical checkout, median of three servers per arm: at 16 concurrent shoppers 210 ms tuned, 618 ms untuned, 1,228 ms Cloudways; at 60, 346 / 1,523 / 5,193; at 100, 1,342 / 5,125 / 10,649; at 140, 3,379 / 8,954 / 15,565. Two things are worth taking from that. The separation is already there at 16 shoppers, a load a small store sees on an ordinary day, so this is not purely a stress-test artifact. And no arm returned a single failed request at any step, so these are slowdowns, not servers falling over.

Tool: k6. Each virtual user is its own WordPress editor account that logs in fresh, then works through the dashboard, the post list, the media library and the block editor with think-time, and saves a draft through the REST API. Every timed page is checked for markup that only exists on a logged-in admin page, and any step where fewer than 99% of pages pass that check is rejected outright: a failed login lands on the login page, which returns HTTP 200 and renders far faster than a dashboard, so without that check broken sessions flatter the numbers. Runs that predate these checks were discarded, and none of their numbers appear here. Concurrency was stepped 1, 5, 10, 20, 30, 40, 60, 80, sixty seconds a step, one dedicated load generator per target, and capacity is linearly interpolated where the 95th-percentile admin page crossed 2 seconds. wp-admin is never cacheable on any host. Measured August 2026 at 4 vCPU: three clock-matched servers per droplet arm (all 2294.6 MHz, CPU steal under 4% throughout), one Cloudways server. The tuned arm’s configuration is read back off each running box and matched against the recipe before its numbers count.

Capacity is the highest concurrency at which the 95th-percentile admin page still loads inside 2 seconds: tuned droplet 30 (three servers: 30, 30, 33), untuned droplet 21 (21, 21, 22), Cloudways 16 from a single server. The spreads are tight, three editors across three servers on each droplet arm, so the tuned arm’s nine-editor advantage over untuned reads as real: the object cache and opcode cache do help the uncacheable admin, though nothing like the twelve-times gap the page cache opens on the public side of the site. Single-editor page medians: 270 ms tuned (251 to 276), 385 ms untuned (380 to 396), 516 ms on Cloudways; saving a draft took 172, 207 and 390 ms respectively. Every step on every server passed the logged-in check at 100%.