PrestaShop powers a large share of Europe's small and mid-sized online stores because it is free, multilingual and multi-currency, and it does not take a cut of sales. Its weakness is the same as any PHP store's: it lives or dies on its hosting, and shared hosting dies in December. This post follows a store owner moving a PrestaShop shop to MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, and getting through peak season without the annual panic.
The store is a Belgian outdoor-clothing retailer we will call Ardenne Outfitters: PrestaShop 8, four languages, two currencies, 3,000 products, and a December that brings six times the traffic of a normal month. The PrestaShop package installs the current release on a PHP application server with OPcache and friendly URLs enabled, plus a MariaDB database, with the installer completed.
Why not Shopify, briefly
The owner considered it. Shopify's per-month plan plus transaction fees on sales through third-party payment providers, and its limits on multi-currency and multilingual selling at the lower tiers, added up to a meaningful percentage of Ardenne's margin in a business where December is most of the year. PrestaShop has no transaction fee and sells in four languages and two currencies out of the box. The owner's decision was that hosting is the only thing she would pay for, and that it should be hosting that handles December.
Moving the store
The migration from shared hosting followed PrestaShop's standard path: copy the files over SFTP into the new environment's web root, import the database through the platform's built-in database manager, update the database parameters file, and regenerate the .htaccess from the back office. The owner's freelance developer did it on a Sunday morning, tested with the shop pointed at the platform subdomain, then moved the domain and issued the certificate with the Let's Encrypt add-on. The store was on the new environment by lunch and no order was lost, because the old host stayed live until DNS had moved.
December, handled by vertical scaling
A cloudlet is 128 MiB of RAM plus 400 MHz of CPU, and a container uses as many as its load needs, up to the limit you set, billed by the hour on actual use. The developer set the PHP node's limit at 48 and MariaDB's at 24. From January to October the PHP node uses 6 to 8 cloudlets and the database 4. In the last week of November the PHP node climbs to 30 and 40 as PHP-FPM workers multiply for the traffic, and the database to 16; the platform allocates it as it happens, with nobody logging in. In January it falls back. The owner pays December prices in December.
| Month | Orders | PHP node, average cloudlets | MariaDB, average cloudlets | Approximate hosting |
|---|---|---|---|---|
| March | 400 | 7 | 4 | About $27 |
| October | 650 | 9 | 5 | About $34 |
| December | 2,800 | 32 | 14 | About $113 |
| January | 900 (returns and sales) | 12 | 6 | About $44 |
Figures use MassiveGRID's published $0.003372 per cloudlet-hour, before discounts and excluding disk and the public IP. The shared host had charged a flat fee and gone down twice the previous December.
Caching, because CPU is not the whole story
PrestaShop has its own cache layers, and the developer turned on what mattered: Smarty template caching in the back office, OPcache already on in the package, and PrestaShop's server cache pointed at a Redis node added from the topology wizard, which moves category and product cache off the database. The most effective change was the cheapest: enabling PrestaShop's CCC (combine, compress and cache) for CSS and JavaScript, and setting far-future cache headers on the static assets the NGINX front end serves. Between them, the December PHP peak was about half what the first year's would have been, which the platform's per-minute statistics showed clearly when the developer compared the two seasons.
Module updates without a broken checkout
The other December disaster on shared hosting had been a payment module update that broke checkout on a Saturday. The developer's rule is now that no module or PrestaShop update touches production first. He clones the environment, applies the update on the clone, places a test order with a sandbox payment, and only then repeats on production, in the morning, with the clone kept for a day as a rollback. Clones run at a low cloudlet limit and cost cents an hour; the shop has had zero checkout outages from updates since.
When one PHP node is not enough
Backups follow the same two-part pattern as any PHP store: the Database Backup/Restore add-on dumps MariaDB nightly to a backup storage node, and the image and module directories are archived to the same node by a scheduled job. The developer restores both into a clone before every peak season, which doubles as the load-test environment.
Ardenne has not needed it yet, and the developer has written down when it will: if the PHP node reaches its cloudlet ceiling for sustained periods in December, or if the owner wants a node failure to be invisible rather than a brief restart. The path is an NGINX load balancer and a second PHP node from the topology editor, with PrestaShop's images and module files kept identical across nodes by the File Synchronization add-on or a shared storage mount, and sessions moved to Redis. It is an afternoon's work and a clone to test it on, not a new server.
Frequently Asked Questions
PrestaShop or Magento for a store this size?
PrestaShop is lighter, cheaper to run and easier for a small team, and suits stores up to tens of thousands of products. Magento offers deeper B2B features and a larger enterprise ecosystem at the cost of more resources and complexity; the marketplace has both Magento Standalone and an auto-scalable Magento cluster if you outgrow PrestaShop.
Does the package support PrestaShop's multistore?
Yes. Multistore is a PrestaShop feature enabled in the back office; additional shop domains point at the same environment and are added to the Let's Encrypt add-on's domain list for certificates.
How do I keep the store online during a PrestaShop core upgrade?
Upgrade a clone first with the 1-click upgrade module or the manual procedure, test, then upgrade production during a quiet hour with maintenance mode on for the minutes the upgrade takes. Keep the pre-upgrade clone for a day as the rollback.
Pay December prices in December
The PrestaShop package installs PrestaShop with a tuned PHP server and MariaDB in one click on MassiveGRID PaaS. Set a cloudlet ceiling for the season and pay by the hour for what the shop uses. Free 14-day trial, no credit card.
PrestaShop on MassiveGRID PaaS