WooCommerce hosting requirements: specs, setup and tuning

The WooCommerce hosting requirements go beyond what a blog needs. According to WooCommerce's official server requirements at the time of writing (October 2026), WooCommerce 10.8 and later needs WordPress 6.9, PHP 8.3, MySQL 8.0 or MariaDB 10.6, HTTPS and a 256 MB memory limit. More important than the version numbers: cart, checkout and customer account pages can't be cached, so a store needs more PHP workers, RAM and database capacity, plus a Redis object cache, server-run cron and frequent database backups.

This article explains why WooCommerce is heavier than plain WordPress, how to estimate the resources a store needs, the server checklist to work through, and how to set it all up in ZoPanel.

What are the WooCommerce hosting requirements?

Component	Requirement (WooCommerce 10.8+)	Notes
WordPress	6.9 or later
PHP	8.3 or later (tested up to 8.4)	Still runs on PHP 7.4+, but those versions are end of life
Database	MySQL 8.0+ or MariaDB 10.6+
HTTPS	Required
PHP memory limit	256 MB or more
Web server	Nginx or Apache recommended

Requirements move with each WooCommerce release, so check the official page before you choose a server.

Against common distributions: Ubuntu 24.04 ships PHP 8.3 and MariaDB 10.11; Debian 12 ships MariaDB 10.11 but PHP 8.2, so you need PHP 8.3 from an additional repository; Debian 13 ships PHP 8.4 and MariaDB 11.8. A freshly installed VPS meets the requirements. Budget shared hosting still on old PHP does not.

Why is WooCommerce heavier than a regular WordPress site?

A blog with page cache barely runs PHP for readers. A store is different:

• Cart, checkout and customer accounts bypass the cache. As soon as a visitor adds something to the cart, their browser carries a WooCommerce session cookie and every page they see after that is built by PHP.
• Product filters and search use query strings, and every combination is its own URL that almost never hits the cache. Bots love walking every filter combination.
• Background jobs. WooCommerce uses Action Scheduler for emails, webhooks, stock updates and subscription renewals. By default these run on WP-Cron, which means they run on visitor requests.
• A growing database. Orders, metadata, notes, logs. Since WooCommerce 8.2, new stores use High-Performance Order Storage (HPOS) by default, keeping orders in dedicated tables instead of the posts table; older stores have to switch in WooCommerce → Settings → Advanced → Features.
• Payment and shipping plugins call external APIs during checkout. A slow API holds a PHP worker for the whole wait.

In our 4 GB VPS capacity tests, we noted that a shop with many logged-in customers behaves more like the "without page cache" column than the "with page cache" one. That's the simplest mental model: size a store as if most of its valuable traffic runs PHP.

How much server does a WooCommerce store need?

We won't give a single number, because a 50-product store with little traffic and a 20,000-product store running ads differ by an order of magnitude. Estimate from three questions instead:

1. How many visitors are in the cart or checkout at once? Each such request holds a PHP worker while the page is built. PHP workers needed ≈ uncached requests per second × page build time in seconds, plus headroom.
2. How much RAM does each PHP worker use? With WooCommerce and a few plugins, typically tens of megabytes to over 100 MB. RAM for PHP ≈ workers × memory per worker.
3. How big is the database? MariaDB needs RAM for its buffer pool to keep the busy order and product tables in memory.

For example: at peak you see 4 uncached requests a second and each page takes 0.5 seconds, so about 2 workers are busy at any moment, and 6–8 workers leave room for spikes. At 80 MB per worker, PHP needs about 650 MB. Add MariaDB, Redis, the OS and page cache, and 2 GB is a reasonable minimum for a small store on its own server; a store running ad campaigns should usually start at 4 GB and 2 vCPUs or more, then measure. These are starting points to measure against, not measurements.

The most accurate answer comes from your own store: watch CPU, RAM and checkout response times during a real sale.

A server checklist for WooCommerce

1. Page cache with the right exclusions

Page cache is still the biggest win for the home page, categories and product pages that casual visitors browse. It must bypass:

• /cart, /checkout and /my-account;
• visitors with a cart or WooCommerce session cookie, and logged-in users;
• POST requests.

Getting the exclusions wrong is serious: customers see someone else's cart, or an empty one.

2. Redis object cache

For the requests that must run PHP, a Redis object cache cuts repeated database queries. This is where WooCommerce benefits most clearly. Our guide to the WordPress Redis object cache covers the setup.

3. Server-run cron

Turn off visitor-driven WP-Cron (define('DISABLE_WP_CRON', true);) and let the server run scheduled tasks every few minutes with WP-CLI:

*/5 * * * * cd /home/shop/public_html && wp cron event run --due-now --quiet

Order emails, the Action Scheduler queue and stock updates then run on time, even when the store is quiet, and they no longer slow down page views.

4. Frequent database backups

Nightly backups are fine for a blog. For a store, losing 23 hours of orders is a disaster. Back up the database at least every hour or every few hours, keep a copy off the server, and test a restore at least once.

5. Safe updates and staging

A WooCommerce or payment plugin update can break checkout while the home page looks fine. Test on a staging copy, take a snapshot before updating, and run through an order afterwards.

6. Security and bot control

Stores attract card-testing attacks, password guessing on customer accounts and bots crawling filters. Use a web application firewall, per-IP request rate limits, 2FA for admin accounts, and keep the plugin file editor disabled in wp-admin.

7. Transactional email

An order confirmation in spam becomes a support call. Set up SPF, DKIM and DMARC for the domain, and consider a dedicated transactional SMTP service if the store sends a lot.

Meeting WooCommerce hosting requirements with ZoPanel

Everything on that checklist is built into ZoPanel and works on the Free plan, except copying backups to S3 storage, which needs Pro:

• PHP 8.3 or 8.4: ZoPanel supports PHP 7.4 through 8.4; administrators install versions under Runtimes and pick one per site on the PHP & config tab (see Websites and PHP).
• Page cache on the PHP & config tab. ZoPanel never caches visitors with a WooCommerce cart or session cookie, logged-in users, /cart, /checkout or /my-account, POST requests or URLs with a query string. Ad-tracking parameters such as utm_*, fbclid and gclid don't count as a query, so campaign visitors still get cached pages.
• Redis object cache on the same tab: ZoPanel creates a private Redis database for the site and configures the plugin.
• Server runs scheduled tasks in the Maintenance card of the WordPress tab: ZoPanel sets DISABLE_WP_CRON and creates a timer that runs wp cron event run --due-now every 5 minutes, as the hosting account and inside its resource limits (see WordPress Toolkit).
• Scheduled database backups: every hour, every 6 hours or daily, keeping up to 168 copies, with one-click restore; with Pro, backups are also copied, encrypted, to S3 storage for an off-server copy (see Backups).
• Safe updates: a snapshot of files and database, the update, a check of the home and login pages, and an automatic rollback if the site broke. Staging to test first, then Publish to live.
• WAF (ModSecurity with the OWASP Core Rule Set) and a Request rate limit (20, 8 or 2 requests a second per IP) for sites hit by filter-crawling bots.
• A package for stores: give stores a package with more RAM, CPU and PHP workers, and turn on PHP always running so no customer meets a cold PHP start. Make sure the package's Emails per hour covers the store's order email volume.

The takeaway

WooCommerce hosting isn't just "a bigger VPS". Meet the official requirements (PHP 8.3+, MariaDB 10.6+, HTTPS, 256 MB), then focus on what can't be cached: enough PHP workers and RAM, a Redis object cache, server-run cron, hourly database backups and updates tested on staging. Busy stores deserve their own plan or server, not a share of resources with dozens of brochure sites.

To try it, install ZoPanel with curl -fsSL https://get.zopanel.net | sudo bash, create a WordPress site, turn on page cache, Redis and server cron, and measure your store on the Free plan. See pricing when you need more sites.

Frequently asked questions

Can shared hosting run WooCommerce?

For a small store, yes, provided the host offers PHP 8.3+, MariaDB 10.6+ or MySQL 8.0+, HTTPS, a 256 MB memory limit and generous resource limits. Once a store takes many orders or runs ads, a VPS or a dedicated plan gives you control over PHP workers, caching and cron.

How much RAM does WooCommerce need?

PHP needs a memory limit of at least 256 MB per request, but total RAM depends on how many PHP workers run at once, the database size and other services. A small store on its own server usually starts at 2 GB; measure at a real peak before upgrading.

Should I use page cache with WooCommerce?

Yes, for the home page, categories and product pages that casual visitors browse. The cache must bypass cart, checkout, customer accounts, logged-in users and visitors with a cart cookie; getting that wrong shows customers the wrong cart.

What is HPOS and should I enable it?

High-Performance Order Storage keeps orders in dedicated tables instead of WordPress's posts table, which scales better as orders grow. It has been the default for new stores since WooCommerce 8.2; older stores should check plugin compatibility and then switch, using compatibility mode to keep both storages in sync during the move.

Why do WooCommerce order emails arrive late?

Usually because WP-Cron only runs when someone visits, so the email queue waits while the store is quiet. Moving to server-run cron every few minutes fixes it; if emails arrive on time but land in spam, check SPF, DKIM and DMARC.