WordPress Hosting and Server Sizing

Shared hosting or your own server?

On a shared plan, PHP, the database, email and SSL arrive ready and the system side is not yours to maintain — for a single blog or company site that is usually the right answer. You move to your own server in three situations: an installation that needs an object cache such as Redis or PHP settings a plan does not expose, a WooCommerce shop whose cart and checkout pages never pass through a cache, or a number of installations you want gathered on one machine. The price of that route is explicit: updates, the firewall and the backup scheme become your responsibility.

Recommended resources

These values match the VDS plan tiers in our catalogue; the exact price is calculated in the configurator.

Prices exclude VAT (20%).

Resources: PHP workers, the database and caching

In WordPress it is not the number of visitors that sets your resource needs but the share of pages your cache covers. With full-page caching on, a request for a blog post never runs PHP at all — it becomes a read of a ready file — which is why a busy news site can be comfortable on a 2 GB machine. Shops are different: in WooCommerce the cart, checkout and account pages are specific to each user and never pass through a full-page cache, so every request runs PHP and the database together. The memory plan follows from that: each PHP-FPM worker holds around 50-100 MB for WordPress, the database wants its own buffer pool, and the operating system needs 0.5-1 GB left over. On a 4 GB machine, fifteen to twenty workers with a database beside them is a realistic ceiling. Configuring more workers than RAM allows is the classic mistake: instead of slowing down, the server loses processes the moment memory runs out. An object cache such as Redis then cuts repeated database queries on the requests the page cache does not cover, and its real benefit shows up in shops.

Storage, backups and wp-cron

The WordPress core is under 100 MB; what fills a disk is the media library. For every image you upload WordPress generates several sizes and your theme adds its own, so a 4 MB photo multiplies on disk. That is usually why a 10 GB plan is full a year later; when sizing storage, aim for roughly twice today's media archive. On backups, the most common mistake is leaving the backup taken by a plugin on the same disk — when the server is unreachable, so is the backup. The daily backup you schedule from the panel is the second copy, and on a VDS order its retention is set to 5 or 30 days. Keeping a third copy entirely outside the server is a good habit. One last detail is scheduled jobs: WordPress fires its own tasks through wp-cron.php during page visits. On a low-traffic site that means a scheduled post does not appear on time; on a busy one the same mechanism runs far more often than needed. On your own server the correct fix is to turn the WP_CRON setting off and hand the job to the system scheduler.

Setup steps

1. 1Pick the plan: Plesk-based web hosting for a single site, or a VDS from the configurator if you need your own settings.
2. 2On a VDS, choose the Ubuntu 22.04 or 24.04 LTS template and install Nginx, PHP 8.x and a MySQL-compatible database.
3. 3Create a separate database for each installation, with a user granted rights to that database only.
4. 4Upload the WordPress files and finish the setup wizard; the database details are written into wp-config.php.
5. 5Point the domain at the server's IP address and enable an SSL certificate; free SSL is included with the web hosting plans.
6. 6Turn full-page caching on, and on shops keep the cart, checkout and account pages out of the cache.
7. 7Schedule daily backups; on a VDS the configurator offers 5 or 30 day retention. Keep one copy outside the server.

Common mistakes

• Keeping the backup on the same disk. As long as a plugin's backup stays inside the server, it is unreachable exactly when the server is.
• Treating slowness by adding resources first. On machines scaled without measuring, the real problem is usually a disabled cache or one heavy plugin.
• Not updating the old addresses in the database when you change domains. Addresses also appear inside serialised data, so use a migration tool rather than a manual search and replace.
• Delaying plugin and theme updates. Most breaches of WordPress installations come not from the core but from plugins and themes left unpatched.
• Setting the PHP-FPM worker count without reference to memory. If you do not budget 50-100 MB per worker, the server loses processes under load.

What is included at Datafex

Frequently Asked Questions

Is shared hosting enough for WordPress?

For a single blog or company site it usually is: PHP, the database and SSL arrive ready and system maintenance is not yours. Once you have a shop with pages that cannot be cached, or need an object cache or PHP settings a plan does not expose, a VDS becomes necessary.

How many WordPress sites can I host?

Because each installation uses one database, the plan's database count draws the line: Starter carries 2, Pro 5 and Business 15. On your own VDS there is no database limit — memory and storage set it instead.

Does WordPress come pre-installed on the server?

No. Provisioning completes automatically at the operating system and panel level; you install WordPress yourself. On a web hosting plan you create the database in the panel and upload the files, while on a VDS you also install the web server and PHP.

Can I choose the PHP version?

On a VDS it is entirely up to you: you install whichever version you want from the distribution's repository or a separate one. On web hosting plans PHP settings are managed per domain from the Plesk panel, where you can see which versions are installed.

My site got slow — will adding resources fix it?

Do not scale without measuring. Three things to check in order: is full-page caching on, which plugin is stretching page generation time, and are database queries benefiting from an object cache. Without those three, adding resources simply repeats the same slowness on a more expensive machine.

How long are my backups kept?

On a VDS order, the configurator sets daily backup retention to either 5 or 30 days. That is the copy held on the provider side; for migrations and long-term archiving you should keep a copy in your own environment as well.