PrestaShop Hosting: Requirements, Setup & Performance

Hosting is the floor your shop sits on

We have run PrestaShop on roughly every hosting tier that exists: cheap shared cPanel boxes inherited from clients, VPSes at Hetzner and OVH, dedicated machines in datacentres, and the office TrueNAS that hosts mypresta.rocks itself. After ten-plus years of this, our position is simple — no amount of caching, image optimisation, or module tuning will save a shop that's stuck on undersized or misconfigured hosting. Get the floor right first, then everything above it gets easier.

This page is opinionated on purpose. It's where we'd send a client who asks "what should I host on?" before they sign anything.

Hosting types, in order of when they're actually appropriate

Cheap shared hosting (around $3-15/month)

Your shop shares a server with hundreds of others. You get cPanel or DirectAdmin, a locked PHP configuration, and no root access. The good ones (we've seen them) let you pick a recent PHP, enable OPcache, and don't oversell the disks. The bad ones do all the opposite.

What you get: low monthly bill, email included, someone else patches the OS.
What you give up: noisy neighbours that randomly tank response times, no SSH on entry plans, no Redis, no Varnish, PHP versions you don't pick, and a shared IP that another tenant can blacklist on your behalf.

Fine for a brand-new shop under 500 products with low traffic and no time pressure to optimise. Not fine for anything you're trying to grow.

VPS (managed or unmanaged, $5-60/month)

Dedicated RAM, dedicated CPU, dedicated disk, root access. This is where most of our client shops live, and it's where we'd put yours.

Managed VPS: Provider patches the OS and handles security updates. You handle PrestaShop. A control panel or managed service usually adds $5-20/month on top of the raw VPS price.
Unmanaged VPS: A blank Debian or Ubuntu box with SSH. Cheaper, but you own every line of nginx config and every kernel update.

For 90% of the shops we touch, a managed VPS in the $15-30/month range outperforms shared hosting in every dimension that matters.

Dedicated server ($80-300+/month)

A whole physical machine, no hypervisor overhead. Overkill for a shop with 2,000 products. The right call when you cross 50,000 products with serious traffic — that's where we move clients off cloud VPS and onto something like a Hetzner dedicated, because the price-to-performance ratio gets ridiculous in your favour.

Cloud VPS

Hourly billing, fast provisioning, snapshots, an API. 2GB / 2 vCPU sits in the $5-15/month band across the providers worth using, and EU-based providers reliably undercut the US ones for equivalent specs.

"Managed PrestaShop" hosting

Pre-configured boxes with PS-specific support. The pitch is appealing if you've never touched a server. The reality is it's usually resold infrastructure with a markup, and the support knows the shop control panel — not your specific modules.

Managed PS hosting earns its money when you genuinely have zero appetite to learn a server. For anyone else, a managed VPS with a sane LEMP stack performs better and costs less.

Minimum requirements, by PrestaShop version

PrestaShop 1.7

PHP: 7.1-7.4 • MySQL: 5.5+ (5.7 recommended) • RAM: 2GB floor, 4GB sensible
Extensions: curl, gd, intl, mbstring, zip, xml, json, openssl

PrestaShop 8.x

PHP: 7.2-8.1 (8.1 is the one we deploy on) • MySQL: 5.6+ • RAM: 4GB floor
Extensions: the 1.7 list plus fileinfo and iconv

PrestaShop 9.x

PHP: 8.1-8.4 (we run 8.2 in production) • MySQL: 8.0+ or MariaDB 10.5+ • RAM: 4GB floor, 8GB if you've got real traffic
Extensions: the 8.x list, with Symfony 6.4's requirements applying on top

Treat these as "the shop will install" numbers, not "the shop will perform" numbers. A 5,000-product catalogue with 50 modules and live traffic wants 4-8GB of RAM regardless of which version is on the floor.

Sizing guide

Store size	Products	Daily visitors	RAM	CPU	Disk
Starter	<500	<200	2GB	1 core	20GB SSD
Small	500-2K	200-1K	4GB	2 cores	40GB SSD
Medium	2K-10K	1K-5K	8GB	4 cores	80GB SSD
Large	10K+	5K+	16GB+	4-8 cores	160GB+ SSD

A reminder on disk: 5,000 products with 5 images apiece, regenerated across 7 PrestaShop image types, eats 10-20GB before you've added anything else. Plan disk accordingly.

What actually moves the needle

Every host quotes cores, RAM, and bandwidth. In our experience, here's the order things actually matter in.

1. PHP version and OPcache

PHP 8.1 is roughly 20-40% faster than 7.4 on the same code, and OPcache turns out to be the bigger win on top of that. Without OPcache, PrestaShop recompiles hundreds of PHP files on every request. With it, the compiled bytecode comes straight from memory.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

If a host won't let you enable OPcache, or is still serving PHP 7.x in 2026, walk. There's no upside.

2. Disk I/O — SSD or NVMe, never spinning rust

PrestaShop reads hundreds of files per page. HDD random read sits around 5-15ms, SSD at 0.1ms. That alone makes a 3x difference in real page time. We will not deploy a shop on HDD. Neither should you.

3. MySQL configuration

A typical PS page fires 100-300 queries. The single setting that matters most is innodb_buffer_pool_size — it controls how much of your data lives in RAM. 50-70% of total RAM on a dedicated database server, 25-40% on a combined app+DB box. Before tuning around a bloated database, use Database Cleanup or equivalent SQL audits to trim abandoned carts, logs and stale statistics.

4. RAM

Each PHP-FPM worker uses 30-80MB of resident memory. Ten workers means 300-800MB just for PHP, then add MySQL, Redis, OPcache itself, and the OS. 2GB is tight before you've served a single request.

5. HTTP/2

Multiplexes everything over a single connection. 20-40% faster on pages loading 60-80 assets, which is most PrestaShop pages. Needs HTTPS, which you needed anyway.

Shared hosting: the walls you'll hit

Shared can work for the smallest shops, but you'll bump into these in roughly this order:

No SSH. You can't run CLI Composer, console commands, or any of the cleanup scripts we'd normally lean on.
Cron limits. Many shared hosts cap cron at every 15 minutes. PrestaShop's housekeeping wants more.
memory_limit capped. 128-256MB is normal on cheap plans. Big imports fail silently when they hit it.
No Redis. You're stuck on filesystem caching, on shared storage that's already busy.
Shared IP. A neighbour's spam habit blacklists your IP, and order confirmation emails stop landing. We cover the fix in our email deliverability guide.

If you're shopping shared anyway, prioritise SSH access, a control panel that lets you pick the PHP version, OPcache support, and a memory limit you can raise. And always read the renewal price — the intro number is marketing.

$2.99/month renews at $10.99 a year later. Every cheap-shared review site glosses over this. We don't.

VPS: the right choice for most shops

Why we keep ending up here

Root access. Install Redis, Varnish, the whole stack.
Dedicated CPU and RAM. No neighbour to blame at 2pm on Black Friday.
Full PHP-FPM and OPcache control.
Unrestricted SSH and cron.
nginx, not Apache, unless you choose otherwise.
Snapshots before risky upgrades — three clicks to roll back.

What to actually check before you sign up

SSD or NVMe storage. If the spec sheet doesn't say, assume HDD and skip.
Fair pricing. 2GB / 2 vCPU at $5-15/month is normal. $30 is overpaying.
Datacentre location. EU shops want EU datacentres. Latency is real, GDPR is realer.
Cheap snapshots. The single feature that pays for itself the first time a module upgrade goes sideways.
Documentation. You're going to spend time in their docs. If they're thin, that tells you something.

If you've never managed a Linux box, pay the extra for managed service or a control panel. A misconfigured VPS will outperform shared hosting in benchmarks and underperform it in real life because nobody patched the kernel.

LEMP stack baseline

# Debian 12 / Ubuntu 22.04
apt install nginx php8.2-fpm php8.2-mysql php8.2-curl \\
    php8.2-gd php8.2-intl php8.2-mbstring php8.2-xml \\
    php8.2-zip php8.2-opcache mariadb-server redis-server -y
mysql_secure_installation

Never run a Linux server before? Start with managed VPS or a panel. A broken DIY VPS is worse than shared hosting. Our security hardening guide covers what to lock down after you're up.

Dedicated and cloud: when the VPS isn't enough

Move up when you've got 50K+ products, sustained 5K+ daily visitors, a multistore with five or more shops sharing the box, or a real 99.99% uptime requirement.

A dedicated 64GB / NVMe box from a European provider can land at EUR 40-60/month — more capacity than most shops will ever use, but the price-to-performance gap versus cloud VPS at the same spec is hard to argue with.

The scaling order, when you do need to scale: pull MySQL onto its own server first (biggest single jump), then put Redis on its own instance, then think about a load balancer with multiple app servers — and at that point you also need shared storage and Redis sessions, so don't skip ahead.

Server configuration for PrestaShop

nginx, not Apache

Apache is the default because shared hosting uses it, not because it's the better fit. nginx uses event-driven I/O (10-30MB per process versus 300-800MB for Apache prefork), serves static files without going through PHP, and ships with a FastCGI cache out of the box.

If you're locked into Apache, run mpm_event with PHP-FPM, never mpm_prefork with mod_php. The latter is the slowest PrestaShop deployment we've seen in the wild.

PHP-FPM settings

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500
php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 300

Formula we use for pm.max_children: (RAM in MB - MySQL footprint - OS) / 50MB per worker. On a 4GB box: (4000 - 1500 - 500) / 50 = 40. We set 20-30 to leave headroom, because a maxed-out FPM pool means 502s in the customer's face.

MySQL tuning

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
long_query_time = 1

Turn the slow query log on day one. A single bad query running 200 times per page beats any "slow server" diagnosis we've ever made — and the log is how you find it. Our performance guide walks through what to do once you've got the offenders.

Redis for sessions and cache

PrestaShop puts sessions and cache on disk by default. Move both to Redis and the admin pages stop blocking on filesystem session locking, which is the single most common cause of "the back office is so slow" tickets we open. Redis costs you 50-100MB of RAM and pays it back immediately.

SSL/TLS — not optional

Every shop needs HTTPS. Google ranks HTTP down, browsers shame it, and no payment provider will work without it. The argument is over.

Let's Encrypt

Free, automatic, 90-day renewal. Certbot installs it once and you forget about it:

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourshop.com -d www.yourshop.com

Cloudflare SSL

Free via their proxy, with one trap: always use Full (Strict). Flexible mode sends plaintext between Cloudflare and your origin, which defeats the whole point. Set X-Forwarded-Proto so PrestaShop knows it's behind HTTPS even when the origin hop is HTTP-ish.

Force HTTPS

Enable in Shop Parameters → General, then add the server redirect:

# Nginx
server {
    listen 80;
    server_name yourshop.com;
    return 301 https://yourshop.com$request_uri;
}

# Apache (.htaccess)
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

CDN: when and how

If you serve one region from a local server, the CDN doesn't buy you much speed. What it does buy you is caching of static assets and a free DDoS layer.

Cloudflare's free tier covers most shops: global CDN, free SSL, basic DDoS, HTTP/2, Brotli. Wire it up in Advanced Parameters → Performance → Media Servers.

Cache aggressively: images, CSS, JS, fonts.
Never cache: admin, cart, checkout, my-account, anything that touches a PrestaShop cookie.

Never turn on "Cache Everything" for the whole domain. We've seen it: one customer sees another customer's cart because the checkout got cached at the edge. Cache static assets and named URL patterns only.

Backups: the host's snapshots are not a strategy

Provider backups are usually weekly, run on the same infrastructure, and have a non-zero chance of not restoring when you need them. That's a comfort blanket. If the provider has a bad night, the backups go with the shop. If ransomware encrypts your files, the encrypted versions get dutifully backed up. And you probably want a database from two hours ago, not last Tuesday.

What you want, minimum: daily automated DB dumps plus file backups, stored off the production server, kept for 30 days, with a test restore every month. Schedule those jobs somewhere visible; MPR Cron Manager is the PrestaShop-side option when you want backup tasks tracked instead of hidden in anonymous crontab lines. Our backup guide has the runbook.

Migrating between hosts

Provision the new server with the same PHP version and the same extensions.
Dump the database: mysqldump -u root -p prestashop_db | gzip > backup.sql.gz
Sync files: rsync -avz /var/www/html/prestashop/ newserver:/var/www/html/prestashop/
Import the database on the new server.
Update credentials in app/config/parameters.php.
Fix permissions: chown -R www-data:www-data, dirs 755, files 644.
Clear cache: rm -rf var/cache/*
Test via /etc/hosts — point your laptop at the new IP and walk through checkout and admin before anyone else does.
Lower DNS TTL to 300 seconds 24 hours before the cutover.
Final DB sync right before flipping DNS, so the last orders aren't lost.

Where migrations go wrong

File ownership. The web user has to own the files. Cache, img, upload, download all need to be writable.
Missing .htaccess. Migration GUIs love to skip dotfiles. Apache also needs AllowOverride All to honour it.
Base URL mismatch. If the domain changed, update ps_shop_url or every link breaks.
PHP version jump. Going 7.4 to 8.1 breaks any module still calling deprecated functions.

Never flip DNS before you've tested via /etc/hosts. We've watched two migrations break checkout in production because nobody clicked "buy" on the new server first.

Red flags: walk away when you see these

Technical

No SSH. You can't deploy, you can't debug, you can't run any of the tools that actually fix problems.
PHP 7.x in 2026. End of life. Known vulnerabilities that won't be patched.
No OPcache. 3-5x slower than the same code with OPcache on. No reason for it.
HDD storage. If they don't say SSD or NVMe in writing, assume HDD.
Locked php.ini. You can't run PrestaShop properly without raising at least memory_limit.

Business

"Unlimited" anything. Nothing is unlimited. They throttle the noisy tenants instead of saying so.
Holding-company brands. Five "different" hosts owned by the same parent, all on the same oversold tin, different logos.
No uptime SLA. They don't trust their own infrastructure enough to put a number on it.
Support replies in days. A 2am outage needs minutes, not "next business day".
Forced annual billing. They're counting on you not leaving when you realise it was a mistake.

The cheapest hosting is the one that stays up during Black Friday. Saving $5/month on a host that loses you $5,000 in conversions over a weekend is not saving anything.

Pre-purchase checklist

Every line here matters. Tick them off before you put a card in.

Server

PHP version matches your PrestaShop version
All required PHP extensions available (intl, mbstring, gd at minimum)
php.ini is configurable (memory_limit, OPcache settings)
MySQL or MariaDB at a version PrestaShop actually supports
SSD or NVMe in writing
SSH access
Unrestricted cron frequency

Performance

OPcache enabled and configurable
4GB+ RAM on the plan you're picking
HTTP/2 enabled
Redis or Memcached available

Reliability

99.9% or better uptime SLA
Automated and manual backup options
Critical support response measured in hours, not days
Datacentre near your customers

Pricing

Renewal price (not intro price) checked
Monthly billing available
Bandwidth or transfer limits understood
No clause preventing you from migrating away

What we'd put you on, by stage

Brand new shop: Cloud VPS with 2GB RAM ($5-10/month) plus a free CDN and Let's Encrypt. Beats most $15/month shared by a mile.
Growing shop: Managed VPS at $15-30/month. Pay someone to keep the OS patched while you focus on selling.
Established (1K+ visitors a day): VPS with 8-16GB RAM, MariaDB tuned, Redis on, nginx with FastCGI cache. $15-40/month gets you there.
Big catalogue or heavy traffic: Dedicated server (cheap EU dedicated outperforms cloud VPS at this scale) or a properly separated cloud architecture. $50-100+/month and worth every cent.

Set up uptime monitoring on day one — UptimeRobot is free for 50 monitors and good enough. Once hosting is sorted, the rest of the optimisation work has somewhere solid to land.