NevTan Cloud is a developer cloud that connects your Git repository to managed infrastructure: app hosting, managed databases, object storage, monitoring, and AI services on one platform and one bill. If your WooCommerce store has outgrown shared hosting, this guide shows you how to run it at scale, from repository setup to surviving a flash sale.
You'll get the architecture, a five-step deployment process, a worked example, and the mistakes that quietly break WooCommerce stores once they pass a few thousand orders a day. It's written for practitioners who need working infrastructure.
WooCommerce at scale usually fails in three places: database writes, PHP worker exhaustion, and uncached dynamic traffic (cart, checkout, logged-in users).
The fix is stateless app nodes, managed MySQL and Redis, layered caching, and Git-driven deploys you can roll back instantly.
NevTan Cloud provides the building blocks: deploy from Git, managed databases, scaling presets, and logs and rollbacks.
Enable WooCommerce High-Performance Order Storage (HPOS) before you scale anything else. It's the cheapest performance win available.
Size for your worst hour of the year, not your average day.
What You Need Before Starting
Gather these first. Skipping any one of them costs hours later.
A Git repository on GitHub, GitLab, or Bitbucket containing your theme, child theme, and a
composer.jsonif you manage plugins as dependencies. NevTan supports GitHub and Bitbucket integrations out of the box.A database export of your current store. Dumps under about 5 GB import cleanly; larger stores should use a replication-based migration.
S3-compatible object storage for product images and downloads. Media should never live on an application node.
A CDN for static assets and full-page caching of anonymous traffic.
Redis for the persistent object cache. At scale, this is non-negotiable.
A performance baseline: current p95 page load time, peak orders per hour, and average cart size. You can't prove an improvement you didn't measure.
If you're new to the platform, the quickstart guide and this walkthrough of the NevTan Cloud dashboard will get you oriented in a few minutes.
Step 1: Connect Your Repository and Define the Build
Create a new app in the NevTan Cloud console, choose "Connect Repository," and authorize your Git provider. Select your production branch, usually main.
For WooCommerce, the most predictable approach is a Dockerfile based on an official PHP-FPM image. This pins your PHP version and extensions (mysqli, redis, imagick, intl, opcache) so every environment is identical. A typical build runs:
composer install --no-dev --optimize-autoloadernpm ci && npm run build(if your theme has a build step)wp core download --skip-content(if you don't commit WordPress core)
Keep secrets out of the repository. Database credentials, Redis passwords, and API keys belong in environment variables, which you then read in wp-config.php.
💡 Pro tip: Pin PHP 8.3 explicitly. WooCommerce 9.x runs noticeably faster on 8.3 than on 8.1, especially on cart and checkout endpoints, and you avoid surprise upgrades between deploys.
Turn on auto-deploy so every merge to main ships automatically, and point your store's domain at the app using custom domains, which include automatic SSL. If you're coming from a traditional host, this post on cloud deployment vs. traditional hosting explains why Git-driven releases change how fast you can ship.
Step 2: Provision Managed MySQL, Redis, and Object Storage
From the dashboard, create a managed MySQL database. Pick a size from the available database packages and confirm the MySQL version against the supported engine versions. Then restrict access to your app only using trusted sources.
Next, provision Redis and install a persistent object cache plugin such as Redis Object Cache. Wire everything through environment variables:
php
define('DB_HOST', getenv('DB_HOST'));
define('DB_NAME', getenv('DB_NAME'));
define('DB_USER', getenv('DB_USER'));
define('DB_PASSWORD', getenv('DB_PASSWORD'));define('WP_REDIS_HOST', getenv('REDIS_HOST'));
define('WP_REDIS_PORT', getenv('REDIS_PORT') ?: 6379);
define('WP_REDIS_PASSWORD', getenv('REDIS_PASSWORD'));
define('DISABLE_WP_CRON', true); // run cron on a schedule instead
The connecting to databases guide covers connection strings and TLS settings.
Two WooCommerce-specific changes matter more than any hardware upgrade. First, enable HPOS (WooCommerce → Settings → Advanced → Features). It moves orders out of the bloated wp_posts and wp_postmeta tables into dedicated, indexed order tables, cutting write contention at checkout dramatically. Second, understand where sessions live. WooCommerce stores customer sessions in its own wp_woocommerce_sessions table, not in PHP sessions, so the gain from Redis comes from caching the objects, options, and transients that would otherwise trigger database reads on every request.
If your store eventually needs a read replica, note that WordPress doesn't split reads and writes natively. You'll need a drop-in like HyperDB or LudicrousDB to route product listings and reports to the replica.
Finally, offload wp-content/uploads to object storage with a plugin like WP Offload Media. Stateless nodes are what make horizontal scaling possible.
💡 Pro tip: Set Redis
maxmemory-policytoallkeys-lru. Object caches balloon during sales, and LRU eviction prevents out-of-memory failures without manual intervention.
Step 3: Configure Scaling and Load Balancing
Use NevTan's scaling presets to set how many instances run and how large each one is. A reasonable starting point for a store doing around 5,000 orders a day is at least two instances with 2 vCPU and 4 GB RAM each. Running two or more removes your single point of failure.
If your plan supports rule-based autoscaling, scale on CPU (roughly 65% sustained for a few minutes) or on request queue depth, never on memory. PHP-FPM holds memory even when idle, so memory triggers cause constant flapping. Where autoscaling rules aren't available, scale up ahead of known peaks like Black Friday or a product launch, then scale back afterward.
Because Redis holds your cache and nodes don't store uploads, you don't need sticky sessions. Round-robin distribution avoids the "hot node" problem entirely.
Add a lightweight /healthz endpoint that returns 200 only when PHP-FPM, MySQL, and Redis are all reachable, so failing instances are easy to detect.
💡 Pro tip: Scale out quickly and scale in slowly. Asymmetric cooldowns (for example, 60 seconds out, 5 minutes in) prevent the classic scale-up, scale-down thrash during spiky traffic.
Step 4: Layer Your Caching
Caching is where WooCommerce at scale is won or lost. You need three layers.
CDN. Put Cloudflare, Fastly, or BunnyCDN in front of your app. Cache static assets for a year and anonymous HTML for 5 to 15 minutes. Use NevTan webhooks or a plugin hook to purge the cache on deploys and product updates.
Full-page cache. Use a WooCommerce-aware page cache (WP Rocket, or a custom Nginx FastCGI cache). Always bypass /cart, /checkout, /my-account, and any request carrying the woocommerce_items_in_cart or wp_woocommerce_session_ cookies.
Fragment cache. Cache expensive blocks like related products, category sidebars, and "recently viewed" for 10 to 30 minutes. This keeps pages fast for logged-in shoppers who can't receive full-page cache.
💡 Pro tip: Audit the
wc-cart-fragmentsscript. Recent WooCommerce versions load it only when a mini-cart is present, but many themes force it on every page. Removing it from catalog pages often cuts time to first byte by a few hundred milliseconds.
Step 5: Observability, Backups, and Rollbacks
Use NevTan's container metrics for CPU, memory, and instance health, and add an APM tool like New Relic or Datadog for PHP-level tracing. Watch five numbers above all: p95 checkout response time, MySQL write load, Redis hit ratio, PHP-FPM queue depth, and 5xx error rate.
For backups, rely on managed database backups, and use point-in-time recovery where your database tier includes it. Test a full restore at least once a quarter; an untested backup is only a hope.
Because every release is a Git commit, a bad plugin update is recoverable in minutes: roll back to the previous deployment from logs and rollbacks, fix the issue on a branch, and redeploy.
Lock down the operational side too. Give developers only the access they need with team roles, enforce two-factor authentication, and review audit logs after incidents. For a broader checklist, see our cloud security best practices for growing businesses.
Illustrative Example: An Apparel Store on Black Friday
The figures below are a representative model built from common WooCommerce bottlenecks, not a published customer case study.
Picture an apparel store with 42,000 SKUs, 18,000 orders a month, and a Black Friday peak of about 9,400 concurrent shoppers. On a single 8 vCPU VPS with a separate database server, checkout p95 climbs past 14 seconds, the database pins at 100% CPU, and carts are abandoned by the thousands.
After moving to stateless app instances with managed MySQL, Redis object caching, HPOS, a CDN, and offloaded media, a store like this can reasonably expect:
Metric | Before (single VPS) | After (NevTan Cloud) |
|---|---|---|
Checkout p95 latency | ~14 s | under 2 s |
Catalog p95 latency | ~4.6 s | under 0.5 s |
Peak orders per hour | ~600 | 3–4x higher |
5xx error rate | ~4% | well under 0.1% |
Monthly infra cost | baseline | roughly 20–40% higher |
The infrastructure bill goes up, but revenue during peak goes up far more because checkout stops failing. That trade is the whole business case.
How to Choose Your Setup
Size for peak traffic, not average. Rough tiers (check current pricing for exact numbers):
Under 500 orders a day: One app instance plus managed MySQL and Redis is usually enough. For simple stores, NevTan's managed WordPress hosting may be the fastest path.
500 to 5,000 orders a day: Two to six instances, full-page cache, CDN, and HPOS enabled.
5,000 to 20,000 orders a day: More instances, a larger database package, a read replica with a routing drop-in, and queue-based order processing.
20,000+ orders a day or complex B2B pricing: Consider going headless. Our guide to deploying a headless Medusa store on NevTan shows what that architecture looks like.
A store averaging 1,000 orders a day but hitting 8,000 on Black Friday belongs in the higher tier.
Why This Architecture Works
Each layer targets a specific bottleneck.
Database writes. Every order generates dozens of writes: order data, stock decrements, customer records, and Action Scheduler jobs. On the legacy posts tables these compete with everything else in WordPress. HPOS plus a properly sized managed database separates and indexes that load.
PHP worker exhaustion. Each PHP-FPM worker serves one request at a time. If 9,400 shoppers are active and 70% of requests hit cache, you still need capacity for thousands of dynamic requests. Without caching you'd need several times more instances, which is why caching is almost always cheaper than scaling.
Uncached dynamic traffic. Logged-in users and cart pages can't be full-page cached, so Redis object caching and fragment caching do the heavy lifting there, keeping repeated option and query lookups out of MySQL.
This is also why managed cloud services have become the default for SMBs: the hard parts (backups, patching, database tuning) stop being your team's problem.
Common Mistakes
Storing uploads on the app node. New instances won't have the images, and scaling breaks. Always use object storage.
Caching cart or checkout. Customers end up seeing someone else's cart. Bypass cache whenever WooCommerce cookies are present.
Leaving HPOS off. Large stores on legacy order storage fight table contention they don't need to.
Ignoring Action Scheduler. The
wp_actionscheduler_actionstable can reach millions of rows. Prune completed actions regularly.Relying on WP-Cron. It fires on page loads, which is unreliable under cache and wasteful under load. Disable it and run cron on a real schedule.
Scaling on memory. Use CPU or queue depth instead.
Skipping load tests. Run k6 or Locust at twice your expected peak before a sale, not during it.
FAQ
How many concurrent users can WooCommerce handle on NevTan Cloud?
With stateless instances, Redis object caching, a CDN, and full-page cache, five-figure concurrency is realistic. The ceiling is usually database write throughput, not the app tier, which is why HPOS and database sizing matter most.
Do I need a read replica?
Usually only past a few thousand orders a day or very large catalogs. Remember that WordPress needs a drop-in like HyperDB or LudicrousDB to actually use one.
How long does migration take?
Stores under 5 GB typically move in a day, including DNS changes. Larger stores should plan two to three weeks for replication, testing, and cutover. Never migrate during peak season.
Can I skip the CDN?
Technically yes, but a CDN absorbs most static and anonymous traffic. Without it, you'll pay for far more compute than you need.
How do I handle plugin updates safely?
Test updates on a staging app that mirrors production, merge to main when they pass, and roll back instantly if something breaks. Invite your agency or contractors as project collaborators instead of sharing credentials.
Is NevTan Cloud suitable for B2B WooCommerce?
Yes, with care. Role-based pricing lowers cache hit rates, so lean on fragment caching and Redis, and consider a headless storefront once you're serving hundreds of accounts with unique pricing.
Get Started
Hosting WooCommerce at scale is an engineering problem, not a hosting problem. You need stateless app instances, managed data services, layered caching, and deployments that ship from Git in minutes. NevTan Cloud brings those pieces together in one console, backed by a 99.99% uptime SLA.
Connect your repository, provision MySQL and Redis, enable HPOS, and deploy. Then add CDN caching, load testing, and monitoring, and your next flash sale becomes something to look forward to. Browse the full NevTan Cloud documentation or see pricing to plan your setup.
