PrestaShop: What the Repository Actually Gives You

Who PrestaShop is for, and who it is not for

PrestaShop solves a specific problem: running a storefront on infrastructure you control, in a language most hosting providers already support. The README describes it as an open source e-commerce web application written in PHP, with a responsive front and back office, support for major payment services, and translations and localization for many countries. That combination matters if you want to self-host, if you want to modify the checkout or catalog code directly, or if you already run PHP and MySQL and do not want to add a new runtime.

The audience is narrower than the tagline suggests. The repository README says the source code here is intended for development and preview only, and points anyone installing a production shop to the releases page. So the GitHub repository is not the distribution channel for merchants. It is the channel for people building modules, themes or core patches, and for people who want to run the next version before it ships. A merchant who clones this repository and points a domain at it is using it against the README's own instruction.

The branch and release model you have to understand first

PrestaShop's versioning is the part most likely to trip up a new adopter. The README states that the develop branch contains work in progress for the next version, and at the time of writing it says that branch is exclusively for version 9.1. Meanwhile the repository lists 9.2.0-rc.1, 9.1.5 and 8.2.8 as recent releases. Those are three different things: a release candidate, a stable 9.1 line, and a maintained 8.2 line.

The practical consequence is that "PrestaShop" is not one artifact. If you want a stable shop, you take a stable release. If you want to test what is coming, you take the release candidate. If you want to work on the codebase, you work on develop, and you accept that develop is not a release. The README links a guide on the branch system rather than explaining it inline, which is a fair sign that the project expects contributors to read it before opening a pull request.

The last push to the repository was on 2026-09-21, and 9.2.0-rc.1 was published the same day. That tells you the project is moving, but it does not tell you which line you should run. That decision is yours, and it depends on whether you are shipping a store or testing one.

Getting a development shop running with the Docker environment

The README provides a complete Docker-based development environment, and this is the shortest path from a clone to a working back office. The Makefile defines docker-start as a build followed by an up, so a single target does both.

make docker-start

After the containers come up, the README lists three endpoints: the frontend at http://localhost:8001, the back office at http://localhost:8001/admin-dev, and a mail catcher at http://localhost:1080. The default admin credentials given in the README are [email protected] with the password Pr3st4Sh0P.

The compose file binds port 8001 to the container's port 80 and 8002 to 443, and starts a mysql:8.4 service alongside the application. The application service waits on mysql:3306 before running its startup script, with a 60 second timeout and strict mode, so a slow database start fails the container rather than silently continuing.

If you want different credentials, the README shows exporting them before compose starts.

export [email protected]
export ADMIN_PASSWD=Your-Secure-Password
docker compose up

The same environment variables are visible in docker-compose.yml, including PS_INSTALL_AUTO, PS_DOMAIN, PS_FOLDER_ADMIN, PS_DEV_MODE and PS_USE_DOCKER_MAILDEV. The README also documents a behaviour worth knowing before you debug a missing install screen: the container checks that app/config/parameters.php does not exist on startup, and if you want it to reinstall the shop you remove that file. It adds that the container user www-data needs write access to the whole workspace.

The auto-install check is the first thing that will confuse you

The parameters.php check is a real failure mode, not a footnote. The container decides whether to install based on the absence of a file, so a shop that was installed once and then had its containers recreated will not reinstall, and the frontend may serve an error instead of a setup wizard. The README's instruction is explicit: remove app/config/parameters.php if you expect a reinstall.

The second constraint in the same paragraph is file ownership. The README says the container user www-data must have write access to the whole workspace. On Linux hosts where the bind mount is owned by your desktop user, that is not automatic, and the compose file exposes USER_ID and GROUP_ID build arguments defaulting to 1000. If your local user ID is not 1000, the defaults will not match, and write failures during install are the symptom to expect.

Neither of these is documented as a troubleshooting section. They appear as notes inside the Docker quick start, which means you meet them in the middle of a failed install rather than before it.

Server requirements and where the install guides actually live

The README states that installing the latest PrestaShop 9.0 needs a web server running PHP 8.1 or newer and any flavor of MySQL 5.6 or newer, including MySQL, MariaDB and Percona Server. It also notes you need a database administration tool such as phpMyAdmin to create the database, and recommends Apache or Nginx, linking an example Nginx configuration file.

Those numbers are the floor, not a tested configuration. The README points to a system requirements page and a system administrator guide for more detail, and the Docker image in the compose file is built from a VERSION argument defaulting to 8.1-apache, which is the PHP version rather than the PrestaShop version. That naming collision is easy to misread when you are scanning the file for the PrestaShop release.

The README separates two install paths clearly. If you downloaded the source from GitHub, you read the development install guide. If you intend to run a production shop, you download the latest version from the releases page and follow the user install guide. There is also an INSTALL.txt file at the repository root, and the README does not describe its contents, so treat it as a secondary source behind the linked guides.

What you give up compared with a hosted storefront

The honest comparison is with a hosted platform such as Shopify, which the related searches show people ask about directly. The difference is not features, it is who operates the stack. A hosted platform runs the servers, the upgrades and the payment integrations for you, and you trade control and a monthly fee for that. PrestaShop gives you the code, the database and the upgrade responsibility.

That trade shows up in the upgrade path. The README links an updating guide and warns that switching to the newest version is not trivial, which is a candid statement from the project itself. A self-hosted shop means you own the PHP version, the MySQL version, the module compatibility matrix and the rollback plan. The README does not document a rollback procedure, and the repository does not ship one.

The second difference is the module ecosystem. PrestaShop has an addons marketplace, and the related searches include addons, themes and marketplace. Modules are how most stores get functionality the core does not include, and module compatibility is something you verify per release rather than assume. If you are not prepared to test modules against a new minor version before upgrading a live shop, a hosted platform removes that work by removing your control over it.

Licence, contribution and the cost of staying current

The repository's licence field is reported as NOASSERTION, and the root contains a LICENSE.md alongside a .header-stamp-osl3-license.txt file and a header-stamp configuration. The OSL 3.0 name in that tooling file points toward the Open Software License, but the repository metadata does not assert a licence identifier, so read LICENSE.md directly before you rely on any particular licence. This is not legal advice, and if you plan to redistribute PrestaShop or ship it inside a product, that is a question for a lawyer rather than a README.

The maintenance cost is visible in the repository structure. There are PHPStan configurations including a baseline and a legacy layout baseline, a PHP CS Fixer config, a Rector config, and separate Makefile targets for unit, integration, behaviour and API module tests. That is a codebase with an enforced quality gate, which is good for contributors and also means a local patch that ignores the coding standard will not survive review.

Contributions go through CONTRIBUTING.md, with good first issue labels for newcomers and Crowdin for translations. The README also asks that AI coding tools read .ai/CONTEXT.md, and the repository root carries AGENTS.md, CLAUDE.md and GEMINI.md along with .claude/, .cursor/ and .windsurf/ directories. Whatever you think of that convention, it is now part of the repository layout you inherit.

Editorial conclusion

Adopt PrestaShop if you want a PHP storefront you host yourself and can extend with modules, and if you are comfortable running the repository through its Docker environment rather than dropping the GitHub source onto a production server. Do not adopt it if you need a managed SaaS storefront with no server work, or if you expect the develop branch to be a stable release. Before committing, verify your PHP and MySQL versions against the system requirements page, confirm which release line you are installing (9.1.5, 8.2.8, or the 9.2.0 release candidate), and check the licence file in the repository rather than assuming a specific open source licence.

Frequently asked questions

Official sources

1. Issues
2. PrestaShop/PrestaShop on GitHub
3. Project website
4. README
5. Releases