VPS for an online store: what kind of server you need for WooCommerce, OpenCart, or PrestaShop

A VPS for an online store should be chosen with headroom. Unlike a regular website, an online store constantly works with dynamic pages and functions: the cart, checkout, customer accounts, filters, search, payments, delivery, and emails.

For a small store on WooCommerce, OpenCart, or PrestaShop, it is better to focus not on the CMS’s minimum system requirements, but on the actual load: the number of products, visitors, orders, modules, integrations, and advertising-related traffic spikes.

Guideline:

It is better to choose NVMe storage rather than simply more gigabytes. An online store makes heavy use of the database, cache, images, logs, temporary files, imports, and backups. A slow disk can make the catalog, admin panel, and checkout sluggish.

For a small store, a sound architecture looks like this: a VPS for the website and database, external backups, a CDN for images and static assets, an SMTP service for email, monitoring, a staging copy, and admin panel protection.

At the start, the database can run on the same VPS if the store is small and the load is moderate. However, you need to monitor MySQL or MariaDB, slow queries, table sizes, available RAM, and disk space.

Caching is needed not only for speed, but also for stability under load. Public catalog pages can be cached, but the cart, checkout, customer accounts, and personal data must not be served from a shared cache to all users.

SSL is mandatory for an online store: without HTTPS, you cannot properly handle payments, authentication, and personal data. It is better to send email through a separate SMTP service rather than directly from the VPS, so that order, payment, and registration emails are not lost.

The main mistakes are launching a store without regular backups, failing to test checkout after migration, not monitoring the database and files, cutting costs on storage, and ignoring seasonal peaks such as sales, advertising campaigns, holidays, and email newsletters.

A good VPS for an online store is not the cheapest plan, but a configuration that can handle normal traffic, updates, product imports, backups, and order spikes without the cart and payment flow going down.

Why an Online Store Needs a More Powerful VPS

An online store places a heavier load on the server than a typical blog or corporate website. Even if traffic seems modest, the shopping cart, catalog, search, filters, customer account, orders, payments, shipping, emails, and background tasks are constantly running behind the scenes.

That is why choosing a VPS based only on the number of visitors is the wrong approach. It is more important to consider how many products are in the catalog, how many modules are connected, how often inventory levels are updated, and whether there are imports, integrations, promotions, and advertising-driven traffic spikes.

Dynamic Pages and the Shopping Cart

A standard informational page can be cached and served as ready-made HTML. An online store is more complex: the cart, checkout, user account, and some AJAX requests must remain dynamic.

Each time, the server has to account for the items in the cart, discounts, coupons, stock levels, shipping options, taxes, authentication, and the user’s personal data. These pages cannot simply be served from a shared cache for all visitors.

As a result, an online store makes heavier use of PHP, the database, and RAM. Even with page caching configured, some of the load still remains on the backend.

This is especially noticeable during promotions, when many users simultaneously add products to their carts, proceed to payment, and refresh catalog pages.

Product, Order, and Customer Database

The database is the central component of an online store. It stores products, categories, attributes, prices, inventory levels, customers, orders, statuses, coupons, shipping settings, and module data.

The larger the catalog and order history, the more important MySQL or MariaDB performance becomes. A slow database can slow down not only the public catalog, but also the admin panel, search, filters, reports, imports, and checkout.

Additional load is created by variable products, complex filters, multilingual functionality, exports, synchronization with a CRM or accounting system, and analytics and marketing modules.

If the database runs on a slow disk or does not have enough RAM, the store may appear unstable: product pages take a long time to open, the admin panel freezes, and checkout takes longer than it should.

However, the database itself is not the only source of load. A store is almost always connected to external services.

Payments, Shipping, and External Integrations

An online store rarely operates entirely on its own. It is usually connected to payment systems, shipping services, a CRM system, inventory management, email services, analytics, marketplaces, and advertising platforms.

Each integration introduces potential latency. If a payment module, shipping service, or CRM system responds slowly, the user may have to wait during checkout even if the VPS itself is not overloaded.

Some tasks are better handled asynchronously, such as sending data to a CRM system, updating statuses, data exports, and reports. However, critical stages—payment, order confirmation, and shipping cost calculation—must still be fast and stable.

That is why a VPS for an online store must have enough headroom not only for regular pages, but also for background processes, webhooks, queues, email notifications, and handling errors from external services.

This headroom is especially important during seasonal spikes.

Seasonal Peaks and Advertising Campaigns

An online store may run smoothly for most of the month and then experience a sharp increase in load due to a sale, an email campaign, advertising, holidays, or a blogger’s post.

At these times, it is not only the number of page views that increases. Users simultaneously browse the catalog, use filters, add products to the cart, apply promo codes, place orders, and receive emails.

If the VPS was chosen without sufficient capacity headroom, a traffic spike can lead to queues in PHP-FPM, high database load, 502 or 503 errors, payment delays, and lost orders.

For an online store, it is important to plan for peak load rather than average load. The server must be able to handle not only a normal day, but also an advertising campaign, a seasonal promotion, product imports, and backups.

Next, you can compare popular e-commerce platforms: WooCommerce, OpenCart, and PrestaShop. Each has its own requirements for the VPS, caching, the database, and resource headroom.

CMS Comparison for an Online Store

WooCommerce

WooCommerce is an online store built on WordPress. It is a convenient option when a store grows out of a content website, blog, landing page, or corporate project. For a small catalog and a moderate number of orders, it is a flexible solution, especially when SEO pages, articles, and simple content management are important.

However, WooCommerce depends heavily on plugins, the theme, and the condition of the database. The cart, checkout, customer account, variable products, filters, coupons, and integrations create dynamic load that cannot be fully handled by page caching.

If you add Elementor, a heavy theme, several marketing modules, filters, CRM, payment, and shipping to WooCommerce, VPS requirements increase quickly. In this case, it is better to plan for extra RAM, CPU, and disk performance from the start.

For a small WooCommerce store, you should typically consider a VPS with 2–4 vCPU and 4–8 GB RAM. If there are many products, active advertising campaigns, complex filters, or a visual builder, it is better to choose a configuration closer to the upper end of that range.

OpenCart

OpenCart is designed specifically for online stores. It is simpler and lighter than many general-purpose CMS platforms, so it can run well on a moderately configured VPS if the catalog is not overloaded with modules.

For a small store, OpenCart often requires fewer resources than WooCommerce with a heavy theme and a large set of plugins. However, this advantage can easily be lost if you install many modifications, filters, integrations, SEO modules, and extensions for exchanging data with external systems.

In OpenCart, the main load is usually associated with the catalog, filters, search, product imports, orders, and the admin panel. A large catalog with attributes and frequent stock updates can place a significant load on the database.

For a small OpenCart store, 2 vCPUs and 2–4 GB of RAM are often enough to get started. However, for stable operation with headroom for imports, backups, and advertising-driven traffic spikes, it is better to plan for 4 GB of RAM and a fast NVMe disk.

PrestaShop

PrestaShop is a specialized CMS for online stores with a wide range of built-in features. It is suitable for stores that need a catalog, product attributes, discounts, multilingual support, multiple currencies, and advanced product management.

Compared with a basic OpenCart setup, PrestaShop can be more resource-intensive, especially with a large catalog, complex modules, multilingual support, marketing features, and heavy admin panel usage.

Performance bottlenecks often occur on category pages, in filters, search, recommendation modules, imports, inventory updates, and order processing. If the database grows, the site may start to slow down even on a decent VPS without caching and SQL optimization.

For a small PrestaShop store, it is best to plan for 2–4 vCPU and 4–8 GB RAM. If the catalog is large and there are many languages, currencies, modules, and integrations, you will need additional CPU, RAM, and disk capacity.

VPS Requirements Table for Different Platforms

Exact requirements depend on catalog size, theme, modules, traffic, and the number of orders. For an initial VPS selection, however, you can use the baseline ranges as a guide.

These are starting guidelines for small and medium-sized projects. If the store receives many orders and actively uses filters, synchronization, imports, and advertising, it will need more resource headroom.

CPU and RAM

The CPU handles PHP code execution, CMS requests, modules, the shopping cart, checkout, the admin panel, and background tasks. The more dynamic operations a store performs, the more important it is to have spare CPU capacity.

For OpenCart, 2 vCPUs are often enough to start with. WooCommerce and PrestaShop are better deployed with 2–4 vCPUs, especially when using resource-intensive themes, filters, marketing modules, and visual editors.

RAM is not required only by the CMS. Memory is also used by PHP-FPM, MySQL or MariaDB, cache, the web server, background tasks, the control panel, backups, and system processes.

If there is not enough RAM, the VPS starts using swap. For an online store, this is especially risky: the shopping cart, checkout, and admin panel may start slowing down at the worst possible time.

Disk and Database

For an online store, disk capacity is not the only factor that matters; disk speed is important as well. The catalog, images, database, cache, logs, temporary files, imports, and backups all make intensive use of read and write operations.

For this reason, NVMe is the better choice for an online store. A slow disk can become a bottleneck even when CPU performance is adequate and there is enough RAM.

For a small store, the database can be hosted on the same VPS as the website. This is simpler and cheaper at the start. However, you need to monitor table sizes, slow queries, available memory, disk load, and MySQL or MariaDB response times.

If the catalog grows, order volume increases, and the database starts to interfere with site performance, it can be moved to a separate server or a managed database.

Cache, SSL, Email, and Backups

Caching reduces server load, but in an online store it must be configured carefully. Public catalog pages and product pages can be cached, but the cart, checkout, customer account area, and personal data must not be served as shared HTML.

OPcache should almost always be enabled. Redis or Memcached is useful when the site frequently accesses the database, such as in WooCommerce and PrestaShop catalogs with filters and in customer account areas.

SSL is mandatory for an online store. Without HTTPS, you cannot properly handle authentication, payments, or personal data, or maintain user trust.

It is better to send email through an external SMTP service. Order, payment, registration, and password recovery emails must be delivered reliably, and a VPS is not always suitable for dependable delivery of transactional emails.

Backups must be stored separately from the VPS. For an online store, it is important to back up not only the files but also the database, because it contains orders, customers, statuses, settings, and operation history.

Peak loads

An online store should be sized not for an average day, but for peak scenarios. A sale, email campaign, advertising push, seasonal demand, or a mention by a blogger can sharply increase the load.

During peak periods, it is not only the number of page views that increases. Users open the catalog, apply filters, add products to the cart, use promo codes, place orders, and receive emails.

If the VPS is sized with no headroom, these are exactly the moments when 502 and 503 errors, PHP-FPM queue buildup, slow checkout, and payment delays occur.

Peak loads require sufficient RAM headroom, an adequate number of vCPUs, fast NVMe storage, caching, a CDN, monitoring, and backups that have been tested in advance. The store must handle not only regular visits, but also the moments when orders are actually coming in.

What VPS Configuration Does a Small Store Need?

Minimum Starter Configuration

A minimum starter VPS for a small online store is a configuration that lets you launch, test, and run the project without constant failures.

For OpenCart, this can be 2 vCPUs, 2–4 GB of RAM, and NVMe storage starting at 40 GB. For WooCommerce and PrestaShop, it is better to consider 2–4 vCPUs and 4 GB of RAM from the start.

This starter VPS is suitable if the catalog is small, traffic is moderate, and there are no heavy filters, complex integrations, continuous imports, or aggressive advertising campaigns.

However, a minimum configuration requires careful setup: an up-to-date PHP version, OPcache, a properly configured database, proper caching, external backups, and monitoring. Without this, even a small store can start slowing down sooner than expected.

Optimal configuration for stable operation

For stable operation, it is best to choose a VPS with headroom for RAM, CPU, and disk capacity. The store needs to handle not only regular catalog browsing, but also checkout, admin panel operations, backups, product imports, and background tasks.

For a small store, the following configuration is a good baseline:

RAM headroom is especially important. A single VPS typically runs the web server, PHP-FPM, MySQL or MariaDB, cache, cron jobs, backups, and system processes. If there is not enough memory, the server starts using swap, and the store slows down specifically in dynamic scenarios such as the cart, checkout, and admin panel.

You should also not cut costs on disk capacity. An online store quickly accumulates images, logs, temporary files, exports, database dumps, and backups. Even if backups are stored separately, the production VPS needs free space to operate normally.

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

Frankfurt infrastructure, predictable pricing, and expert migration support.

Get

When You Need a More Powerful VPS

You should move to a more powerful VPS based on metrics, not intuition. If the store has started to slow down, the first step is to identify the bottleneck: CPU, RAM, disk, database, PHP-FPM, cache, or external integrations.

Signs that the initial configuration is no longer sufficient:

• CPU is regularly under high load;
• RAM is almost fully utilized;
• swap is being used heavily;
• the PHP-FPM queue is growing;
• MySQL is responding slowly;
• 502 or 503 errors appear;
• backups and imports interfere with customers;
• the admin panel slows down during normal operations;
• the site’s performance drops during promotions and advertising campaigns.

If the issue is caused by slow SQL queries, a resource-intensive module, or misconfigured caching, upgrading the VPS may only help temporarily. It is better to optimize the database, plugins, PHP-FPM, and cache first.

However, if the store is already properly configured and the load is steadily increasing, it is better to scale resources in advance. For an online store, a server outage during a sale costs more than having a small amount of extra capacity on the plan.

Architecture of a Small Online Store

VPS for a Website and Database

For a small online store, the website and database are often hosted on the same VPS. This is a reasonable starting setup if the catalog is small, order volume is low, and the server has spare CPU, RAM, and disk capacity.

A VPS like this typically runs the web server, PHP-FPM, MySQL or MariaDB, cache, cron jobs, and the CMS itself. For that reason, you should not choose a configuration with no margin: resources are needed not only for visitors, but also for the admin panel, product imports, updates, backups, and background processes.

The key point is not to treat a single VPS as “one box with no oversight.” Even if the database is located alongside the website, it must be monitored separately: table sizes, slow queries, RAM usage, disk load, and response time.

As the store grows, the database can be moved to a separate server or a managed database, and the application can be scaled horizontally by deploying it across multiple VPS instances behind a load balancer. But at the start, it is more important to configure the current VPS correctly and remember the data that needs to be stored separately from it.

Separate backups

Online store backups, like any other backups, must not be stored only on the same VPS. If the server is deleted, damaged, encrypted, or becomes unavailable, local backups will be lost along with the site.

For a store, you need to back up not only the files but also the database. The database is where orders, customers, statuses, carts, payment and shipping settings, and modules are stored.

Keeping a backup “nearby” can be useful for quick recovery, but the minimum reasonable setup is to regularly back up the files and database and store those backups in external storage. For an active store, the database should be backed up more frequently than the files, because orders and statuses change constantly.

It is important to check not only that the archives exist, but also that they can actually be restored. A backup that has never been deployed to a test copy remains nothing more than an untested hope.

After protecting the data, you can reduce the load on the VPS by moving static files closer to users.

CDN for Images and Static Assets

An online store typically contains many images and static files: product cards, galleries, banners, icons, stylesheets, scripts, and fonts. If all of this is served only from a VPS, the server takes on unnecessary load, and users in remote regions have to wait longer.

A CDN helps serve static assets through a distributed network. Visitors receive images, CSS, and JavaScript from the nearest node, while the VPS spends less time repeatedly sending the same files.

For a store, a CDN is especially useful in the catalog, on product pages, on the home page, and during advertising campaigns. It does not replace image optimization, but it complements it well.

At the same time, dynamic pages must be excluded from the general HTML cache. The cart, checkout, user account, and personal data must not be cached as the same page for all users.

Once static assets have been moved to a CDN, email should be handled separately: the store must send notifications reliably regardless of the VPS’s reputation.

SMTP Service for Email

An online store sends emails about registration, orders, payments, status changes, password resets, and inquiries submitted through forms. If these emails are not delivered, the customer may not know whether the order has been accepted, and a manager may miss a request.

You can send email directly from a VPS, but this is not the best option for a store. The server may lack proper sender reputation, SPF, DKIM, DMARC, and reliable deliverability, which will require additional work or setting up a separate mail server.

A more reliable approach is to use an external SMTP service or a transactional email platform. This makes order and payment emails less dependent on the VPS configuration itself and less likely to land in spam.

After setting up SMTP, you need to test not only email sending itself, but also real scenarios: a new order, cancellation, status change, password reset, an email to the administrator, and an email to the customer.

The next layer is monitoring. Even a good architecture is useless if you only learn that the store is down from a customer.

Website and Server Monitoring

Monitoring is needed to detect problems before they lead to lost orders. For an online store, it is important to track not only the availability of the homepage, but also the health of the server, database, and key user flows.

At a minimum, you should monitor website availability, HTTPS, CPU, RAM, swap, free disk space, MySQL load, 502 and 503 errors, log size, and backup success.

For an online store, it is also useful to test the checkout process: whether the cart opens, whether checkout works, whether emails are sent, and whether payment and shipping modules are available.

Monitoring should send alerts, not just collect attractive graphs. If the VPS starts using swap, the disk is almost full, or checkout returns an error, you need to know immediately.

It is highly advisable to keep monitoring separate from the system being monitored (the VPS), or at least use a dead man’s switch mechanism so that you receive an alert even if the VPS fails completely. Separate monitoring will also help during incident investigation, because the metrics will be stored separately from the VPS.

However, monitoring shows problems in production. To avoid introducing them yourself through updates and experiments, you need a staging copy.

Staging Copy

Staging is a test copy of the store used to verify updates, modules, theme changes, migrations, PHP versions, and integrations before they are applied to the production site.

For an online store, staging is especially important because an error can break the cart, payment, shipping, or admin area. The site may appear to load normally, while checkout no longer works.

The following should be tested on staging:

• Catalog and product pages;
• Cart;
• Checkout;
• Payment in test mode;
• Shipping;
• Emails;
• Customer account;
• SEO URLs and redirects;
• Import and inventory updates.

The test copy must not be left open to indexing. It should be blocked from search engines and unauthorized users, and real payment and email workflows should be used only with caution.

Beyond staging, one more critical element remains: securing the admin area, because access to the control panel effectively provides access to orders, customers, and store settings.

Securing the Admin Panel

An online store’s admin panel needs stronger protection than a standard login page. It can be used to change prices, orders, company details, payment settings, access permissions, and customer data.

At a minimum, it requires strong passwords, separate employee accounts, two-factor authentication, and role restrictions. Full administrative access should not be granted to users who only need order manager or content editor permissions.

Where possible, access to the admin panel should be restricted by IP address, VPN, or additional HTTP authentication. This reduces the risk of password brute-force attempts and automated attacks.

You also need to regularly update the CMS, modules, and themes, remove unused extensions, monitor login logs, and disable old employee accounts. New vulnerabilities are discovered regularly, and an online store can be an attractive target for a hacker: it has payment information, payments themselves, and customers’ personal data.

As a result, the architecture of a small store is not built around the VPS alone. The server remains the core component, but it should be supported by external backups, a CDN, SMTP, monitoring, staging, and admin panel protection. Without these elements, even a powerful VPS does not make the store reliable.

Key settings to configure on a VPS

PHP-FPM and memory limits

PHP-FPM is responsible for executing the store’s PHP code. Dynamic pages run through it: the catalog, product pages, cart, checkout, customer account, admin panel, and modules.

If PHP-FPM is configured too conservatively, requests start waiting for an available process. If there are too many processes, the VPS can quickly exhaust its RAM and start swapping.

For an online store, it is important to tune the settings to the actual amount of available memory rather than copy a generic configuration. You need to account for how much RAM is used by MySQL or MariaDB, cache, the web server, backups, cron jobs, and the operating system itself.

It is also worth checking memory_limit, max_execution_time, file upload limits, and response timeout settings. Values that are too low can break imports, catalog updates, and module functionality, while values that are too high can allow a single process to consume too many resources.

After PHP-FPM, the next step is the database, because it stores products, orders, and customers.

MySQL or MariaDB

For WooCommerce, OpenCart, and PrestaShop, the database is one of the key parts of the infrastructure. It stores products, categories, prices, stock levels, orders, customers, statuses, coupons, and module settings.

MySQL and MariaDB can run on the same VPS as the website if the store is small. However, the database still needs to be configured and monitored separately: slow queries, table sizes, memory usage, disk load, and response times should all be tracked.

A slow database has an immediate impact on the store. It can slow down the catalog, search, filters, checkout, reports, imports, and the admin panel.

Common causes of issues include oversized tables, resource-intensive filters, missing indexes, outdated module data, large log volumes, and inefficient SQL queries from plugins or extensions.

If the database has already become a bottleneck, increasing CPU alone may not be enough. In some cases, you need to optimize queries, add indexes, clean up tables, increase RAM, or move the database to a separate server.

After the database, you should configure caching to reduce repeated requests to PHP and SQL.

Redis or another caching system

An online store needs caching, but it should be used carefully. Public catalog pages, categories, product pages, and landing pages can be cached, but the cart, checkout, user account, and personal data must not be served as shared HTML to all users.

OPcache should almost always be enabled: it speeds up PHP code execution. A page cache helps with public pages. Redis or Memcached are useful when the store frequently queries the database and cannot rely entirely on HTML caching.

Redis is especially useful for WooCommerce, PrestaShop, large catalogs, user accounts, filters, and sites with a large number of dynamic requests.

However, caching must not break business logic. After configuration, you need to test the cart, checkout, authentication, coupons, stock levels, prices, payment, and shipping. If the cache is configured too aggressively, a customer may see an outdated price, incorrect stock availability, or encounter a problem during checkout.

Once performance and dynamic behavior are configured, the next required layer is HTTPS.

SSL Certificate

An SSL certificate is essential for an online store. Without HTTPS, you cannot properly handle authentication, payments, personal data, cookies, forms, or maintain customer trust.

HTTPS should be enabled on all store pages, not just at checkout. Mixed content, where some resources are loaded over HTTP, must be fixed: browsers may block these files or display warnings.

After enabling SSL, you should check the HTTP-to-HTTPS redirect, whether the certificate is configured correctly, the trust chain, the expiration date, and the operation of all subdomains, if any are used.

It is also important to update the site URLs in the CMS settings and check canonical URLs, the sitemap, robots.txt, links in emails, and payment system integrations.

However, even a secure store can lose orders if emails do not reach customers and managers.

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

Email and Transactional Notifications

An online store constantly sends transactional emails: order confirmations, status updates, registrations, password resets, payment notifications, and messages to administrators.

Sending email directly from a VPS is often unreliable. Messages may end up in spam, be rejected by mail servers, or fail to arrive because of poor IP reputation.

For an online store, it is better to use an external SMTP service or a transactional email platform. This improves deliverability and makes email tracking and management easier.

After configuration, you need to test not only the technical sending process, but also real-world scenarios: a new order, payment, cancellation, status change, registration, password reset, and an email to the manager.

You should also configure SPF, DKIM, and DMARC for the domain. Without these records, even properly formed emails can pass checks by email services less reliably.

Once PHP, the database, cache, SSL, and email are configured, the next critical area is backup and recovery. For an online store, this is not a matter of convenience, but of protecting orders and customer data.

Store Backups and Recovery

What to Back Up

For an online store, you need to back up more than just the site files. The most valuable data is often in the database: orders, customers, payment statuses, shipping settings, coupons, inventory levels, products, and transaction history.

A backup should include:

• CMS files;
• Product images;
• Themes and templates;
• Modules and plugins;
• The database;
• Web server configuration;
• PHP settings;
• cron jobs;
• SSL configuration;
• Integration settings, if they are stored in files.

For WooCommerce, OpenCart, and PrestaShop, it is especially important to back up the database before updates, migrations, product imports, and changes to payment or shipping modules.

Files can be restored from an archive, but lost orders and customer data are much harder to recover. That is why a store’s database should be backed up more frequently and more carefully than a regular set of files.

Once you understand what the backup should contain, you need to define the backup frequency. For a store, this should be based not on the administrator’s convenience, but on how much data the business is prepared to lose in the event of a failure.

How often to back up

Backup frequency depends on the store’s activity level. If orders are placed infrequently, a daily backup of the database and files may be sufficient. If the store receives orders every day, the database should be backed up more often.

You can use the following schedule as a guideline:

Before updating the CMS, modules, theme, PHP, database, or server, you should create a separate fresh backup. The same applies to migration, bulk product imports, and changes to payment modules.

It is important to consider not only backup frequency but also the retention period. If an issue is not noticed right away, the latest backup may already contain the problem. For this reason, it is useful to keep multiple restore points, for example from the last few days and weeks.

However, frequent backups will not help if they are stored on the same VPS and disappear along with it.

Where to Store Backups

Backups should be stored separately from the primary VPS. A local archive on the server is convenient for fast recovery, but it does not protect against deletion, compromise, disk failure, or loss of access to the server.

It is better to use external storage: object storage with deletion protection, a separate backup server, cloud storage, or a backup service. Access to it should be restricted, and archives containing sensitive data should be protected.

For an online store, it is important that backups are not accessible from the website’s public directory. Database dumps, code archives, and configuration files must not be left in a folder where they can be downloaded through a browser.

Access rights should also be separated. If an attacker gains access to the VPS, they should not automatically be able to delete all external backups.

A good approach is to store copies off the server, restrict access with keys, use encryption, and periodically verify that the archives are actually being created.

But even a perfectly preserved archive is useless if no one has tested whether it can be restored.

How to Test Recovery

Recovery testing is an essential part of the backup process. The mere fact that an archive exists does not mean the store can be brought back online.

A backup should be periodically restored to a test copy or staging environment. This lets you verify that the files are not corrupted, the database imports successfully, the site opens, the admin panel works, and products and orders are in place.

After recovery, you should go through the key scenarios: open the catalog, a product page, the cart, checkout, the customer account, the admin panel, emails, and integrations.

It is especially important to test recovery after a migration, a PHP version change, a CMS update, or the installation of major modules. At these times, the risk of errors is higher than during normal operation.

For a store, it is useful to understand in advance not only whether a backup exists, but also how long recovery will take. If the business cannot afford several hours of downtime, a more robust backup and recovery strategy is needed.

Backups protect against failures, but many problems occur during site migration. That is why the next important topic is migrating an online store to a VPS and testing the order flow after the move.

Migrating an Online Store to a VPS

Checking the Catalog and Product Pages

After migrating an online store to a VPS, check the catalog first. The home page may load correctly, while categories, filters, product pages, or search may still produce errors.

It is important to test several different scenarios: categories, product pages for standard and variable products, search, filters, sorting, pagination, and promotional pages.

On product pages, check images, prices, availability, specifications, variants, add-to-cart buttons, reviews, related products, and recommendation sections.

If the store imports inventory levels or synchronizes with a CRM, warehouse, or accounting system, make sure after the migration that the data is updated correctly. Otherwise, the site may display outdated prices, incorrect stock levels, or obsolete product statuses.

Once the catalog and product pages open correctly, the next step is to check what matters most to the business: the cart and checkout.

Testing the Cart and Checkout

A catalog that opens successfully does not necessarily mean the store is ready to accept orders. After migration, you must go through the full customer journey, from adding a product to the final order confirmation.

Test different scenarios: a single product, multiple products, a variable product, a promo code, quantity changes, item removal, moving from the cart to checkout, and going back.

During checkout, make sure that fields, validation, total calculation, discounts, taxes, shipping, payment methods, and order confirmation all work correctly.

Pay special attention to caching. The cart and checkout must not be cached like regular pages. If Nginx, CDN, or cache plugin settings changed after the migration, you can accidentally break the store’s dynamic functionality.

After placing a test order, check whether it appears in the admin panel and whether the customer details, status, amount, payment method, and shipping information were recorded correctly.

If checkout works, move on to external services, because they are often what break after a migration.

Testing Payments, Shipping, and Emails

Payment modules, shipping services, and email notifications depend on the domain, SSL, callback URLs, API keys, the server IP address, and CMS settings. After a migration, some of these parameters may change.

Payments should be tested in test mode if the payment system supports it. Make sure the user can successfully proceed to payment, the store receives the callback or webhook, and the order status is updated correctly.

Shipping should be tested using several addresses or regions if the calculation depends on geography, weight, order total, or an external shipping service API.

Emails must also be tested. After migration, make sure notifications are delivered to both the customer and the administrator: new order, status change, password recovery, registration, and messages submitted through forms.

If an external SMTP service is used, check the connection, authentication, SPF, DKIM, DMARC, and sender addresses. If emails are not delivered, the store may technically still accept orders, but managers and customers will miss important notifications.

Once orders, payments, shipping, and emails have been tested, the remaining area is SEO. Errors in URLs and redirects may not directly prevent purchases, but they can quickly hurt search traffic.

Checking SEO URLs and redirects

After migration, it is important to preserve the URLs for products, categories, pages, and filters. If the link structure has changed without redirects, the store may lose rankings, traffic, and external referrals.

You need to verify that old URLs either open correctly or redirect to the new ones as expected. This is especially important for product pages, categories, brand pages, promotions, and informational content.

It is also worth checking canonical URLs, the sitemap, robots.txt, breadcrumbs, pagination, and menu links. After moving a domain or switching from HTTP to HTTPS, old URLs often remain in these places.

Redirects should be clear and avoid long chains. If a user or search engine crawler has to go through multiple redirects, it slows things down and makes indexing more difficult.

After checking SEO URLs, it is useful to crawl the site or at least manually review the key sections. A migration is successful not when the site “loads,” but when the catalog, checkout, payment, emails, redirects, and admin panel work as well as or better than they did before the move.

Common Mistakes When Choosing a VPS for an Online Store

Mistakes made when choosing a VPS for an online store usually do not become apparent immediately. At first, the site may load, products can be added, and the admin panel may work. Problems start later: during migration, an update, the first advertising-driven traffic spike, catalog growth, or a server failure.

For an online store, these mistakes are more dangerous than they are for a standard website. In this case, a failure means more than just a slow page: it can result in lost orders, undelivered emails, incorrect stock levels, and the risk of losing customer data.

Hosting a store without regular backups

The main mistake is launching an online store without a clear backup plan. As long as everything is working, it may seem that backups can be set up later. But failures usually do not happen on a schedule.

For a store, losing the database means losing orders, customers, payment statuses, shipping settings, coupons, and transaction history. Losing files means losing product images, templates, modules, documents, and configurations.

A local copy on the same VPS does not fully solve the problem. If the server is deleted, damaged, blocked, or compromised, that backup may disappear along with the store.

At a minimum, files and the database should be backed up regularly to external storage. For an active store, the database needs to be backed up more often than the files because orders and statuses change constantly.

Even with backups in place, a store can still lose money if no one checks the purchase flow after a migration or update.

Failing to test checkout after migration

After a migration, many teams check only the home page, the catalog, and the admin panel. For an online store, however, that is not enough. The primary user flow is not viewing a page, but placing an order.

After the migration, you need to go through the entire customer journey: open a product, add it to the cart, apply a promo code, select delivery, proceed to payment, complete the order, and check the emails.

After migration, the most common things to break are payment system callback URLs, delivery settings, SMTP, HTTPS, cart caching, file paths, and access permissions.

The site may appear to be working, but fail to accept payments or send notifications to the manager. The owner may only discover this after a customer complaint or a drop in the number of orders.

Therefore, a migration should be considered complete not when “the site opens,” but when the catalog, cart, checkout, payment, delivery, emails, and admin panel have all been tested.

The next mistake is leaving even a working store unmonitored.

Leaving the database and files unmonitored

An online store continuously accumulates data: orders, customers, images, logs, cache, temporary files, exports, database dumps, and module data.

If you do not monitor the database and files, problems develop unnoticed. Tables grow, disk space fills up, slow queries take longer, logs consume more and more space, and backups start taking longer to complete.

High-Performance Virtual Machines

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

Get

At some point, the store may start slowing down or go down because of an issue that would have been easy to spot in advance: disk space ran out, the database grew, swap started being used, MySQL started responding slowly, or backups stopped being created.

For a store, it is worth monitoring at least site availability, HTTPS, CPU, RAM, swap, free disk space, database size, 502 and 503 errors, backup status, and logs.

Monitoring does not make the site faster by itself, but it lets you detect a problem before it affects orders.

One of the most common causes of such problems is trying to save money on disk space.

Skimping on storage

For an online store, storage is not just space for CMS files. It also holds product images, the database, logs, cache, temporary files, imports, exports, archives, documents, and sometimes local copies of backups.

If you choose a disk that is too small or too slow, the store may run into two problems: insufficient space and poor read and write performance.

Insufficient space can disrupt file uploads, cache generation, log writing, product imports, and database operations. A slow disk slows down the catalog, search, admin panel, backups, and checkout.

It is better to choose NVMe storage and keep a reserve of free space. Even if backups are stored separately, the VPS must have enough room for temporary operations, logs, updates, and imports.

Cutting costs on storage is especially risky before seasonal peaks, when the catalog grows, advertising campaigns launch, inventory levels are updated, and the number of orders increases.

Not accounting for seasonal peaks

A store may run normally on a typical day and go down during a sale. That is why choosing a VPS based only on average traffic is a mistake.

A seasonal peak puts load on multiple parts of the site at once: the catalog, filters, cart, checkout, payment, shipping, email, database, and background tasks.

The most dangerous situations occur when an advertising campaign, a mailing, product import, and a backup run at the same time. On a normal day, the VPS can cope, but during a promotion it may run into a PHP-FPM queue, high CPU usage, insufficient RAM, or a slow database.

For an online store, you need to plan resource headroom in advance and test scenarios under load. If a sale is expected, it is better to verify in advance that caching works, the CDN is enabled, backups do not interfere with the peak, and monitoring alerts you to problems.

An online store must handle not only normal traffic, but also the moments when customers are actually ready to place orders. That is why choosing a VPS for a store is not only a matter of price, but also of business resilience.

Checklist for choosing a VPS for an online store

Before choosing a VPS, check:

• Which CMS the store runs on: WooCommerce, OpenCart, PrestaShop, or another platform;
• How many products and categories the catalog will contain;
• Whether it uses filters, search, product variants, and complex attributes;
• How many orders are expected on a typical day and during promotions;
• Which payment, shipping, CRM, accounting system, and analytics modules are connected;
• Whether product imports, stock updates, and bulk exports will be used;
• Whether a visual builder or a resource-intensive theme is required;
• How many images are stored for the products;
• Where backups will be stored;
• How email will be sent;
• Who will receive failure notifications.

For the VPS configuration, plan ahead for:

• CPU headroom for PHP, the admin panel, the cart, and background tasks;
• RAM sized for PHP-FPM, MySQL or MariaDB, caching, and system processes;
• An NVMe disk with enough headroom for images, the database, logs, cache, and temporary files;
• An up-to-date PHP version compatible with the CMS and modules;
• MySQL or MariaDB with slow query monitoring;
• OPcache and carefully configured caching;
• An SSL certificate for the entire store;
• An external SMTP service for transactional emails;
• A CDN for images and static assets;
• External backups;
• A staging copy for updates and migrations;
• admin panel protection;
• Monitoring for the website, server, database, disk, and backups.

After the store launches, you need to regularly check not only the availability of the homepage, but also the customer journey: catalog, product page, cart, checkout, payment, shipping, and emails.

If the store is preparing for a sale, advertising campaign, or seasonal peak, it is better to review the VPS configuration in advance. Resource headroom is cheaper than lost orders under load.

Conclusion

A VPS for an online store should be chosen differently than a server for a regular website. An online store constantly handles dynamic pages, a product database, orders, customers, payments, shipping, emails, and external integrations.

A modest configuration may be enough for a small OpenCart store, while WooCommerce and PrestaShop often require more CPU, RAM, and disk headroom. However, the CMS is not the only factor: load is also affected by the theme, modules, catalog size, filters, imports, advertising campaigns, and order volume.

Initially, the database can be hosted on the same VPS as the website if the store is small. However, it should be monitored separately: check slow queries, table sizes, memory usage, and disk load.

A reliable architecture for a small store includes more than just a VPS. It also requires external backups, a CDN, an SMTP service, monitoring, a staging copy, and admin area protection. Without these components, even a powerful server will not protect the store from data loss, undelivered emails, or errors after updates.

The main principle is simple: the VPS must be able to handle not only a normal day, but also updates, imports, backups, migration, and seasonal peaks. For an online store, resource headroom is not a luxury; it is part of sales resilience.

FAQ

How much RAM does an online store need on a VPS?

For a small OpenCart store, you can start with 2–4 GB of RAM if the catalog is small, there are only a few modules, and traffic is moderate.

For WooCommerce and PrestaShop, it is better to plan for 4–8 GB of RAM. These platforms typically use more PHP logic, modules, cache, and dynamic workflows: the shopping cart, checkout, customer account, filters, and integrations.

It is important to keep in mind that RAM is needed not only for the CMS. On a VPS, PHP-FPM, MySQL or MariaDB, the web server, cache, cron jobs, backups, and system processes all run at the same time. If there is not enough memory, the server starts using swap, and the store becomes noticeably slower.

Which is better for an online store: WooCommerce, OpenCart, or PrestaShop?

It depends on the use case.

WooCommerce is a good fit when the store is built around WordPress, content, SEO pages, a blog, and a flexible plugin ecosystem. However, with a heavy theme, many extensions, and a complex checkout process, VPS requirements can increase quickly.

OpenCart is often simpler and lighter for a traditional online store with a catalog, categories, products, and basic modules. It can run well on a modest configuration, but a large catalog, filters, and extensions also require extra headroom.

PrestaShop is suitable for a more advanced store with built-in e-commerce features, multilingual support, discounts, currencies, and a large catalog. It typically requires more attention to the server, cache, database, and modules.

Does an online store need Redis?

Not every store needs Redis, but it is often useful for dynamic projects.

If the store is small, the catalog is limited, and public pages are cached effectively, OPcache, page cache, and proper database configuration may be enough at first.

Redis becomes especially useful when there is a lot of dynamic functionality: a shopping cart, user account area, filters, search, a large catalog, an active admin panel, WooCommerce, PrestaShop, or a large number of authenticated users.

However, Redis stores data in memory. On a VPS with limited RAM, it should not be enabled without monitoring: it may start competing with PHP-FPM and MySQL for resources.

Can the database be hosted on the same VPS?

Yes. For a small store, the database can be hosted on the same VPS as the website. This is simpler, cheaper, and often sufficient at the start.

This setup is suitable if the catalog is small, order volume is low, and there are no continuous imports, heavy filters, or high traffic.

However, the database needs to be monitored separately. It is important to track slow queries, table sizes, RAM usage, free disk space, iowait, and MySQL or MariaDB response time.

When the database starts affecting the site’s operation, it can be moved to a separate server or a managed database. This makes sense as the catalog, orders, reports, synchronizations, and background jobs grow.

When is it time for a store to move to a separate database or a more powerful server?

A move is needed when the current VPS is consistently hitting its resource limits and basic optimization has already been done.

Key signs:

• The CPU is frequently under heavy load;
• RAM is running out and swap is being used;
• MySQL or MariaDB responds slowly;
• Slow queries keep recurring even after optimization;
• The disk cannot keep up with read and write operations;
• Imports, backups, and data exchanges affect shoppers;
• The admin panel is slow during routine work;
• Checkout slows down as order volume grows;
• The store goes down or returns 502/503 errors during promotions.

If the issue is a heavy module, a bad SQL query, incorrect caching, or an external API, a more powerful server will help only temporarily. First identify the bottleneck, and only then scale the infrastructure.

Sources

1. WooCommerce — Server Recommendations

2. WordPress.org — Requirements

3. OpenCart Documentation — System Requirements

4. PrestaShop Developer Documentation — System requirements for PrestaShop 9

5. PHP Manual — FPM configuration

6. MySQL Documentation — The Slow Query Log

7. Nginx Documentation — Logging