VPS for WooCommerce

VPS for WooCommerce should be sized for the parts of the store that cannot behave like a cached blog: cart, checkout, account, orders, stock, payment callbacks, scheduled actions and database writes. Monthly visits or product count alone do not tell you how much server the store needs.

For the broader WordPress workload, see VPS for WordPress. For the central server-buying path, see VPS for website.

Quick answer · Fit checker · Checkout load · Database · Scheduled actions · Sale peaks · FAQ

Quick answer

These are practical starting points for the current VDSina Standard tiers, not order-count or visitor guarantees.

WooCommerce’s own scaling guidance has used 1 vCPU + at least 2 GB RAM as a foundational self-hosted setup with OPcache, CDN and persistent cache support. That is a starting floor, not a promise that a production store will remain comfortable there.

Current VDSina Standard prices rechecked on October 13, 2026:

• 1 vCPU / 1 GB / 10 GB / 1 TB monthly transfer — $0.07/day;
• 1 vCPU / 2 GB / 40 GB / 32 TB — $0.50/day;
• 2 vCPU / 4 GB / 80 GB / 32 TB — $0.67/day;
• 4 vCPU / 8 GB / 160 GB / 32 TB — $1.34/day.

For many real business stores, 4 GB is the more practical starting tier because the VPS must carry the OS, database, PHP workers, cache, background jobs and operating headroom at the same time.

For deeper cross-stack sizing, use VPS sizing for website.

WooCommerce requirements are not production VPS sizing

WooCommerce’s current server recommendations for WooCommerce 10.8+ call for:

• WordPress 6.9+;
• PHP 8.3+;
• MySQL 8.0+ or MariaDB 10.6+;
• HTTPS;
• WordPress memory limit 256 MB+;
• Apache or Nginx as recommended web-server choices.

Those values answer “does the environment meet WooCommerce’s software baseline?”

They do not answer:

• how many PHP workers you need;
• how much total VPS RAM is required;
• whether the DB working set fits in memory;
• whether checkout queues under load;
• whether scheduled actions are late;
• whether backups/imports collide with customers;
• whether payment/webhook integrations are delaying requests.

A 256 MB WordPress/PHP memory limit is not 256 MB of VPS RAM. Total server RAM must also cover Linux, web server, DB, PHP workers, cache, jobs, panel/mail and headroom.

WooCommerce VPS Fit Checker

Use this as a starting decision, not as a benchmark guarantee.

When WooCommerce actually needs VPS

A WooCommerce store can justify VPS when:

• shared hosting repeatedly hits legitimate CPU/memory/process/I/O limits;
• checkout/account requests queue under real load;
• the DB working set or write load needs more control;
• extensions need services the current host does not permit;
• Redis/Memcached or custom server configuration is required;
• Action Scheduler/background jobs need more reliable execution;
• product imports, feeds or inventory sync collide with customer traffic;
• custom PHP/runtime/web-server settings are required;
• staging or store-specific operational control is required.

If the store is small, stable and well supported on managed WooCommerce/WordPress hosting, VPS is not automatically the better choice.

When managed WooCommerce hosting may be better

A self-managed VPS is a poor fit when:

• no one owns OS/security updates;
• nobody monitors checkout availability or server alerts;
• backups exist but restore is untested;
• payment/order downtime is business-critical;
• the team wants WordPress/WooCommerce help rather than Linux administration;
• the existing managed platform already solves performance and scaling adequately.

A VPS can give more control, but it also gives you more failure modes to own.

See Managed vs Unmanaged VPS before putting a revenue-critical store on a self-managed server.

Checkout and account traffic stay dynamic

WooCommerce’s own caching guidance says Cart, My Account and Checkout should be excluded from full-page cache because they contain customer-specific state.

That matters because the most commercially important requests can still execute:

• PHP;
• session/cart logic;
• shipping/tax logic;
• payment integration code;
• database reads/writes;
• order creation;
• stock updates;
• hooks/extensions.

A store can therefore serve a cached product page quickly while checkout still queues.

Do not size WooCommerce from the cache hit rate of the catalog alone.

PHP workers and dynamic concurrency

For dynamic WooCommerce requests, PHP workers determine how many requests can execute concurrently.

A useful approximation is:

active dynamic requests ≈ uncached requests per second × request duration

If checkout/account/API requests average 0.8 seconds at peak and 5 dynamic requests per second reach PHP, roughly four workers can be busy at once before admin work, webhooks or background jobs are added.

Each worker consumes memory. Increasing the worker count without a RAM budget can starve the database or push the server into swap/OOM.

Use:

WooCommerce RAM = OS + web server + DB + cache + PHP workers + jobs + panel/mail + headroom

Then verify average/peak worker memory instead of copying a generic worker count.

Cache WooCommerce correctly

WooCommerce needs a layered cache strategy.

Full-page cache

Useful for cacheable catalog/content pages.

Do not blindly cache:

• Cart;
• Checkout;
• My Account;
• customer/session-specific responses.

WooCommerce’s official caching guidance explicitly excludes those pages.

OPcache

Caches compiled PHP bytecode and reduces repeated PHP compilation work.

Persistent object cache

Redis or Memcached can reduce repeated database/object work when the workload benefits.

It does not replace full-page caching and does not automatically fix inefficient queries.

Browser / CDN

Useful for static assets and edge-deliverable content.

A CDN can reduce static origin requests but does not remove dynamic checkout/database work.

Database demand and HPOS

WooCommerce creates heavier database read/write behavior than a typical cached WordPress site.

Important DB work can include:

• order creation and updates;
• customer/account data;
• stock changes;
• product/catalog lookups;
• sessions;
• extension metadata;
• reports/analytics;
• search/filtering;
• scheduled jobs.

WooCommerce High-Performance Order Storage (HPOS) stores order data in dedicated tables and is enabled by default for new installations since WooCommerce 8.2.

HPOS is an important architectural improvement, but it is not a substitute for:

• compatible extensions/custom code;
• query/index review;
• adequate DB memory;
• low storage latency;
• monitoring;
• staging/testing before major changes.

For existing large stores, WooCommerce recommends testing HPOS migration and critical flows before production cutover.

Action Scheduler and background work

WooCommerce uses Action Scheduler for background jobs such as:

• order notifications;
• payment-related processing;
• webhooks;
• subscriptions/renewals;
• extension jobs;
• imports/synchronization.

WooCommerce exposes these under WooCommerce > Status > Scheduled Actions.

Watch for:

• failed actions;
• past-due actions;
• persistent pending backlog;
• long-running jobs;
• queues that grow during customer peaks.

Action Scheduler depends on WordPress scheduling by default, so server-side cron can be useful where reliable timing is required.

A store with fast cached pages can still have operational problems if its scheduled queue is failing.

Payments, webhooks, email and integrations

A larger VPS cannot fix every checkout failure.

External dependencies may include:

• payment gateways;
• tax APIs;
• shipping APIs;
• inventory/ERP sync;
• CRM;
• transactional email;
• fraud checks;
• webhooks;
• external search/services.

Measure whether latency originates from your VPS or from the external service.

Monitor:

• payment callback failures;
• webhook delivery;
• email queues;
• API timeouts;
• retry/backoff behavior;
• Action Scheduler failures.

Do not buy CPU to solve a third-party API bottleneck.

Catalog, search and filtering

Large catalogs do not create load only because they contain many products.

The real pressure comes from:

• complex search/filter queries;
• attribute/taxonomy queries;
• product lookup tables;
• variation counts;
• pricing/stock rules;
• extensions that add SQL or external calls;
• uncached personalized results.

Measure search/filter endpoints separately from normal product-page browsing.

Persistent cache can help some repeated queries, but database/query design still matters.

Size for sale and campaign peaks

WooCommerce peak load often combines several things at once:

• newsletter/ad traffic;
• catalog browsing;
• add-to-cart;
• checkout;
• payment callbacks;
• order emails;
• stock updates;
• admin/order processing;
• webhooks;
• scheduled actions;
• analytics/logging.

Size for the representative peak window, not the average day.

Before a major promotion:

1. test representative checkout traffic;
2. verify PHP worker headroom;
3. verify DB latency and connections;
4. check Action Scheduler backlog;
5. pause or reschedule imports/backups/scans;
6. confirm external payment/shipping/tax APIs;
7. watch logs and resource metrics during the event.

Storage, backups and staging

A WooCommerce backup must protect both files and transactional data.

Include:

• WordPress/WooCommerce files;
• uploads/product media;
• database/order data;
• configuration/secrets needed for recovery;
• plugin/theme/custom code;
• integration settings.

Transaction-aware recovery

If the store receives orders continuously, backup frequency defines potential order-data loss.

A daily DB backup can mean up to a day of recent transactions is outside that restore point.

Choose backup frequency from acceptable recovery point objective (RPO) rather than convenience.

Deep backup architecture belongs to VPS Backup Strategy.

Staging

Test PHP/WooCommerce/plugin/theme/HPOS/payment changes in staging before production where practical.

But staging copies also consume disk and sometimes DB/RAM/backup resources, so include them in capacity planning.

Control panel, FASTPANEL or manual stack

WooCommerce can run on a manually managed Linux VPS or through a hosting control panel.

For generic panel selection, see VPS with Control Panel.

For the VDSina FASTPANEL-specific path, see FASTPANEL VPS Hosting.

For a manual Linux deployment, see How to host a website on VPS.

A control panel simplifies routine tasks; it does not own checkout reliability, WooCommerce/plugin updates, DB tuning, backups or incidents.

Live-store migration has a data boundary

A WooCommerce migration is not only “copy files and DB”.

Orders, stock, carts, customers and scheduled actions can change while the store is live.

For migration:

• build/test the destination first;
• control final writes;
• run a final DB/uploads sync;
• avoid two writable production stores diverging;
• verify payment/webhook endpoints;
• preserve email/DNS;
• keep a rollback plan.

Use Website migration to VPS for the full cutover process.

WooCommerce VPS upgrade triggers

Scale or re-architect when measurements show:

• repeated PHP worker queues;
• sustained CPU saturation after cache/query/plugin optimization;
• RAM pressure, swap or OOM;
• DB latency / DB working-set pressure;
• Action Scheduler backlog/failures caused by capacity;
• checkout/payment errors under legitimate peak load;
• storage growth reducing safe headroom;
• backup/import/scan jobs colliding with customers;
• multiple store/services competing for one VPS.

If checkout is slow while server resources are healthy, investigate payment/API/plugin/database causes before buying a larger VPS.

WooCommerce VPS launch checklist

Current WooCommerce VPS examples

These current VDSina Standard plans are mapping examples, not store-capacity guarantees.

The 1 GB Standard tier is not presented as the normal WooCommerce production option.

VDSina’s current Standard page does not list a dedicated preinstalled WooCommerce application in its visible template/application groups. Use a compatible WordPress/manual/panel path rather than assuming one-click WooCommerce.

Check current WooCommerce VPS options

Disclosure: the editor has a professional relationship with VDSina, and this site may earn a commission if you order through this partner link. Verify current VPS pricing, templates and panel availability before ordering.

Technical references

• WooCommerce — server recommendations
• WooCommerce Developer — scaling with WooCommerce
• WooCommerce Developer — configuring caching plugins
• WooCommerce — Scheduled Actions
• WooCommerce Developer — High Performance Order Storage
• VDSina Standard VPS

FAQ

How much RAM does WooCommerce need on a VPS?

There is no universal number. WooCommerce’s own scaling guidance has used 2 GB as a foundational self-hosted setup, while a 4 GB VPS is a stronger practical starting point for many business stores because PHP workers, DB, cache and jobs need to coexist.

Is 2 GB RAM enough for WooCommerce?

It can be enough for a very small/lean store or controlled low-volume setup. Validate checkout concurrency, DB latency, scheduled actions and memory pressure before treating it as production-ready.

Is 4 GB RAM enough for WooCommerce?

For many small business stores, 4 GB is a practical starting point. Heavy traffic, larger catalogs/DBs, many integrations, subscriptions, imports or sale spikes can require more.

Why is WooCommerce heavier than normal WordPress?

Cart, checkout, account, orders, stock and many integrations are dynamic. Those requests still execute PHP and database work even when public catalog/content pages are cached.

Can I cache WooCommerce checkout?

Full-page caching should exclude Cart, Checkout and My Account because those pages contain customer-specific state. Use other cache layers for appropriate data/content.

Does WooCommerce need Redis?

No. Redis or Memcached can provide persistent object caching when the workload benefits. They do not replace correct page-cache exclusions or efficient queries.

What is HPOS?

High-Performance Order Storage stores WooCommerce orders in dedicated tables. It is enabled by default for new installations since WooCommerce 8.2. Test extension/custom-code compatibility and critical store flows when changing an existing store.

What are WooCommerce Scheduled Actions?

They are queued background jobs managed by Action Scheduler for work such as order notifications, payment-related processing, webhooks and extension tasks. Failed or past-due queues are an operational signal.

Does VDSina include WooCommerce preinstalled?

The current VDSina Standard page does not list WooCommerce as a dedicated preinstalled application in its visible template/application groups. Verify the live order interface before assuming any template availability.

Is a VPS always better for WooCommerce than managed hosting?

No. A self-managed VPS is useful when you need control/resources and can operate the server. Managed WooCommerce/WordPress hosting can be safer when the store is business-critical and server administration has no internal owner.