PrestaShop's official system requirements fit on one screen. They tell you what will install. They tell you almost nothing about what will hold up when your catalogue is 20,000 products and a newsletter lands on a Tuesday morning.
Both matter, so here is both: the official minimums, verbatim from PrestaShop's developer documentation, and then the sizing work that the requirements page deliberately does not attempt.
The official requirements
From the PrestaShop developer documentation, current as of August 2026:
| Requirement | PrestaShop 9 | PrestaShop 8 |
|---|---|---|
| Web server | Apache 2.4 or later (nginx 1.0+ also supported) | Apache 2.4 or later (nginx 1.0+ also supported) |
| Database | MySQL 5.7 minimum or MariaDB 10.2 minimum | MySQL 5.7 minimum or MariaDB 10.2 minimum |
memory_limit |
512M minimum recommended | 256M minimum recommended |
| Operating system | Unix-based (Linux, macOS); Windows not actively supported | Same |
PHP version support
This is where most upgrade planning goes wrong, so read the chart rather than the headline.
| PrestaShop version | Supported PHP | Recommended |
|---|---|---|
| 9.1 | 8.1, 8.2, 8.3, 8.4, 8.5 | 8.5 |
| 9.0 | 8.1, 8.2, 8.3, 8.4 | 8.4 |
| 8.0 – 8.2 | 7.2, 7.3, 7.4, 8.0, 8.1 | 8.1 |
Two things follow. PrestaShop 9.0 does not support PHP 8.5 — only 9.1 does. And PrestaShop 8 does not support PHP 8.2 or later per the official chart, which means a PrestaShop 8 store on a host that has moved its stack to PHP 8.2+ is running outside the supported matrix. Neither the docs nor the newest supported line covers PHP 8.6 or above.
Required PHP extensions
CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO, PDO (MySQL), SimpleXML, Zip.
Plus one setting that catches people: allow_url_fopen must be On. PrestaShop uses it for remote file access as part of the payment process, among other things. Some hardened shared-hosting stacks disable it by default, and the resulting failure surfaces at checkout rather than at install.
PrestaShop also ships a phppsinfo.php checker you can upload to a candidate server to verify all of this before committing.
What the requirements page cannot tell you
The minimums are an install gate, not a capacity plan. Four variables actually decide what you need:
Catalogue size. A 200-product store and a 50,000-product store are different applications. Product count, combinations (a product with 4 sizes × 6 colours is 24 combinations), and images per product all multiply.
Concurrency, not visits. "10,000 visits a month" is not a sizing input. Peak concurrent sessions is. A campaign that lands 400 people on the site in ten minutes is a different machine from the same traffic spread over a day.
Cached versus uncached ratio. Category pages and product pages cache well. Cart, checkout and logged-in sessions do not, and they are the pages that make money. Size for the uncached path.
Module count. This is the one nobody plans for. Every module adds hooks, and hooks execute on page render. A store with 60 modules is doing substantially more work per request than the same store with 20, on identical hardware.
Choosing the tier honestly
| Store profile | Sensible platform |
|---|---|
| Under ~1,000 products, modest traffic, standard modules | Managed shared hosting |
| A few thousand products, growing traffic, some custom modules | VPS |
| Large catalogue, heavy concurrency, custom integrations, strict uptime | Dedicated server |
NexonHost's PrestaShop hosting plans cover the first row and part of the second — from a 5 GB Starter tier at €2.49/month to a 50 GB Agency tier at €24.99/month supporting 25 sites, all on NVMe-backed, DDoS-protected infrastructure with free SSL and a managed migration path.
Note what storage actually has to hold: PrestaShop's own footprint, the database, product images in every generated thumbnail size, invoices, and logs. A catalogue with 5,000 products and 4 images each generates tens of thousands of image files once thumbnails are produced. Storage plans on shared tiers are consumed by images far more often than by code.
When a store outgrows shared hosting, the honest next step is a Linux VPS — root access, your own PHP-FPM pool sizing, your own MySQL tuning — and beyond that a dedicated server where the database gets dedicated memory and the storage layer is not shared.
The five settings that matter most
Once you control the stack, these produce more improvement than any hosting upgrade:
- OPcache, sized properly. PHP recompiling PrestaShop's class hierarchy on every request is the single biggest avoidable cost. Enable OPcache and give it enough memory that it is not evicting entries — check
opcache_get_status()rather than assuming. innodb_buffer_pool_size. MySQL's default is far too small for an ecommerce workload. On a dedicated database host, a substantial share of system RAM belongs here; the goal is for the working set to be in memory rather than on disk.- PHP-FPM pool sizing against real RAM.
pm.max_childrenset higher than memory allows converts a traffic spike into swapping, which is slower than refusing the connection would have been. Measure actual per-process memory and divide. - A real caching layer. PrestaShop supports filesystem, Memcached and Redis caching. On anything past a small store, Redis or Memcached is the correct answer, and the filesystem is not.
- HTTP caching and a CDN in front of static assets. Product images are the bulk of the bytes and none of the logic. Serving them from the origin on every request wastes the resource you are paying for.
Failure modes worth recognising
- Checkout fails but browsing works. Check
allow_url_fopenand outbound connectivity to the payment provider. Both are frequently blocked on hardened shared stacks. - The back office is slow while the front is fine. Usually a module, or statistics/logging tables that have grown without bound.
- Everything is fine until a campaign. Concurrency limit, almost always PHP-FPM children or MySQL max connections.
- Upgrade breaks on a version bump. Check the PHP compatibility chart above before touching the PrestaShop version. Half of PrestaShop upgrade failures are a PHP version mismatch that the chart predicts.
- Storage full, no obvious cause. Generated image thumbnails or
var/logs.
Before you migrate
Whatever you choose, verify three things on the target: the PHP version against the chart for your PrestaShop version, the extension list, and allow_url_fopen. Run phppsinfo.php on the candidate host and read the output. Fifteen minutes there prevents the class of problem that only appears at checkout.
If the store is moving providers, NexonHost's PrestaShop plans include a managed migration covering files, database, themes, modules and configuration — the relevant part being that migrations are scheduled rather than improvised, which is what "zero downtime" actually requires.
Related reading: cPanel vs DirectAdmin vs Plesk, how to install a production-ready LAMP stack on Ubuntu, and website DDoS protection for ecommerce and high-traffic sites.
Sources
- PrestaShop 9 system requirements and PrestaShop 8 system requirements, PrestaShop Developer Documentation, retrieved 20 August 2026.
- Plan specifications and pricing as published on nexonhost.com on 20 August 2026; check the product page for current figures.
