VPS for WordPress

VPS for WordPress is useful when WordPress needs more control, isolation or server-level features than shared hosting can provide. The VPS should be sized around uncached PHP work, database demand, plugins, background jobs, storage growth and the services that run beside WordPress, not around a monthly visitor number.

For the broader server decision, see VPS for website.

Quick answer · Fit checker · PHP workers · Caching · Database · WP-Cron · FAQ

Quick answer

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

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.

If the site is a real store with dynamic cart, checkout, account, orders or stock, use VPS for WooCommerce rather than treating it like normal cached WordPress.

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

WordPress requirements are not VPS sizing

WordPress.org currently recommends a host that supports:

• PHP 8.3 or greater;
• MariaDB 10.11+ or MySQL 8.0+;
• HTTPS;
• Apache or Nginx as recommended web-server choices.

Those requirements answer “can this server run WordPress?” They do not answer “how much VPS does this production workload need?”

A production VPS also needs RAM/CPU/storage for:

• Linux;
• Nginx/Apache;
• PHP-FPM workers;
• MySQL/MariaDB;
• OPcache;
• page/object cache where used;
• control panel;
• mail if hosted locally;
• backups;
• cron jobs;
• malware/security scans;
• imports/exports;
• monitoring;
• operating headroom.

Do not use the WordPress software requirements as a production resource recommendation.

WordPress VPS Fit Checker

Use this checker as a starting point. It does not replace real CPU/RAM/database measurements.

When WordPress actually needs VPS

A WordPress site can justify VPS even without huge traffic.

Common reasons:

• repeated CPU/memory/process limits under legitimate load;
• need for a custom PHP/runtime configuration;
• need for Redis/Memcached or another server-side service;
• real system cron instead of visitor-triggered scheduling;
• long-running background jobs;
• custom Nginx/Apache behavior;
• several sites that need one controlled environment;
• stronger workload/account isolation;
• server-level monitoring or firewall requirements.

If the only symptom is “the site is slow,” first compare VPS vs Shared Hosting and verify that WordPress itself is not the bottleneck.

When WordPress does not need VPS

Stay on good shared or managed WordPress hosting when:

• the site is light and stable;
• caching works;
• the host’s resource meters are not showing repeated limits;
• no custom service/root access is required;
• the team does not want to maintain Linux;
• the provider already handles backups, security, updates or staging well enough;
• the VPS would mainly replace a simple hosting service with more operational work.

VPS is not automatically faster. A poorly sized or untuned VPS can run WordPress worse than a good managed platform.

PHP workers and RAM

For uncached requests, PHP-FPM workers are a major concurrency limit.

Each active worker consumes memory while processing a request. More workers can handle more simultaneous dynamic requests, but increasing the worker count without increasing the RAM budget can cause:

• swap;
• memory pressure;
• OOM kills;
• database starvation;
• server instability.

A practical model is:

WordPress RAM = OS + web server + database + cache + PHP workers + panel/mail/jobs + headroom

Then:

PHP worker budget = RAM safely available to PHP / measured average worker memory

Do not configure the theoretical maximum number of workers if doing so leaves no memory for MySQL/MariaDB, cache or the operating system.

Logged-in users, wp-admin, REST/API requests, search, forms, preview and personalized pages are more likely to bypass full-page cache and consume PHP workers.

WordPress caching layers

Caching is not one feature.

WordPress’s own optimization documentation recommends caching as a major performance tool. But these layers solve different problems.

Do not call Redis a page cache. Redis is commonly used as a persistent object-cache backend; full-page caching is a separate layer.

Persistent object cache and Redis

WordPress includes an object-cache API, but the default cache is not persistent across requests.

Persistent object caching requires an external backend/drop-in such as Redis or Memcached plus the appropriate WordPress integration.

It can help when the site repeatedly performs expensive database/object work, but it is not an automatic speed button.

Before adding Redis:

• confirm the site/database workload benefits;
• verify enough RAM remains for PHP and the database;
• monitor hit rate and memory;
• keep page caching as a separate decision.

A site with efficient full-page caching and light database work may gain less from Redis than a dynamic membership or query-heavy site.

Database demand

WordPress performance can become database-limited before CPU is visibly saturated.

Check:

• slow queries;
• large options/autoloaded data;
• plugin metadata;
• search/filter/reporting queries;
• postmeta-heavy workloads;
• database working set;
• concurrent writes;
• imports/exports;
• storage latency.

More CPU does not repair a pathological query. More RAM can help when the database legitimately needs a larger working set, but it does not replace indexing/query/plugin work.

Measure first, then scale.

Plugins, themes and background jobs

A plugin is not only disk space.

Plugins/themes can add:

• PHP work;
• database queries;
• external API calls;
• scheduled tasks;
• cache invalidation;
• admin AJAX;
• image processing;
• security scanning;
• backups;
• imports/exports;
• analytics/logging.

Heavy tasks can collide with real traffic.

Schedule backups, scans, imports and image-processing jobs away from peak periods where practical. If one plugin or job causes the resource spike, fix or reschedule it before assuming the VPS is too small.

WP-Cron and background jobs

WP-Cron is triggered by WordPress requests rather than running continuously like a system scheduler.

That can be acceptable for ordinary sites. For time-sensitive or busy workloads, WordPress’s own developer documentation describes using the operating system’s scheduler to call WordPress cron on a controlled interval.

If you move to a system scheduler:

• create the replacement trigger first;
• verify it works;
• only then disable the normal visitor-triggered WP-Cron behavior if that is part of the plan;
• log and monitor failed jobs.

Do not disable WP-Cron without another scheduler.

Storage, media, staging and backups

Disk planning must include more than WordPress core.

Budget for:

• uploads/media;
• database;
• plugins/themes;
• logs;
• cache files;
• temporary update files;
• image-processing temp space;
• staging copy;
• backup archives before they are moved off-server;
• expected growth.

A site using 20 GB today can need materially more temporary space during a clone, restore, plugin update or backup compression job.

Do not keep the only backup on the VPS.

Manual, control panel or FASTPANEL?

WordPress can run perfectly well without cPanel or another panel.

Manual Linux

Good fit when you want:

• minimal stack;
• SSH administration;
• custom Nginx/Apache/PHP/database configuration;
• automation or Git-based deployment.

Use How to host a website on VPS for the manual deployment path.

Generic control panel

Useful when browser-based domains, SSL, PHP, databases, users, mail or backups remove enough repetitive work.

Use VPS with Control Panel.

FASTPANEL

FASTPANEL’s official workflow supports WordPress site creation. VDSina currently lists FASTPANEL on Ubuntu 22 as a preconfigured panel option.

Use FASTPANEL VPS Hosting for the branded setup/sizing path.

A control panel simplifies administration; it does not make the VPS managed.

Managed vs self-managed WordPress VPS

On a self-managed VPS, somebody must own:

• OS/package updates;
• SSH/firewall;
• PHP/web-server updates;
• database administration;
• WordPress/plugin/theme updates;
• backups and restore tests;
• monitoring;
• incidents.

If nobody owns those jobs, choose managed administration rather than assuming WordPress or a control panel will manage the server.

See Managed vs Unmanaged VPS.

WooCommerce is a different WordPress workload

WooCommerce shares the WordPress stack but behaves differently under real store traffic.

Cart, checkout, account, orders, stock and many scheduled actions are dynamic and cannot be treated like anonymous cached blog pages.

If store transactions matter, use VPS for WooCommerce for the dedicated sizing/operations model.

Multiple WordPress sites

Several WordPress sites share:

• CPU;
• RAM;
• database service;
• PHP workers/pools;
• storage;
• cron/background-job windows;
• backup time;
• failure domain.

Ten quiet cached sites can be lighter than one busy dynamic membership site.

Use separate users/database credentials where appropriate, and size from the combined peak, not the domain count.

See VPS for Multiple Websites.

WordPress VPS upgrade triggers

Upgrade only after measuring a real constraint.

Strong triggers:

• sustained RAM pressure, swap or OOM events;
• repeated PHP worker queue/saturation;
• sustained CPU saturation after cache/query/plugin optimization;
• database latency caused by legitimate working-set pressure;
• storage growth beyond safe operating headroom;
• background jobs repeatedly colliding with live traffic;
• multiple active sites exhausting shared resources.

If the website is slow while these signals remain healthy, a larger VPS may not be the fix.

WordPress VPS launch checklist

For an existing production site, use Website migration to VPS for cutover, final writes, DNS and rollback.

Current WordPress VPS examples

These VDSina Standard configurations are current examples, not WordPress traffic guarantees.

VDSina’s current Standard page does not list WordPress as a dedicated preinstalled application in its visible template/application groups. Use a pure OS/manual path or a current compatible control-panel path instead of assuming a one-click WordPress image.

Check current WordPress 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

• WordPress.org — current requirements
• WordPress Developer Handbook — caching
• WordPress Developer — object cache
• WordPress Developer — system scheduler and WP-Cron
• VDSina Standard VPS

FAQ

How much RAM does WordPress need on a VPS?

WordPress core does not define a production VPS RAM requirement. RAM must cover Linux, the web server, PHP workers, database, caches, panel/mail/background jobs and headroom. A lean site may fit 2 GB; 4 GB is a stronger practical baseline for a business site.

Is 1 GB RAM enough for WordPress VPS?

It can run a very lean/test WordPress setup, but leaves little headroom for the database, PHP workers and background work. It should not be treated as the normal production recommendation.

Is 2 GB RAM enough for WordPress?

It can be enough for a small, well-cached site with a lean stack. Monitor PHP worker memory, database RAM, plugins and background jobs.

Is 4 GB RAM enough for WordPress?

For many business WordPress sites, 4 GB is a practical starting point. Heavy plugins, membership traffic, WooCommerce, large databases, imports or several active sites can require more.

How many visitors can a WordPress VPS handle?

There is no reliable universal visitor number. Cache hit rate, uncached concurrency, PHP request duration, plugin cost, database work and background jobs determine capacity.

Do I need Redis for WordPress on VPS?

No. Redis can provide persistent object caching when the workload benefits from repeated object/database caching, but it is not required for every WordPress site and does not replace full-page caching.

Should I use Nginx or Apache for WordPress VPS?

Both are valid. WordPress.org recommends Apache or Nginx as robust choices. Use the stack your application and administrator can operate reliably.

Should I replace WP-Cron with system cron?

Only when the workload benefits from a controlled scheduler and you configure a working replacement. Do not disable WP-Cron without another trigger.

Does WordPress VPS need a control panel?

No. WordPress can run on a manually managed Linux VPS. A panel is optional and should be chosen for administration convenience, not as a performance requirement.

Does VDSina include WordPress preinstalled?

The current Standard VPS page does not list WordPress as a dedicated preinstalled application in the visible template/application groups. Verify the live order screen before assuming any template availability.