← All postsHosting

Setting up WooCommerce on Cloudways, step by step

By · Updated October 9, 2026 · Published September 16, 2026 · 5 min read

Setting up WooCommerce on Cloudways, step by step
Photo: Brett Sayles / Pexels

Disclosure: the Cloudways links in this post are affiliate links. If you start a plan through one, StoreToNative may earn a commission at no extra cost to you. Every setting and price below is from Cloudways’ own documentation and pricing pages — check the current pages before you buy, since plans change.

Managed cloud hosting removes Linux administration and leaves you with about six decisions. Get those six right and a WooCommerce store on a small server will outperform a much larger badly-configured one. Here they are in the order you will meet them.

Decision 1 — which cloud provider

Cloudways is a management layer on top of someone else’s infrastructure: DigitalOcean, Vultr, Linode, AWS EC2 or Google Cloud. You pick.

For a typical WooCommerce store, DigitalOcean is the sensible default: the cheapest entry point, plenty of regions, and predictable performance. As of October 2026 their Micro plan is $14/month (1 GB RAM, 1 vCPU, 25 GB NVMe, 1 TB bandwidth), which is under-powered for a store; pick Small at $28/month (2 GB RAM, 1 vCPU, 50 GB NVMe, 2 TB bandwidth) as the starting point.

Choose AWS or Google Cloud only if you have a specific reason — a compliance requirement, or other infrastructure you need to sit beside. They cost more for equivalent resources.

Decision 2 — which region

This is the highest-impact decision on the page and the one people click past. Latency is geography, and no cache fixes a round trip.

Put the server where your customers are, not where you are. A US store serving US customers belongs in a US region. If you have a mobile app, this matters twice over: the app makes many small API calls per screen, and every one of them pays the round trip.

Decision 3 — how big

Start smaller than you think and resize later; vertical scaling on Cloudways is a slider, not a migration.

A rough guide:

  • Under 500 products, under 50 orders/day: the 2 GB entry plan.
  • 500–2,000 products, or heavy attribute filtering: one tier up, mostly for the MySQL buffer pool.
  • Spiky campaign traffic: size for the spike, or look at their autoscaling product (below).

Cloudways also sells Cloudways Autonomous, fully managed WordPress with autoscaling, from $99/month on the Growth plan (one baseline autoscale server, 20 GB disk, 150 GB bandwidth, unmetered visits). That is the option if you would rather not size servers at all.

Decision 4 — the cache stack

Cloudways ships Varnish, Redis and Memcached built in, plus their free Breeze cache plugin pre-installed, and includes Object Cache Pro on plans. Here is what to do with each, because “turn everything on” is wrong for WooCommerce.

Redis / Object Cache Pro — turn on. This is the big one. A persistent object cache stops WordPress recomputing option and term data on every request. It is the single largest improvement available to dynamic pages and to REST API traffic, which is what a mobile app consumes.

Varnish — on, with exclusions. Varnish is a full-page cache and it must never cache cart, checkout, my-account or the REST API. Cloudways’ WooCommerce guidance covers the standard exclusion list; if you skip it, the classic symptom is a customer seeing someone else’s cart.

Breeze — on, but configure it deliberately. Use it for minification and browser caching. Do not stack it with another page-cache plugin; two page caches produce bugs nobody can reproduce.

Memcached — leave it off if you are using Redis. Pick one object cache.

Decision 5 — PHP version

Cloudways lets you switch between PHP 7.4, 8.0, 8.1, 8.3 and 8.4 per application. Run the newest version your plugins support. Moving a store from 7.4 to a current 8.x is frequently the cheapest performance gain available, and it is a two-minute change with a rollback.

Test on staging first — an old plugin that breaks on PHP 8 is the one thing that makes this non-trivial.

Decision 6 — staging

Cloudways includes free advanced staging and cloning. Set it up on day one, before you need it.

This stops being optional the moment a mobile app depends on your store, because a plugin update that changes how product data comes back through the REST API now breaks your app as well as your site. Your app’s users will report it as “the app is broken,” and they will do it in your App Store reviews.

Rule to adopt permanently: plugin and PHP updates go to staging first, always, once an app exists.

The migration, if you are moving an existing store

Cloudways provides the Cloudways WordPress Migrator plugin, and includes one free migration for new users. Either way, the order that avoids downtime:

  1. Create the server and application on Cloudways.
  2. Migrate with the plugin — or use the free migration service.
  3. Test with your hosts file pointed at the new server’s IP, so only you see it.
  4. Place a real test order. Card, address, shipping, confirmation email.
  5. Check the REST API if you have an app: product endpoints, order creation.
  6. Enable Redis, configure Varnish exclusions, set the PHP version.
  7. Lower your DNS TTL the day before the switch.
  8. Switch DNS. Keep the old host running for a week.
  9. Re-issue SSL on the new host and verify no mixed-content warnings.

Step 4 is the one people skip and the one that catches gateway configuration tied to the old server’s IP.

The post-launch checklist

Before you call it done:

  • Automated backups on, with a retention you have actually looked at.
  • A test restore. A backup you have never restored is a hope.
  • Cron. WordPress’s pseudo-cron is unreliable under caching; use a real server cron for wp-cron.php.
  • SSL valid, redirects clean, no mixed content.
  • Object cache confirmed active, not just installed.
  • A real order, on a real card, from a real phone.

If you also run a mobile app, add: our WordPress companion plugin’s 14 store-readiness checks, which catch the HTTPS, permalink and gateway problems that surface as app failures rather than website errors.

What this does not fix

Hosting is not a substitute for a well-built store. Thirty plugins hooking every product query, 4 MB hero images and a page-builder theme shipping 800 KB of CSS will be slow on any server. Do the object cache and image sizes first, then buy the server — and if you have an app, remember that the app’s perceived speed is your API’s response time.

Related reading

Their 3-day trial takes no credit card, which is enough to clone a store and measure it against what you have now.