PrestaShop (a long-running PHP shopping cart you run on your own server, instead of renting from a SaaS) has earned a reputation as one of the more painful e-commerce installs. Most of that reputation is outdated. On a fresh Ubuntu 26.04 box the install is a couple of apt commands, a database setup, and a five-screen web installer. The boring parts are exactly what makes it good for a small store that needs to stay up.
This walkthrough is the version I wish I had three PrestaShop installs ago. I am writing it for someone comfortable with the Linux command line, comfortable editing one Apache config file, and not afraid of error messages. You do not need PHP expertise.
What Ubuntu 26.04 changes about this install
The reason this install feels smoother in late 2026 than the older walkthroughs suggest is that the package versions finally line up. Ubuntu 26.04 ships a current PHP and MariaDB (a community-maintained drop-in replacement for MySQL, so anywhere the docs say “MySQL” you can use MariaDB without changes), which means PrestaShop’s 8.x line installs without backports, custom PPAs (Personal Package Archives, user-maintained software repositories outside the official Ubuntu archives), or hand-compiled extensions. The old guides that walked you through pinning PHP 7.4 from a third-party repo are no longer needed.
Two pieces of infrastructure changed in ways that matter for the install:
- Apache 2.4 ships with a saner default vhost (virtual host, a single config block that defines one website’s settings) and
mod_rewriteis onea2enmodaway, so pretty URLs work out of the box. - MariaDB 11 changed the default authentication plugin to
unix_socketfor the root user, which means the database is locked down by default. You do not have to remember to set a root password before the database is reachable.
Both changes are small, but together they remove about ten minutes of pre-install fiddling that older guides treated as mandatory. Plan on forty minutes for the whole install, including SSL (the HTTPS certificate that encrypts traffic between your browser and the shop, without it, login credentials travel in plain text) and a backup test. Not twenty. Forty.
The prep that actually matters
Most PrestaShop install failures I have seen trace back to the same handful of skipped steps. The browser-based installer is forgiving, but the surrounding server setup is not.
Before you run anything, make sure you have:
- A fresh Ubuntu 26.04 server, ideally one you have not customized heavily.
- A domain name with an A record pointing at the server’s IP.
- 2 GB of RAM minimum. PrestaShop alone is light, but the module catalog is where memory goes.
- Root or sudo access. Some hosting providers give you a locked-down user that cannot edit
/etc/apache2/, and those accounts cannot do this install. - Twenty uninterrupted minutes, plus another twenty for backups afterward.
Do not try to install PrestaShop on a raw IP address. You can test the install that way, but the moment you want HTTPS for the admin panel, you need a hostname for Let’s Encrypt (a free, automated certificate authority that issues browser-trusted HTTPS certificates) to issue a certificate against. Moving an existing install to a hostname is a half-day of database surgery. Set up the domain first.
The actual install
Pull everything in one shot. The apt packages below cover a clean PrestaShop 8.x install with no extra steps:
sudo apt update && sudo apt upgrade -y
sudo apt install apache2 mariadb-server php php-mysql php-xml \
php-curl php-gd php-zip php-mbstring php-intl unzip -y
Lock down the database with sudo mysql_secure_installation. On Ubuntu 26.04 you will probably see MariaDB respond that the root account is already using unix_socket auth, in which case the script’s password prompt is mostly cosmetic. Still run it. Then create a database for PrestaShop and a dedicated user with access to that one database only.
The reason for the dedicated user is not theoretical. When (not if) a PrestaShop module has a SQL injection vulnerability (a coding flaw that lets an attacker sneak database commands through a normal web form), the blast radius is the database user the module connects with. If that user only has SELECT and INSERT on one schema, the attacker only has SELECT and INSERT on one schema. If that user is root, the attacker owns the box. A least-privilege database user is the single highest-leverage thing you can do during install.
Download the PrestaShop zip from prestashop.com itself. The current line is 8.x. Third-party mirrors sometimes carry old versions with known vulnerabilities, and the official site’s download endpoint is the version everyone else is testing against. Move the zip into /var/www/html/, unzip it, and then run:
sudo chown -R www-data:www-data /var/www/html/prestashop
That single command is the one most people forget on their first try. The Apache process on Ubuntu runs as the www-data user. If the PrestaShop files are owned by root, the installer either refuses to write the configuration or, worse, completes the database setup and then dies silently when Apache tries to serve the storefront. I have personally watched this exact sequence eat forty minutes. Run the chown before you open the browser to the installer.
The configuration traps nobody warns you about
A few Ubuntu 26.04 specific traps do not appear in older PrestaShop guides because they only showed up recently. Knowing about them ahead of time is the difference between a forty-minute install and a half-day debugging session.
First, PHP module compatibility. Ubuntu 26.04 ships PHP 8.3, and PrestaShop 8.x supports it. Third-party modules sometimes still target PHP 8.1 or 8.2 specific features. If you install a module that targets 8.1 and you are running 8.3, you will get warnings, then white screens on product pages, then a tail of error log entries that do not name the offending module. Either pin your PHP version down or wait for the module to update. Do not try to install the latest PHP and the latest module at the same time. That is the failure combination.
Second, AllowOverride All. Apache’s default virtual host on Ubuntu does not enable .htaccess overrides for performance reasons. PrestaShop’s pretty URLs (/category/red-shirt instead of /index.php?id=42&cat=3) are written in a .htaccess file. If you do not set AllowOverride All for the PrestaShop directory, the installer completes, the storefront looks fine, and then every category link 404s. Edit /etc/apache2/sites-available/000-default.conf, add a <Directory> block for /var/www/html/, and run sudo systemctl reload apache2.
Third, Let’s Encrypt timing. Run sudo certbot --apache -d yourdomain.com after the install completes, not before. Certbot’s Apache plugin rewrites your virtual host to force HTTPS, and if you run it before PrestaShop has generated its first URL rewrites, the cert install and the URL setup step on the same virtual host in ways that occasionally leave one of them broken. Install PrestaShop first, get the storefront serving over HTTP, then turn on HTTPS.
Picking the right cart for your situation
PrestaShop is the right answer for some stores and the wrong answer for others. Spending five minutes here will save you a migration later.
WooCommerce is the right pick if your store is really a blog with a checkout button. If you are already running WordPress, WooCommerce installs in five minutes and inherits every content marketing tool you already use. The downside is that WooCommerce sits on top of WordPress’s update treadmill, and the moment you have a few thousand products the database schema (the structure of how products, orders, and customers are stored in tables) starts to creak.
Shopware is the right pick if you want a more modern PHP codebase and you are comfortable reading German-engineered documentation (their official docs are bilingual). European mid-market retailers use it for its built-in B2B features. Smaller shops usually find it heavier than they need.
Medusa is the right pick if you want headless commerce (a setup where the storefront frontend and the backend cart talk to each other over an API, instead of sharing the same templates). It is JavaScript-based, fast, and what you pick when the design team wants full control of the storefront. The cost is operational complexity. You are now running a Node service, a database, and probably an Elasticsearch instance (a search engine specialized for fast product search).
PrestaShop sits in the middle: PHP-native, a larger module catalog than the alternatives, and a gentler learning curve. The catalog is the reason people stay, because every problem a small store runs into has been solved by a module someone else already wrote.
Trade-offs to budget for
Running your own e-commerce server has costs that are easy to underestimate until you hit them. Naming them out loud is fairer than pretending they do not exist.
Backups. PrestaShop stores products and orders in the database, product images on disk. A complete backup means dumping the database AND mirroring the uploads directory. Test the restore before you go live. The day you discover your restore process does not work is the day after you lose data, and there is no softer way to put that.
Security patches. Ubuntu will patch itself if unattended upgrades are enabled. PrestaShop core and your installed modules will not. Subscribe to the PrestaShop security mailing list and read release notes once a month. Most module vulnerabilities are minor. The occasional one is not.
Capacity planning. A 1 GB VPS feels fine until your product catalog crosses a few hundred items. A 2 GB VPS feels fine until you start adding image-heavy modules. Either size up early or migrate to a Docker Compose setup (a small YAML file that defines how several containers start together) before the wall hits. Retrofitting containers onto a live shop is harder than starting fresh.
What I would do if I were starting over today
Run PrestaShop in Docker Compose from day one, even if the install feels like overkill for a small store. The official PrestaShop Docker images work, the community images are better, and the moment you need to migrate servers, debug a broken module update, or roll back to last week’s working state, the container setup pays for itself. If you must run on bare LAMP, fine, but snapshot the server before going live so a bad module update does not eat your week.
Spend forty minutes on the install, twenty more on backups, and you are done. The boring parts are the parts that keep the shop running.