Installation and Local Environments

The following PHP extensions are required: curl (download of modules and localisation packs), dom, fileinfo, gd (thumbnails), iconv, intl (localised amounts), json, mbstring, openssl, PDO, pdo_mysql, SimpleXML and zip (expanding modules and packs). allow_url_fopen must be On, because PrestaShop reads remote files, among other things during payment processing; allow_url_include should stay Off.

On a host you can check them with the project’s phppsinfo.php tool (download it from the PrestaShop/php-ps-info repository, upload it next to the shop and open it in a browser; the documentation says the login and password are prestashop, so remove it afterwards). In a container or on the command line, ask PHP directly.

Source: PrestaShop devdocs: System requirements

All thirteen extensions printed ok in the official image, and allow_url_fopen=On and allow_url_include=Off were the settings; the image also ships bcmath, soap, sodium and OPcache, and a CLI memory_limit of 512M. Replace prestashop with the name of your own container, or drop docker exec prestashop to run the check on a host.

The installer can create the database (--db_create=1 on the command line) but it then uses the server default collation. On the MySQL 8.4 test server that default is utf8mb4_0900_ai_ci, while the PrestaShop documentation asks for utf8mb4_general_ci. Create the database yourself with the collation the documentation names, and give the shop a dedicated user that owns that database only.

Source: PrestaShop devdocs: Installation

Run on MySQL 8.4.13 these statements succeeded, and information_schema.schemata then showed pocketcoffee with utf8mb4 and utf8mb4_general_ci. Replace the host part % with the host the web server connects from on a real server (for example localhost); it was % here because the database ran in another container. With MySQL 8 and a mysql client or PHP driver old enough not to know caching_sha2_password or the utf8mb4 charset, the official Docker README lists workarounds (force mysql_native_password, change the server charset); the PHP of the 9.2.0 image connected to MySQL 8.4 without any of them.

PrestaShop needs recursive write permission on these folders: admin-dev/autoupgrade (an autoupgrade folder inside the admin folder), app/config, cache, config, download, img, log, mails, modules, override, themes, translations, upload and var. The files must belong to the user that runs PHP (www-data on Debian and Ubuntu and in the official image). The documentation’s development shortcut, running Apache as your own user, must never be used in production: set owners and modes folder by folder instead, and avoid mode 777.

Source: PrestaShop devdocs: Installation, setting up file permissions

The three commands are the usual starting point for a host install (the official image already does this); they were not run on a host for these pages. In the image every file of the shop belongs to www-data; the folders checked (var, app/config, img, modules and themes) have mode 755 and parameters.php and .htaccess mode 644.

Opening the shop before it is installed redirects to the installer (the test container answered 302 to /install/). The installer lists seven steps, which are the strings the installer itself displays:

Source: PrestaShop user documentation: Installing PrestaShop

The seven titles were read from the installer page of the 9.2.0 image and the field descriptions of steps 2 to 7 from the installer’s own view templates; the steps were not clicked through in a browser, because the command-line installer runs the same code and is easier to repeat.

The Docker entrypoint also passes --newsletter and --send_email, which exist in the installer but are not listed by the built-in help.

These are the variables the 9.2.0 image defines, with their defaults as printed by docker run --entrypoint env and as used by the entrypoint script.

Source: PrestaShop/docker: README and entrypoint and PrestaShop devdocs: Installing PrestaShop with Docker

The defaults above are what the image does. The documentation’s table disagrees with the image on several lines, which causes real mistakes: it lists PS_INSTALL_AUTO as 1, PS_FOLDER_ADMIN as admin-dev, PS_FOLDER_INSTALL as install-dev, PS_COUNTRY as fr, DB_SERVER as mysql, DB_PASSWD as prestashop, ADMIN_PASSWD as "Correct Horse Battery Staple" and PS_DEV_MODE as 1. In the 9.2.0 image the values are those in the table above. In particular the image does not start in developer mode unless you ask for it.

The following Compose file starts MySQL 8.4 and PrestaShop 9.2.0, installs the shop automatically for the domain localhost:8096, keeps the database and the shop files in volumes, and waits for MySQL to be healthy before starting the shop. The three passwords come from a .env file next to it, which you create with your own values and never commit.

Source: PrestaShop devdocs: Installing PrestaShop with Docker

Source: PrestaShop devdocs: Installing with Docker

This file was run with docker compose up -d. docker compose config -q accepted it, MySQL became healthy, and the shop container logged the installer messages ending with "Installation successful!". The front office answered 200 on http://localhost:8096/ with the demo products and the back office was in the folder printed by the installer (admin270x0zcwllwpnqk6aw1 in that run). The container showed a restart count of 1, for the reason below.

The entrypoint of the 9.2.0 image behaves as follows, and three of its behaviours surprised the test runs.

Source: PrestaShop/docker repository

The first and second items were read from the entrypoint script inside the 9.2.0 image and confirmed on the runs; the volume and PS_FOLDER_ADMIN failures were observed while the test environment for these pages was built (a first attempt without a volume, and one with a custom admin folder name), and the missing PS_DOMAIN behaviour follows the README’s troubleshooting section; they were not repeated afterwards. If the entrypoint loops on "Another setup is currently running", an install.lock was left by an interrupted install; delete it only after checking that no installer runs.

Use a full version tag such as 9.2.0 in anything you want to keep. The other tags available on 2026-10-27 for 9.2.0 are 9.2.0-apache and 9.2.0-fpm (web server variants), 9.2.0-8.1 to 9.2.0-8.5 (PHP variants of the Apache image) and 9.2.0-6.0-classic with suffixes for the PHP version and -fpm (for example 9.2.0-6.0-classic-8.5-fpm); the 9.2.0-8.5-fpm pattern does not exist. See Versions and Support for the full list and the aliases of latest.

For module and theme work, mount your source folders into the shop instead of copying them. A bind mount of a module folder is a service volume entry; the module appears in the shop and edits are visible at once, and you then install it from the command line. The container must be created with the mount (add it to the Compose file and run docker compose up -d again), because bind mounts cannot be added to a running container; to add a folder without recreating the container, copy it with docker cp and change its owner.

Source: PrestaShop devdocs: Bind a local module to your instance

The docker cp route was used for the Pocket Coffee roast date module on the shared test shop, and the bind-mount route for a demo module; both installed with "Install action on module …​ succeeded". Always run PHP commands as www-data, the owner of the files in the volume, so caches stay writable by the web server. Compose is also the place to add phpMyAdmin (phpmyadmin/phpmyadmin with PMA_HOST set to the database service) and to expose the shop to the Internet for modules that need a public address (ps_accounts, ps_eventbus, ps_metrics) with a tunnel such as ngrok.

PrestaShop Flashlight (the PrestaShop/prestashop-flashlight repository) is a separate Docker project that starts a shop within seconds with demo content and extra tools in the containers (phpMyAdmin, Composer, php-cs-fixer, phpstan, phpunit). Its examples cover installing modules automatically at startup, developing a module, developing PrestaShop itself, an ngrok tunnel and init or post-install scripts; the documentation lists the front office at port 8000, the back office at /admin-dev, and the e-mail admin@prestashop.com with the password prestashop. It is meant for local use only and is documented but was not run for these pages.

Source: PrestaShop devdocs: Docker and PrestaShop Flashlight

The shop’s root .htaccess is generated by the installer and by the back office (Shop Parameters > Traffic & SEO > SEO & URLs, in the "Set up URLs" block). From 9.2 you can regenerate it on the command line.

Source: PrestaShop devdocs: Changes in 9.2, prestashop:htaccess:generate

The first command printed ".htaccess already exists. Use --force to overwrite." and left the file alone; the second printed ".htaccess successfully generated at /var/www/html/.htaccess". The file records the domain in its rules (#Domain: localhost:8095 and one RewriteCond %{HTTP_HOST} per rule), which matters when you change the domain.

The virtual host must allow .htaccess files to be read and must have mod_rewrite enabled. This is the documented configuration for mod_php or PHP-CGI:

Source: PrestaShop devdocs: Apache Httpd

For PHP-FPM, enable alias, proxy and proxy_fcgi and route .php files with a handler such as SetHandler proxy:unix:/var/run/php/php-fpm.sock|fcgi://dummy; to keep HTTP Basic authentication (used by the Webservice) working with FastCGI, add SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1. The .htaccess that ships with the shop also passes the Authorization header to PHP and blocks composer.lock, .git* and .env*; the modules/.htaccess denies direct access to .php, .log, .txt, .lock, .json, .yml, .yaml, .tpl, .twig, config.xml and config_xx.xml files inside modules. On the Apache image, requests for /modules/ps_emailsubscription/ps_emailsubscription.php and for /composer.lock returned 403. The documentation’s two virtual hosts differ in one line: Options -Indexes for mod_php and Options +Indexes in the PHP-FPM example. Use -Indexes in both so that directory listings are never shown.

Nginx needs a complete configuration. The sample in the developer documentation is a good start but it is not complete, as the test below shows. This configuration was run with Nginx stable in front of the prestashop/prestashop:9.2.0-fpm image (PHP 8.5.12 FPM on port 9000), sharing the shop volume read-only with the Nginx container; admin504mbtgyopsqszuyouv is the admin folder that installer generated, and you must put your own folder name there.

Source: PrestaShop devdocs: Configure Nginx

The listing is the documented sample with the image rules shortened to the first rules (the documented sample repeats the product rule for every digit count up to eight digits), a Docker upstream name, no TLS and the two Added rules. The status codes the test shop returned through Nginx:

So the sample leaves module PHP files, module config.xml files and composer.lock reachable, where Apache with the shop’s .htaccess files refuses them. Since 9.0 calling a PHP file under modules/ directly is forbidden (a module must use a ModuleFrontController), the added rule is the Nginx equivalent. If the shop runs behind a TLS-terminating proxy or Cloudflare Tunnel, uncomment the sample’s fastcgi_param HTTPS and X-Forwarded-Proto handling so that PHP knows the request was secure; otherwise the back office will not show the "Enable SSL" switch (see below) and redirects can loop. The sample also contains commented security headers (HSTS, X-Frame-Options, X-Content-Type-Options); PrestaShop itself sends none of them and has no Content-Security-Policy support, so add the headers you want at the web server. Multi-language sites with one or two letter language prefixes need the extra rewrite lines kept in the sample.