Saleor 3.x is a commerce backend, not a complete shop in one repository
Saleor 3.x puts product catalogs, carts, orders, customers, promotions, payments, translations, and channel-specific inventory behind GraphQL. The API-only design lets a storefront, dashboard, or business application use the same commerce rules. Multichannel controls reach pricing, currencies, stock, and products, which is useful when one company sells across regions or brands. The BSD-3-Clause license permits commercial use, and the README says the open version is not divided into paid feature tiers.
That freedom comes with a wide codebase. Our checkout contained 4,669 files, about 851,431 lines of source, and occupied 59.3 MB before installation. The dashboard and example storefront live in separate repositories, so this core does not give a shopper or merchant a usable screen by itself. Saleor Platform assembles the API, dashboard, database, cache, tracing, and test email service for local work. Its README explicitly says that combined stack is not meant for production deployment.
The 3-component split favors staffed commerce teams
The README names 3 production components: Saleor core, the dashboard, and the storefront. Custom behavior runs through apps, webhooks, metadata, subscription queries, API extensions, or dashboard iframes. Deploying extensions separately can isolate failures and let each service scale on its own. It also turns a checkout rule or payment connection into another deployable unit, with its own authentication, monitoring, and release process. That is a sensible trade for a company that changes commerce logic often.
A competent solo developer may still walk away. The project says the service-oriented approach can feel more complex for a small business without high traffic or round-the-clock availability needs. Our 13-second npm install added 272 packages, yet it did not assemble those 3 components or start a store. WordPress, a hosted platform, or a framework kept inside one application can be easier to own when separate scaling and daily backend deployments solve problems the business does not have.
What happened when we ran it
Our sandbox run at commit 0a11eb9 installed 272 npm packages in 13 seconds and used 69 MB on disk. The fresh Debian container had 3 CPUs and 8 GB of RAM, with no secrets. Npm audit reported 0 known vulnerabilities across the installed packages. Installation therefore succeeded for the Node/npm surface detected by the harness, and the log did not report a package failure.
The next steps did not run. There was no build script or target, so the harness skipped the build. There was also no test script or target, so it skipped tests rather than recording a pass or failure. The repository signal scan counted 22 CI workflow files and a Dockerfile, but no top-level tests directory. Saleor's contribution guide separately documents pytest suites inside application folders; our measurement does not provide a result for those Python tests.
The distinction matters more here than it would in a small Node package. GitHub identifies Python as the primary language, and the development guide uses uv, Django commands, PostgreSQL-backed migrations, and Celery processes. A successful 13-second npm step is useful evidence about release or support tooling, but it is not evidence that checkout, payment, or order behavior worked. Buyers should demand their own end-to-end store test before treating the sandbox result as deployment proof.
Python 3.12 development needs supporting services and configuration
The current contribution path specifies Python 3.12 and starts the database, dashboard, cache, and Mailpit with Docker Compose. Developers then run uv sync, create a .env file from the example, apply migrations, and populate sample data. The API starts separately from the Celery worker and optional scheduler. Libmagic is another named prerequisite. None of that is unusual for a mature Django system, but it is materially more work than installing the 272 npm packages our harness saw.
Hosted Saleor Cloud avoids much of that local operations burden and is the README's fastest route to development. Self-hosting shifts the decisions back to the team: database backups, Redis availability, worker supervision, object storage, email, payment credentials, webhook delivery, and secret rotation all sit around the core. Saleor Platform can teach the service relationships, yet its local-only warning means operators cannot treat its Compose file as a ready production architecture.
September 2026 activity is strong, with 249 issues and PRs to sort
GitHub showed 23,297 stars and 249 combined open issues and pull requests when fetched. The last push was September 4, 2026, and release 3.23.31 arrived on September 2. Four other releases appeared between August 20 and September 1. Those dates point to active maintenance rather than a repository living on reputation. The combined open count is not a defect count, so it should be read as workload and participation, not as 249 known bugs.
Current issue activity still reveals operational gaps worth testing. Issue 19739 reports that Celery task execution, failures, and queue depth are absent from the metrics, which could hide a worker outage while the HTTP API stays healthy. Issue 19429 asks for translated product-media alt text because the field currently has one global value. Neither report cancels Saleor's broad commerce coverage. Both show why a serious evaluation should map required observability and localization behavior against the exact 3.x release.
The 13-second install earns a trial, not a production shortcut
Saleor makes the most sense when GraphQL is a deliberate platform choice and a team can own separate storefront, dashboard, worker, data, and integration services. Its active 3.x release line and wide commerce model justify a proof of concept for multichannel or frequently changing businesses. Our run leaves one large question open because no build or tests ran: the buyer still has to validate the Python system and a representative checkout flow. Smaller teams should value the README's warning and choose less architecture unless they need what that architecture buys.