How to Choose a VPS for WordPress in 2026: RAM, PHP, MySQL, Caching, and Security

You should not choose a VPS for WordPress based only on the number of visitors or generic CMS requirements. At the same traffic level, a blog with full-page caching and an online store with user accounts create very different loads.

The basic guidelines are as follows:

These are not strict requirements, but a safe starting point. Actual load depends on the theme, the number and quality of plugins, database size, page update frequency, and the share of logged-in users.

For most projects, the following stack is suitable:

• Nginx or Apache;
• PHP-FPM;
• OPcache;
• MySQL or MariaDB;
• page cache;
• Redis object cache for dynamic sites;
• CDN and WAF;
• External backups;
• a staging copy for updates.

The minimum 1 GB of RAM is suitable only for a very simple site with low traffic. On this type of VPS, memory can run out quickly during plugin updates, data imports, page builder operations, or traffic spikes.

For a typical WordPress site, 2 GB of RAM is a more reasonable minimum. For WooCommerce and heavy visual page builders, start at 4 GB or more and monitor the available headroom.

Caching is mandatory. Without it, every request runs PHP again and queries the database. Page cache reduces load on public pages, OPcache speeds up PHP, and Redis reduces the number of repeated database queries.

However, with WooCommerce, for example, you should not blindly cache the cart, checkout, user account, and other personalized pages. These URLs must be excluded from full-page caching.

On a high-load site, the standard wp-cron should be replaced with system cron. Otherwise, background tasks are triggered by visits and can add extra load during peak periods.

Before launch, you also need to:

• Limit or disable XML-RPC if it is not used;
• Enable automatic backups;
• Configure WAF and CDN;
• Update WordPress, themes, and plugins regularly;
• Test changes on staging;
• Monitor CPU, RAM, disk usage, and slow queries.

The main mistake is choosing a VPS with no headroom. It is better to leave extra RAM and CPU capacity at least for updates, backups, data imports, and short-term load spikes.

What WordPress VPS Requirements Depend On

Traffic and Concurrent Requests

Overall traffic provides only a rough indication of a project’s scale. When choosing a VPS, what matters is not only the number of visits per day, but also how many users access the site at the same time.

Ten thousand visits spread evenly throughout the day create a lower peak load than a sudden influx of several hundred users after an email campaign, a news publication, or the launch of an advertising campaign.

The number of requests generated by a single page also matters. WordPress may invoke PHP, query the database, call external APIs, and access the file system several times during a single page load.

Page caching, a CDN, and an optimized theme help reduce the load. If a ready-made HTML page is served from the cache, the server does not need to execute PHP and database queries again for each visitor.

However, even with the same traffic, two sites can consume resources in completely different ways because of their themes, plugins, and how their pages are built.

Theme, plugins, and page builders

A lightweight theme with a few proven plugins usually requires less CPU and RAM than a site with a large set of extensions and a visual builder.

Elementor, WPBakery, and similar tools add complex markup, extra styles, scripts, and dynamic requests. This affects not only browser performance, but also PHP processing during editing and page generation.

The following can create a particularly noticeable load:

• Analytics plugins;
• Search and filtering;
• Backups performed on the server itself;
• Import and export;
• Security scanners;
• Image generation;
• Related posts and complex widgets;
• Plugins with slow SQL queries.

The number of plugins is not always meaningful on its own. Ten simple extensions may be lighter than a single resource-heavy module. For this reason, you should evaluate actual memory usage, PHP execution time, and database queries.

At the same time, caching does not cover every scenario. Logged-in users and personalized pages often bypass the full page cache and generate dynamic load.

Dynamic Pages and Authenticated Users

A blog or a standard corporate website can be served almost entirely from the page cache. WooCommerce, user accounts, forums, and services with authentication work differently.

The cart, checkout, user profile, purchase history, and admin panel are generated individually. These pages cannot be blindly cached as shared HTML for all visitors.

As a result, each request runs PHP and queries the database. The more concurrent authenticated users there are, the more important the following become:

• Individual CPU core performance;
• RAM capacity for PHP-FPM and the database;
• NVMe speed;
• OPcache;
• Redis object cache;
• SQL query optimization.

WooCommerce also creates background tasks, processes webhooks, recalculates stock levels, and sends emails. As a result, an online store usually requires more resources than an informational website with the same traffic volume.

However, server sizing should account for more than normal operation. Updates, backups, and traffic spikes temporarily increase the load.

Resource Headroom for Updates and Peak Loads

A plan that consistently uses almost all available RAM and CPU will work only until the first unusual event. A plugin update, archive creation, catalog import, or sudden traffic spike can quickly consume the remaining resources.

RAM is especially sensitive to shortages. It is used simultaneously by:

• The operating system;
• The web server;
• PHP-FPM processes;
• MySQL or MariaDB;
• Redis;
• Antivirus software and other security tools;
• Backup processes;
• The control panel, if one is installed.

When RAM is insufficient, the server starts using swap heavily or terminates processes via the OOM killer. For users, this appears as slow loading, 502 or 503 errors, or database unavailability.

For this reason, it is better to choose a VPS with at least 25–30% memory and CPU headroom under normal load. Projects with advertising campaigns, news-driven traffic surges, and bulk imports require an even larger reserve.

After assessing traffic, the complexity of the WordPress build, the share of dynamic requests, and the required reserve, you can move on to specific configurations for a blog, corporate website, WooCommerce store, news site, and projects built with site builders.

VPS Configurations for Different WordPress Sites

Blog and Small Informational Website

For a simple blog or small informational website, 1–2 vCPUs, 2 GB of RAM, and an NVMe drive are usually sufficient.

If pages are well cached and the theme and plugins are not bloated, this type of VPS can comfortably handle moderate traffic. Page cache, OPcache, and a CDN play the key role here: most requests can be served without re-running PHP or accessing the database.

It is worth moving to 4 GB of RAM if a visual editor is used heavily, backups are created directly on the server, or the site periodically sees noticeable traffic spikes.

A corporate website usually has a similar load profile, but more often includes more integrations and utility functions.

Corporate website

For a corporate website, a reasonable starting point is 2 vCPUs and 2–4 GB of RAM. Storage should, of course, be NVMe.

Additional load can come from forms, multilingual support, CRM integrations, service catalogs, search, user accounts, and security plugins. Even with low traffic, these features make the site more resource-intensive than a typical blog.

If the project is used as an important sales channel, it is better to choose 4 GB of RAM from the start. This provides headroom for updates, backups, data imports, and background tasks.

For an online store, this is usually no longer sufficient, because most requests cannot be served entirely from the page cache.

WooCommerce

For a small WooCommerce store, a good starting point is around 4 vCPUs and 6–8 GB of RAM, along with fast NVMe storage.

The cart, checkout, customer account, inventory, and webhooks are all dynamic. These pages cannot be cached as shared HTML, so every request puts load on PHP and the database.

CPU performance, sufficient RAM for PHP-FPM and MySQL, Redis object cache, and a fast NVMe disk are especially important. With a large catalog, load also increases from search, filters, imports, and product recalculations.

If managers, customers, payment integrations, and background tasks are all active in the store at the same time, a configuration with no headroom will quickly run into memory or CPU limits.

For a news site, load is shaped differently: it depends more heavily on sudden traffic spikes.

News or Content Project

A news site or large content-heavy website typically requires at least 4 vCPU and 8 GB of RAM, while high-traffic projects need 8 vCPU and 16 GB of RAM or more. Storage should be NVMe only.

These projects cache well, but they may experience sudden spikes in users after a news item is published, appears in recommendations, or is included in an email campaign.

Full-page caching, a CDN, a WAF, and proper cache behavior after content updates are especially important here. If every new article triggers a full cache purge, the server may suddenly receive hundreds of dynamic requests at once.

In addition to traffic, load is generated by editors, autosaves, search, recommendations, and image generation. For a news site, what matters is not only the amount of RAM, but also the infrastructure’s ability to handle short spikes.

Sites built with Elementor and WPBakery may have lower traffic but still require significantly more resources because of the page builder itself.

Website Built with Elementor or WPBakery

For a project built with Elementor or WPBakery, a reasonable minimum is 2–4 vCPUs and 4 GB of RAM.

Page builders increase the amount of PHP code, database queries, CSS, and JavaScript. The admin area can be especially resource-intensive: editing pages, saving templates, and generating styles require more memory than simply viewing the site.

If WooCommerce, multilingual functionality, complex forms, and several large page builder add-ons are used at the same time, it is better to plan for 6–8 GB of RAM.

Page caching significantly speeds up the public-facing part of the site, but it does not help the editor or logged-in users. As a result, the site may load quickly for visitors while still feeling slow in the admin area.

After reviewing the site types, the guidelines for traffic, vCPU, RAM, and storage can be summarized in a single configuration table.

Configuration table by traffic volume

Traffic volume should not be used as the only criterion, but it helps determine the initial resource range. For WooCommerce, sites with user accounts, and resource-intensive page builders, choose the upper end of the range.

These values assume that WordPress is configured and that pages are not regenerated through PHP on every request.

Up to 1,000 visits per day

For a small blog or company website, 1–2 vCPUs and 2 GB of RAM are usually sufficient. This configuration is suitable for a lightweight theme, a small number of plugins, and a properly configured page cache.

If the site is built with Elementor, regularly creates local backups, or uses a resource-intensive security plugin, it is better to choose 4 GB of RAM from the start.

Even with low traffic, a 1 GB plan may be too limited: the operating system, PHP-FPM, the database, and background processes will all need memory.

As traffic grows, the main constraints become concurrent requests and PHP processing.

From 1,000 to 10,000 visits per day

For this range, a reasonable starting point is 2–4 vCPUs and 4 GB of RAM.

A VPS with these resources is suitable for a corporate website, a content project, or a small catalog, provided that public pages are cached and images are delivered via a CDN or optimized.

For WooCommerce and user account areas, it is better to plan for at least 6–8 GB of RAM, because a significant share of requests remains dynamic.

If the CPU is regularly under load and requests are queuing up in PHP-FPM, increasing RAM alone may not be enough; you will need more compute cores or code optimization.

The next range requires more careful database and object cache tuning.

From 10,000 to 50,000 visits per day

For a content project or news site, 4–8 vCPUs and 8–16 GB RAM are typically considered.

With good full-page caching, a significant portion of the load can be offloaded to a CDN. However, after the cache is cleared, a news item is published, or a large number of users arrive at once, the server must be able to handle a spike in dynamic requests.

In this range, Redis object caching, dedicated MySQL monitoring, PHP-FPM tuning, and slow query tracking become especially useful.

Up to €20,000 in EU-Based IaaS Credits

Frankfurt infrastructure, predictable pricing, and expert migration support.

Get

For WooCommerce, the key factors are not daily traffic but the number of concurrent shoppers, catalog size, filter behavior, and the number of background tasks.

Beyond 50,000 visits, a single VPS may still be able to cope, but the margin for error and traffic spikes becomes critical.

More than 50,000 visits per day

For a high-traffic WordPress site, it is best to start with 8 vCPUs and 16 GB of RAM, then adjust resources based on actual metrics.

At this level, a CDN, a WAF, Redis, efficient page caching, external monitoring, and a separate staging copy are typically required. As traffic continues to grow, the database and file storage may be moved to separate nodes.

A single powerful VPS is not always the right choice. If the project regularly experiences sharp traffic spikes, it is better to plan for scaling, a load balancer, or a managed database.

The key benchmark is not the average number of visits, but CPU load, RAM usage, PHP response time, the number of database queries, and how the site behaves during peak activity.

After choosing an approximate range, you can separately determine how many cores, how much memory, and how much disk space WordPress actually requires.

How to Choose CPU, RAM, and Disk

How Many Cores Does WordPress Need?

WordPress does not always scale well simply by adding a large number of cores. For most sites, strong single-core performance is more important, because an individual PHP request usually runs sequentially.

For a small blog or corporate website, 1–2 vCPUs are sufficient. If you use WooCommerce, a heavy page builder, a highly active admin area, or have many concurrent requests, it is better to start with 4 vCPUs.

Additional cores are especially useful when the following are running at the same time:

• Multiple PHP-FPM processes;
• The database;
• Redis;
• cron jobs;
• Backups;
• Product imports;
• Image generation;
• Security scanning.

If the CPU is nearly maxed out only during infrequent updates, upgrading your plan immediately is not always necessary. However, sustained high load, a PHP-FPM queue, and increasing response times indicate a shortage of compute resources.

At the same time, adding more cores will not solve the problem if the server is constrained by RAM.

How Much RAM to Allocate

RAM is not used by WordPress alone. The operating system, web server, PHP-FPM, MySQL or MariaDB, OPcache, Redis, and background processes are all in memory at the same time.

For a simple website, 2 GB of RAM is a reasonable minimum. For Elementor, WPBakery, a corporate project with several integrations, or a small WooCommerce store, it is better to plan for 4–8 GB.

Additional headroom is especially important for:

• Updating WordPress and plugins;
• Importing data;
• Creating a backup;
• Work by editors;
• Traffic spikes;
• Running multiple PHP processes at the same time.

When memory runs out, the server starts using swap or terminating processes. This can result in database errors, 502 and 503 errors, an unresponsive admin area, and slow page loading.

Under normal load, it is advisable to keep at least 25–30% of RAM available. This gives the server enough capacity to handle a short-term spike without forcibly terminating services.

In addition to memory, disk speed also plays a significant role, especially for the database and large numbers of small files.

Why NVMe Matters More Than a Large Slow Disk

WordPress constantly accesses the file system and the database. It reads PHP files, plugins, themes, cache, images, and MySQL tables.

For this type of workload, storage capacity is not the only thing that matters; random I/O performance is important as well. NVMe is typically much faster than a standard HDD and many SATA SSDs, especially when handling a large number of small requests.

A fast disk helps speed up:

• Database queries;
• Plugin and theme loading;
• Admin panel performance;
• Cache generation;
• Import and export operations;
• Backup creation;
• Image processing.

For a small site, 40 GB of NVMe is often more useful than 200 GB of slow disk space. You can reduce local storage usage by using external backup storage, a CDN, and object storage for large files.

However, a fast disk does not compensate for insufficient RAM or an overloaded CPU. That is why the decision to move to a more powerful plan should be based on the full set of metrics.

When It’s Time to Move to a More Powerful VPS

You should increase resources not after the first traffic spike, but when resource limits become a recurring issue and start affecting users.

Key indicators:

• CPU usage frequently stays above 80–90%;
• There is almost no free RAM left;
• Swap is being used heavily;
• 502, 503, or OOM errors start appearing;
• PHP-FPM is building up a queue;
• The database responds slowly;
• The admin area is slow even without high external traffic;
• Backups and updates noticeably degrade site performance;
• The disk regularly hits its IOPS limit or runs low on free space.

Before upgrading, check caching, heavy plugins, slow SQL queries, and PHP-FPM settings. In some cases, optimization delivers a greater impact than moving to a more expensive plan.

If the site has already been optimized and the load continues to grow, it is better to increase resources in advance. For WordPress, it is safer to have spare capacity than to wait until the next peak fully exhausts CPU or RAM.

After choosing the CPU, memory, and disk, you can move on to the server stack: the web server, PHP-FPM, OPcache, the database, and Redis.

Recommended WordPress Stack

Nginx or Apache

Both web servers are suitable for WordPress. The choice depends on the project’s current configuration, the administrator’s preferences, and the rules being used.

Apache is convenient because it supports .htaccess. Many WordPress plugins and guides are designed with it in mind, so configuring redirects and pretty permalinks usually does not require manually moving rules into the main configuration file.

Nginx does not use .htaccess, but it handles large numbers of concurrent connections and static file delivery well. All redirect, access restriction, and URL handling rules are defined centrally in the server configuration.

For a new project, Nginx with PHP-FPM is often chosen. If a site is being migrated from Apache and relies heavily on .htaccess, it is usually easier to keep the existing stack at first and switch to Nginx separately after testing.

The web server itself does not execute PHP code. A separate handler is required for that.

PHP-FPM and an Up-to-Date PHP Version

PHP-FPM manages the processes that execute WordPress code. It lets you limit the number of processes running concurrently and control memory usage.

A pool that is too small creates a request queue and slows page loading. A pool that is too large can quickly exhaust RAM, especially if plugins consume a lot of memory each time they run.

PHP-FPM settings should be tuned based on:

• The amount of RAM;
• The average memory usage of a single PHP process;
• The number of concurrent requests;
• The proportion of pages not served from a full-page cache;
• The load from the admin panel and cron.

For a new site, use an up-to-date supported PHP version that is compatible with WordPress, the theme, and the plugins. Before changing versions, test it on a staging copy: an outdated extension can cause warnings, errors, or make the site completely unavailable.

After selecting the PHP version, enable OPcache so the interpreter does not compile the same files on every request.

OPcache for Speeding Up PHP

During normal operation, PHP reads and compiles application files before executing them. OPcache stores the compiled bytecode in memory and reuses it for subsequent requests.

This is especially useful for WordPress, where the core, theme, and plugins consist of a large number of PHP files. OPcache reduces CPU load and speeds up the generation of dynamic pages.

It needs enough allocated memory to work effectively. If the cache is too small, some files will be constantly evicted and recompiled.

OPcache does not replace page cache or Redis:

• page cache stores ready-made HTML;
• OPcache speeds up PHP execution;
• Redis stores objects and the results of recurring queries.

After speeding up PHP, the database becomes the next key component.

MySQL or MariaDB

WordPress supports MySQL and MariaDB. For most projects, both systems are suitable, so the choice should be based on compatibility, available versions, and the administrator’s experience.

Database performance depends on more than the product name. More important factors include the amount of allocated memory, disk speed, indexes, table size, and the quality of plugin queries.

Over time, the database may accumulate:

• Outdated revisions;
• Temporary data;
• Expired transients;
• Sessions;
• Plugin logs;
• Residual tables from removed extensions.

Basic cleanup should not be run automatically without a backup: some records may be used by the theme, the store, or integrations.

On a typical VPS, the database usually runs on the same server and should not be exposed to the internet. As load increases, it can be moved to a separate node or a managed service.

A persistent object cache helps reduce the number of repeated database queries.

Redis for object caching

WordPress can temporarily store the results of computations and queries in the object cache. By default, this cache exists only for the duration of a single request and is discarded after the request ends.

Redis makes the object cache persistent across requests. Repeatedly used data can be retrieved from RAM instead of querying MySQL or MariaDB each time.

Redis provides the greatest benefit for:

• WooCommerce;
• Sites with authentication;
• Large catalogs;
• News projects;
• Multilingual sites;
• Projects with frequent database queries.

For a small blog that can be fully cached, the impact may be moderate. In that case, it is more important to configure page caching, OPcache, and a CDN first.

Redis also consumes RAM, so it should not be enabled without monitoring limits and the actual cache hit rate. After enabling it, you need to make sure that WordPress is actually using a persistent object cache and that the data is not crowding out memory needed by PHP and the database.

Once the basic stack is configured, the next level of optimization is caching: complete pages, objects, browser resources, and content on a CDN.

WordPress Caching

Page cache

The page cache stores a ready-made HTML version of a page and serves it without rerunning PHP or querying the database.

For a blog, corporate website, or news project, this is one of the most effective ways to reduce the load on a VPS. The more pages that can be served from a full cache, the fewer PHP-FPM processes and MySQL queries are needed during traffic spikes.

Caching can be configured at the plugin, web server, or external CDN level. The cache must be purged correctly after content is published or updated, but it should not be cleared completely unless necessary.

Full Control Over Your Kubernetes Infrastructure

Deploy production-ready Kubernetes with full control over nodes, storage, and networking on predictable-cost EU infrastructure with direct access to your resources.

Get

For dynamic projects, full-page caching is no longer sufficient, so the object cache becomes the next layer.

Object cache

The object cache stores the results of repeated queries and computations. This reduces the number of requests WordPress sends to MySQL or MariaDB.

By default, this cache is valid only within a single request. Redis makes it possible to persist objects between requests and is especially useful for WooCommerce, user accounts, large catalogs, and multilingual sites.

However, Redis does not replace the page cache. Redis speeds up the dynamic part of WordPress, while the page cache can avoid running PHP altogether for prebuilt pages.

After configuring server-side caching, you should set up asset caching in the browser and on the CDN.

Browser Cache and CDN

Browser caching stores CSS, JavaScript, fonts, and images on the user’s device. When the page is opened again, the browser does not need to download all resources again.

A CDN places copies of static files closer to users and offloads some of the load from the VPS. For an international website, this also helps reduce latency between the visitor and the server.

A CDN can serve images, stylesheets, scripts, and sometimes fully cacheable HTML pages. However, the rules must be configured carefully, especially if the site includes authentication, personal data, or a shopping cart.

This is why a single caching policy cannot be applied to all URLs in WooCommerce.

What Not to Cache in WooCommerce

In WooCommerce, pages that contain personal data must be generated separately for each user. These include the cart, checkout, My Account area, and related AJAX requests.

The following are usually excluded from the full-page cache:

• /cart/;
• /checkout/;
• /my-account/;
• Requests with cart and authentication cookies;
• WooCommerce service endpoints.

If these pages are cached as shared HTML, one user may see another user’s cart, outdated prices, or an incorrect order status.

Product pages and category pages, by contrast, can usually be cached if the system correctly updates the data after changes to prices, stock levels, and promotions.

After configuring the cache, you need to test the site as a guest, as a logged-in user, and as a buyer with an item in the cart. This is the only way to make sure that the performance improvement does not break personalized user flows.

The next important layer of reliability is external backups and a staging copy for safely testing updates.

Backups and a staging copy

What to include in a backup

To restore WordPress, saving only the site files or only the database is not enough. You need both components, as well as the environment configuration.

A backup typically includes:

• The WordPress directory;
• User uploads;
• The database;
• wp-config.php;
• Web server configuration;
• cron jobs;
• PHP settings;
• Redirect rules;
• DNS and external integration details.

The wp-content directory, the database, and configuration files are especially important. They contain themes, plugins, media, users, posts, orders, and site settings.

Secrets and passwords should not be stored in plaintext next to a regular archive. Backups should be encrypted or stored in secure storage.

After defining the backup scope, you need to choose a frequency that matches how quickly the site changes.

How often to back up files and the database

The frequency depends on the type of project. For a small blog, a daily backup is usually enough, while a WooCommerce store with a steady flow of orders may require the database to be backed up several times a day.

Files change less often than the database. Therefore, they can be backed up, for example, once a day or after updates, while the database should be backed up more frequently.

A general guideline is as follows:

Backups should be stored outside the primary VPS. Otherwise, deleting the server, a disk failure, or a system compromise will destroy both the site and its copies.

However, having files in storage does not prove that the site can be restored. You should periodically check the archives and import the database dump into a test environment.

Snapshot helps roll back the server more quickly, but it solves a different problem.

Why a snapshot does not replace a backup

A snapshot captures the state of a virtual machine or disk at a specific point in time. It is useful before updating the system, changing PHP, or making a major configuration change.

However, a snapshot may be stored within the same provider infrastructure, be deleted along with the VPS, and depend on the existence of a specific virtual machine. In addition, an active database may not always be in a fully consistent state when the snapshot is created. Keeping a snapshot for an extended period can also negatively affect performance, so it is recommended to delete it after the work has been completed successfully.

A full backup is different because it is stored separately and allows individual components to be restored: the database, uploads directory, theme, or configuration.

It is best to use both tools:

• snapshot — for quickly rolling back the entire server;
• external backup — for independent data recovery.

However, even a good backup should not be the first way to test updates. A staging copy is needed for that.

What a staging copy is for

Staging is a separate test copy of a website where you can safely test updates to WordPress, PHP, themes, and plugins.

It is especially useful before:

• Changing the PHP version;
• Updating WooCommerce;
• Installing a new plugin;
• Changing the theme;
• Running a bulk import;
• Changing cache and web server settings;
• Changing the URL structure.

Staging should not be indexed or send real emails, orders, or webhooks. It is best to protect it with authentication, restrict access by IP, and also add a noindex directive.

The copy should also not be connected to production payment systems, CRMs, or mailing services unless test mode is enabled. Otherwise, testing may create real operations.

After a successful test, the changes are moved to the live site, but a fresh backup is still created before they are applied. This process reduces the risk of downtime and helps identify problems before visitors see them.

Once backups and staging are configured, you can move on to protecting WordPress, files, the login page, and the external perimeter.

WordPress Security on a VPS

WordPress, Theme, and Plugin Updates

Outdated plugins and themes remain one of the leading causes of WordPress compromises. Even if the VPS itself is configured correctly, a vulnerable extension can give an attacker access to the site, the database, or the file system.

The following should be kept up to date:

• WordPress core;
• The active theme;
• Installed plugins;
• PHP and system packages;
• The web server and database.

Unused themes and plugins should be removed rather than simply disabled. Their files remain on the server and may also contain vulnerabilities.

Critical fixes should not be postponed, but major updates are safer to test on a staging copy first. This is especially important for WooCommerce, page builders, payment modules, and extensions that modify the database structure.

Updates reduce the risk of known vulnerabilities being exploited, but they do not filter malicious requests. A secure network perimeter is required for that.

Firewall, WAF, and CDN

A standard firewall restricts access to VPS ports. Only services that are actually needed should be accessible from the outside, typically SSH, HTTP, and HTTPS.

Databases, Redis, admin panels, and internal services should not be exposed to the internet unless necessary. Access to them should be allowed only locally or from a trusted network.

A WAF operates at a higher level and analyzes HTTP requests. It can block SQL injection attempts, malicious requests targeting plugins, login form brute-force attempts, and other suspicious traffic.

A CDN, in turn, reduces the load on the VPS, caches static files, and hides the direct IP address of the origin server. Many CDNs also provide basic WAF rules and protection against some DDoS attacks.

However, a WAF does not fix a vulnerable plugin and is not a substitute for updates. It is an additional barrier that reduces the likelihood of a successful attack.

The next layer is protecting the WordPress administrative login and interfaces.

Securing Login and Restricting XML-RPC

The WordPress login page is regularly targeted by automated password brute-force attacks. To protect it, use strong, unique passwords, two-factor authentication, and limits on the number of login attempts.

It is also useful to:

• Avoid using the username admin;
• Remove unnecessary administrator accounts;
• Assign users only the minimum roles they need;
• Restrict access to the dashboard by IP address or VPN, if possible;
• Enable logging for logins and changes.

The xmlrpc.php file is used for remote publishing, some mobile applications, and integrations. If these features are not needed, XML-RPC can be disabled or restricted at the web server, WAF, or security plugin level.

If left unrestricted, XML-RPC can be used for credential brute-forcing and abuse of pingback requests. However, it should not be disabled without checking first: some integrations may stop working.

Even a protected dashboard will not help if the site files are writable by all processes.

File Permissions and Access to wp-config.php

WordPress files should not have 777 permissions. This setting can sometimes temporarily resolve a write error, but it also allows any process with server access to modify the site.

Directories typically use 755 permissions, while files use 644. The exact values depend on the PHP-FPM user, the project owner, and how WordPress updates are handled.

Write access is required only for specific directories: uploads, cache, temporary files, and sometimes update directories.

Special attention should be paid to wp-config.php. It contains database connection details, keys, and other sensitive settings. The file must not be accessible through a browser and should have the most restrictive permissions compatible with the site’s operation.

It is also advisable to disable PHP execution in the user uploads directory. If an attacker manages to upload a malicious file, the web server must not execute it as a script.

After permissions have been configured, you still need to monitor the site for new vulnerabilities or signs of compromise.

Monitoring and Vulnerability Scanning

Without monitoring, a compromise or error can go unnoticed for weeks. You need to check not only whether the homepage is available, but also the status of the server, files, and WordPress.

Minimum monitoring should include:

• Website availability and HTTPS;
• 4xx and 5xx errors;
• CPU, RAM, and disk utilization;
• Changes to system and WordPress files;
• Suspicious logins to the admin panel;
• Creation of new administrator accounts;
• Outdated plugins and themes;
• PHP and database errors.

A vulnerability scanner helps identify known issues in WordPress and extension versions, but it does not guarantee complete protection. The results should be compared against the actual configuration, and fixes should not be applied automatically without a backup.

If suspicious activity is detected, it is important to preserve logs, restrict access, rotate keys and passwords, check files, and restore the site from a known clean copy.

WordPress security is not a one-time installation of a security plugin; it is an ongoing process. After setting up external protection and updates, background tasks should be configured separately, because the default wp-cron can create unnecessary load on a high-traffic site and run jobs unpredictably.

Configuring wp-cron on a high-traffic site

High-Performance Virtual Machines

Deploy in seconds with full root access, reserved resources, built-in high availability, and predictable monthly pricing.

Get

Why the default wp-cron creates unnecessary load

wp-cron is WordPress’s built-in mechanism for running background tasks. It handles scheduled publishing, temporary data cleanup, email sending, update checks, and plugin tasks.

By default, wp-cron does not run on a precise schedule; it is triggered when someone visits the site. This can be useful on small hosting environments without access to the system cron. Each request can initiate a check of the task queue. On a small project, this is barely noticeable, but under high traffic it creates unnecessary calls to PHP and the database.

The opposite problem can also occur: if the site receives few visits, scheduled tasks may run late. As a result, the default mechanism both adds unnecessary load on popular sites and does not guarantee precise execution on low-traffic sites.

For a high-traffic WordPress site, it is better to disable cron execution through user requests and delegate it to the system scheduler.

Moving Tasks to System Cron

First, the following parameter is added to the wp-config.php file: define(‘DISABLE_WP_CRON’, true);

It disables the automatic launch of wp-cron on page loads, but does not remove the scheduled tasks themselves.

After that, a system cron job is created on the server. For example, to run it every five minutes: crontab -e

You can add a call via WP-CLI to the schedule: /usr/local/bin/wp cron event run –due-now –path=/var/www/example.com/public –quiet

It is best to run WP-CLI as the system user that owns the site files. This reduces the risk of creating files with the wrong owner and causing permission issues.

If WP-CLI is not used, wp-cron.php can be invoked via PHP CLI or an HTTP request. However, running it on the server via WP-CLI is usually easier to control and log.

The interval depends on the project. For a typical site, 5–15 minutes is often sufficient, while an online store with order queues, emails, and integrations may need it to run more frequently.

After making the change, it is important to verify that tasks are actually running and are not accumulating in the queue.

Checking Background Task Execution

First, you need to view the list of scheduled events: wp cron event list –path=/var/www/example.com/public

The command shows the hook name, the next scheduled run time, and the recurrence interval.

Overdue tasks can be run manually: wp cron event run –due-now –path=/var/www/example.com/public

After it starts running, you should check:

• Scheduled publishing;
• Email delivery;
• Order processing;
• Cache cleanup;
• Synchronization with CRM systems and APIs;
• Backup tasks;
• Queues in WooCommerce and other plugins.

Cron errors should not disappear into the void. It is better to redirect task output to a separate log so you can see PHP failures, incorrect paths, and permission issues.

You should also check the absolute path to WP-CLI or PHP: the system cron environment usually differs from an interactive SSH session and may not see the same commands through PATH.

After moving wp-cron to the system scheduler, background tasks run more predictably, and user requests no longer trigger unnecessary checks. Next, we can look at the errors that most often prevent WordPress from using VPS resources efficiently.

Common Mistakes When Choosing and Configuring a VPS

Installing resource-intensive plugins without caching

A plugin may add complex SQL queries, image processing, search, filters, statistics, or background tasks. If the page cache and OPcache are not configured, each visit runs PHP again and queries the database.

The problem becomes apparent especially quickly on sites that use page builders, catalogs, and WooCommerce. Everything may appear to work normally with a small number of visitors, but as traffic grows, the server starts to run into CPU and PHP-FPM bottlenecks.

Before installing a resource-intensive extension, it is better to check its impact on response time, memory usage, and database queries. If the feature is needed, it should be combined with caching and tested in a staging environment.

However, even a well-configured cache will not eliminate the load from background tasks if wp-cron continues to be triggered by site visits.

Leaving wp-cron at its default settings

The default wp-cron checks the task queue whenever the site is accessed. On a high-traffic project, this creates unnecessary PHP runs, while on a low-traffic site, tasks may instead be delayed.

For reliable operation, it is better to disable execution via user requests and run due events on a schedule using the system cron.

After the migration, you need to check posts, emails, WooCommerce queues, imports, and integrations. The mere presence of a crontab entry does not mean it is working without errors.

The next common issue is no longer about performance, but about an unnecessarily large attack surface.

Failing to restrict XML-RPC

Not every site needs xmlrpc.php. It is used for some remote integrations, mobile apps, pingbacks, and external publishing.

If these features are not needed, leaving XML-RPC exposed creates an additional entry point for brute-force credential attacks and request abuse. It can be disabled or restricted at the web server, WAF, or security plugin level.

Before blocking it, check whether the mobile app, Jetpack, or other integrations use XML-RPC. Otherwise, the security measure could inadvertently break a working site feature.

However, restricting individual interfaces will not help if extensions with known vulnerabilities remain on the server.

Not Updating Plugins and Themes

Postponing updates gradually turns WordPress into a collection of outdated components. A vulnerability may exist not only in an active plugin, but also in an inactive theme whose files are still on the server.

Updates should be installed regularly, and unused extensions should be removed. Major changes, especially to WooCommerce, page builders, and payment modules, should be tested in a staging environment first.

Before updating, you need a fresh backup. Automatic installation without a rollback option can lead to version conflicts, but skipping updates altogether usually creates an even greater risk.

Even an up-to-date and optimized WordPress site will be unstable if plugins are installed indiscriminately.

Installing plugins indiscriminately

A common scenario is a WordPress site owner installing a large number of plugins while experimenting. This is relatively safe in a test environment, but on a production site it can lead to breakage due to incompatibilities, the installation of a "vulnerable" plugin that could be used to hack the site, and a significant impact on site performance.

That is why it is better to install only trusted plugins that are definitely needed, and to install them in a staging environment first.

However, even a limited list of trusted plugins will not help if the hosting plan was selected without any capacity headroom.

Choosing a plan with no RAM headroom

A plan with almost no free memory may work on a normal day but fail during an update, import, or backup.

RAM is used simultaneously by PHP-FPM, the database, Redis, OPcache, the web server, the operating system, and background processes. When memory is insufficient, the VPS either starts using swap or begins terminating services via the OOM killer.

For normal workloads, it is advisable to keep at least 25–30% headroom. If the site uses WooCommerce, Elementor, or WPBakery, or experiences sudden traffic spikes, the headroom should be higher.

Choosing a VPS with just enough resources is cost-effective only until the first unusual event. It is more reliable to account from the start not only for average load, but also for updates, backups, data imports, and peak traffic.

After reviewing the common mistakes, you can compile the main requirements for the VPS, caching, security, and redundancy into a short checklist.

Checklist for Choosing a WordPress VPS

Before ordering a VPS, make sure that:

• The configuration matches not only the traffic volume but also the type of site;
• A standard WordPress site has at least 2 GB of RAM;
• 4–8 GB of RAM is allocated for WooCommerce and resource-intensive page builders;
• An NVMe disk is used;
• There is at least 25–30% spare CPU and RAM capacity;
• An up-to-date PHP version compatible with the theme and plugins is selected;
• PHP-FPM and OPcache are configured;
• MySQL or MariaDB is used with sufficient memory;
• Redis object caching is provided for a dynamic site;
• Page caching is enabled and exclusions are configured for WooCommerce;
• CDN and WAF are used where justified;
• Backups are stored outside the VPS;
• A staging copy is available for updates;
• wp-cron is moved to system cron under high load;
• XML-RPC is restricted if it is not needed;
• Plugins, themes, and WordPress are updated regularly;
• Monitoring is configured for CPU, RAM, disk, PHP, and the database.

If the site is already running, it is better to choose a new plan based on actual metrics. Sustained CPU load, active swap usage, the PHP-FPM queue, and 502 or 503 errors provide a more accurate picture than traffic volume alone.

Conclusion

When choosing a VPS for WordPress, you need to consider the type of site, the share of dynamic pages, the number of plugins, and the nature of the load. The same amount of traffic affects a cacheable blog, a WooCommerce store, and an Elementor-based project in different ways.

For a small site, 1–2 vCPUs and 2 GB RAM are usually enough. Corporate projects, sites built with page builders, and online stores need more headroom, especially in terms of memory. At the same time, fast NVMe storage, PHP-FPM, OPcache, and page cache often deliver more benefit than simply upgrading to a plan with extra gigabytes.

Redis is especially useful where HTML cannot be fully cached: in WooCommerce, user accounts, catalogs, and news projects. For public pages, page cache, a CDN, and proper cache purging still play the primary role.

Reliability depends on more than just resources. External backups, staging, updates, a WAF, XML-RPC restrictions, and system cron help prevent situations where a site goes down not because the VPS is underpowered, but because it is misconfigured.

The best plan is not the largest or the cheapest, but the one that can handle normal load, updates, and short-term spikes without constantly running at its limit.

FAQ

How much RAM does WordPress need?

For a small blog or corporate website, 2 GB of RAM is a reasonable minimum. This configuration is usually sufficient if you use a lightweight theme, a moderate number of plugins, and have page caching configured.

For Elementor, WPBakery, multilingual sites, and complex integrations, 4 GB is a better choice. A small WooCommerce store typically needs 6–8 GB, especially if MySQL, Redis, backups, and security tools are running on the same VPS.

The exact amount depends on more than just traffic. The number of PHP-FPM processes, the proportion of dynamic pages, the database size, and plugin memory usage are also important.

Which is better for WordPress: Nginx or Apache?

Both web servers are suitable for WordPress.

Apache is more convenient for projects that use .htaccess and follow standard plugin instructions. Nginx handles large numbers of connections and centralized configuration well, but .htaccess rules must be migrated manually.

For a new project, Nginx with PHP-FPM is often chosen. When migrating an existing site, it is safer to take the current configuration into account rather than changing the web server solely for a nominal performance improvement.

Does a small website need Redis?

Not always. For a small blog with a good page cache, OPcache, a CDN, and image optimization usually have a greater impact.

Redis is more useful for websites with many dynamic requests, such as WooCommerce stores, user account areas, catalogs, multilingual projects, and news sites. It stores objects between requests and reduces the number of repeated database queries.

However, Redis consumes RAM, so on a resource-constrained VPS it should not be enabled without monitoring memory usage and measuring the actual impact.

Which PHP version should you choose for WordPress in 2026?

For a new production site, you should aim for PHP 8.3 or a newer supported branch after verifying compatibility.

Current WordPress versions support PHP 8.4 and 8.5, but the theme, plugins, and third-party integrations may lag behind the core. Therefore, it is best to test the upgrade on a staging copy first.

Using an outdated PHP branch solely for the sake of an old plugin is not recommended. It is safer to update or replace the incompatible extension.

When is it time to move WordPress to a more powerful VPS?

An upgrade is needed when resource constraints become recurring, rather than appearing only once during an update.

Key signs:

• The CPU remains under high load for extended periods;
• RAM is almost fully utilized;
• Swap is used continuously;
• 502, 503, or OOM errors appear;
• PHP-FPM starts queuing requests;
• The database responds slowly;
• The admin dashboard is sluggish;
• Backups and imports interfere with site operation.

Before changing plans, you should check page cache, Redis, slow SQL queries, heavy plugins, and PHP-FPM settings. If the site is already optimized and the load continues to grow, it is better to increase resources in advance.

Sources

1. WordPress.org — Requirements

2. Make WordPress Hosting — Server Environment

3. WordPress Advanced Administration Handbook — Web Servers

4. WordPress Advanced Administration Handbook — Cache

5. WordPress Plugin Handbook — Cron