PrestaShop hosting: a server built for your store

No. A full copy of the store runs on the new server under a temporary address, and the switch-over is a DNS record change we prepare with a short time-to-live. The old server stays on until every cached response has expired. We plan the switch-over window outside peak sales hours.

Before the switch we run an incremental database sync, so orders from the last few hours land on the new server too. Sales aren't paused, but for a short window part of the traffic still sees the old server, which is why we pick the lowest-load window for it.

It's decided by the number of products and variants, the number of concurrent sessions at peak, and whether integrations with their own request limits are running in the background. A store with a large catalogue and filters loads the database completely differently from a store with two hundred products at the same traffic, so the parameters come from measurement, not from a package name.

You sign the hosting agreement directly with the provider, so its uptime SLA binds them to you, not to us. We size the parameters, configure the environment and maintain it, but you have the access from day one. Changing agency doesn't mean another move.

Four parameters decide how a store runs, and they rarely sit on the front page of an offer: PHP version with its limits, cache such as LiteSpeed or Redis, NVMe SSD disks, and backups. On backups, check three things: how often they run, how far back they reach, and whether restoring the store is included or billed separately. Good PrestaShop hosting is judged by these items, not by the number of gigabytes in the package.

We're not a hosting company and take no commission from any provider, so our recommendation follows from your store's size and PrestaShop's requirements, not from a partner's price list. Installing the store, configuring the admin panel, moving it from your current server and technical support when something breaks are our job. The subscription itself stays on your invoice, with your provider, and that's a difference you notice after a year.

The machine and the system

Cores, memory, disk, and whether resources are guaranteed or shared with neighbours. This is also where the uptime SLA the provider writes into the contract lives. For a store, what matters isn't the average but the worst hour of the year, because that's when the server either keeps up or costs you orders.

The application layer

PHP version, per-process memory limits, code cache, connection compression and encryption. The same machine with default settings versus with PrestaShop-specific configuration is a difference in load time you see without spending an extra penny.

The database

Tuning for the catalogue and its filters, indexes matched to your store's real queries, cleaning up tables that grow on their own. On a large catalogue, this is where most of a category page's load time hides.

Backups and monitoring

Three copies, in two locations, one of them off the store's own server, plus an alert that wakes a human before a customer notices. We set this up once and maintain it server-side. Hours for store code and a contracted response time to tickets are post-launch care, a separate agreement.

How long the move takes

The move itself usually takes two to six hours of work, and then up to a day for the address change to propagate across the internet. The store keeps running the whole time, because the old server stays on until the last visitor reaches the new one.

PrestaShop 8 runs on PHP 8.1 and newer, and older store versions on older PHP that providers are already dropping support for. Beyond the version itself, the limits matter: per-process memory, maximum execution time and upload size. Many providers' defaults are set for a brochure site, not a store running a catalogue import.

MySQL or MariaDB in a version supported by your store's release, on an SSD or NVMe disk. On a catalogue with filters, the database is the bottleneck, so what matters isn't just disk size but how many operations per second the provider guarantees.

OPcache holds compiled code, so PHP doesn't reprocess the same files on every visit. Redis stores sessions and store cache outside the database, which takes a large share of load off it once traffic grows. Both are free, and both are often disabled by default.

An SSL certificate is a requirement today, not an extra: without one, browsers flag the store as unsafe and payments won't work. A free, auto-renewing certificate is entirely enough for a store, unless you take card payments through your own form.

Daily backups stored off the store's own server, with the ability to restore a single file, not only the whole thing. On top of that, access to the server's admin panel and console, because without them every configuration change means a ticket to the provider and waiting.