The Merchant Engine compared with Saleor
Saleor is the enterprise-shaped answer: Python and Django, GraphQL only, apps and webhooks around a core you do not modify, and a cloud to run it on. The Merchant Engine is the small-team answer: TypeScript end to end, REST, one install that includes the admin and the storefront, and a codebase you change in place.
What Saleor does better
Saleor is nearly a decade old, its core API and dashboard are BSD-3-Clause, and its app and webhook architecture is more scalable than anything here. It has an official payment app catalogue that this project cannot match. If you need a platform with that operational history, Saleor is the safer pick.
Row by row
Every claim about Saleor was read from its own documentation on 2026-09-09 and carries the page it came from. Every claim about The Merchant Engine links the documentation page that proves it. If a row is wrong, it is a bug: write to bbadii@pm.me and it gets corrected.
| Criterion | Saleor | The Merchant Engine |
|---|---|---|
| What it is | An API-only, GraphQL-native platform for composable commerce. “GraphQL native, API-only platform for scalable composable commerce.” Source: github.com | A self-hosted ecommerce platform: a REST API, an admin dashboard and a server-rendered storefront, installed together on your own server with one command. Read the page that proves it |
| Language and runtime | Python on Django, pinned to Python 3.12. “requires-python = ">=3.12,<3.13"” Source: raw.githubusercontent.com | TypeScript on Node. NestJS and Prisma for the API, Angular for the admin, Analog.js for the storefront. Read the page that proves it |
| API | GraphQL only, stated as a design choice. “GraphQL only - Not afterthought API design or fragmentation across different styles of API.” Source: github.com | REST, one versioned surface under /v1, split by audience into a storefront and an admin OpenAPI document that are generated from the code, never hand-written. Read the page that proves it |
| Admin dashboard | An official dashboard in its own repository, deployed separately from the API. “A GraphQL-powered, single-page dashboard application for Saleor.” Source: github.com | Included and installed with everything else. Angular, role-based permissions on every endpoint, light and dark, and one editing tab per locale on every text field. Read the page that proves it |
| Storefront | A separate storefront repository, described as a production-ready template you build on. “A minimal, production-ready storefront template for Saleor.” Source: github.com | Included and installed with everything else, server-rendered, and branded from the store configuration rather than forked: colours, fonts, logo, locales and money come from the database. Read the page that proves it |
| Install path | No single command. The quickstart clones a platform repository and runs several Docker Compose steps. “docker compose run --rm api python3 manage.py migrate” Source: docs.saleor.io | One command. ./setup.sh asks for the store’s values, verifies each third-party integration live, builds the images, creates the database, issues the certificates and creates the owner account. Read the page that proves it |
| License | BSD-3-Clause for the core API and the dashboard. The current storefront is under FSL-1.1-ALv2, which restricts competing use for two years before converting to Apache-2.0. “an additional license to use the Software under the Apache License, Version 2.0 that is effective on the second anniversary” Source: raw.githubusercontent.com | Source available: PolyForm Noncommercial 1.0.0, free for personal, educational, research and nonprofit stores. A store that takes money buys a yearly commercial license in one of four tiers. Read the page that proves it |
| Hosting model | Self-hosted or Saleor Cloud, which the vendor's own site promotes. “You build. We infra.” Source: saleor.io | Self-hosted only. There is no vendor cloud, no hosted tier and nothing to sign up for; the install runs on your box and the licence check is an offline signed file. Read the page that proves it |
| Extension model | Apps and webhooks: extensions run as separate services around the core, with UI mount points in the dashboard. “Extend Saleor's default flows through external services with synchronous webhooks.” Source: saleor.io | You own the checkout: it is a modular monolith you change in place, with a documented recipe per kind of change and the gates that keep the change honest. Read the page that proves it |
| Payment providers | An official app catalogue with Adyen and Stripe among others, authored by the vendor. “Repository: [GitHub](https://github.com/saleor/apps/tree/main/apps/stripe)” Source: docs.saleor.io | Cash on delivery, manual bank transfer and gift cards ship and work. No card gateway ships in the first release; the payments module has the seams and a recipe for adding one. Read the page that proves it |
| Cash on delivery | No official cash-on-delivery app was found in the app store or the payment documentation read on this date; it is an open community request. “Cash on delivery - Allow creating orders with the payment status of `NOT_CHARGED`” Source: github.com | Shipped. A payment method row the store owner switches on, published by the public checkout endpoint with its translated name, and snapshotted onto the order. Read the page that proves it |
| Content languages | Translations of catalogue data and of the storefront application are both documented. “Translating the storefront application. Translating the products catalog and other data returned by the API.” Source: docs.saleor.io | French, English and Arabic catalogues ship. A store enables the ones it serves and picks a default; every user-facing field holds one value per locale in one database. Read the page that proves it |
| Right to left | Right to left is not mentioned on the internationalization guide read on this date. A storefront you build yourself can mirror regardless. Searched, not stated: docs.saleor.io | The storefront mirrors: the store configuration names the RTL locales and the pages set dir and lang per locale. The admin edits Arabic in a right-to-left tab, but its own interface is English and is not mirrored. Read the page that proves it |
| Infrastructure | PostgreSQL, configured by connection URL. “The connection URL to a PostgreSQL database.” Source: docs.saleor.io | PostgreSQL and Redis, in Docker, on one Linux box. The installer sets both up; a second box for the storefront is optional. Read the page that proves it |
| Maturity | First released in 2016, on major version 3. “The initial release” Source: github.com | The youngest product on this page, and the page says so: the first public release is not tagged yet. What stands in for a version history is the gate set every push runs, published rather than described. Read the page that proves it |
Which one to pick
Pick Saleor when
- You want GraphQL and an app architecture where extensions are separate deployable services.
- You are staffing a Python team, or already run Django in production.
- You need a vendor cloud with compliance paperwork behind it.
- You want an official catalogue of payment apps rather than writing a provider.
Pick The Merchant Engine when
- You want one install that puts the API, the admin and the storefront on a box, not three deployments to wire.
- Your team is TypeScript and you would rather read one language across the stack.
- Cash on delivery is a requirement, not a gap to close.
- The store serves Arabic and French, and the storefront has to mirror without extra work.
Questions
Is Saleor free to use commercially?
The core API and the dashboard are BSD-3-Clause, which permits commercial use. The current storefront repository is under a source-available licence with a two-year competing-use restriction, so read that one separately before forking it.
Why REST instead of GraphQL?
Because the audience here is a developer who wants to ship a store, not design a schema. Every route is documented, the OpenAPI documents are generated from the code, and there is an HTTP file and a Postman collection to run them.
Can Saleor do cash on delivery?
Nothing prevents it: you can build an app that marks an order unpaid until delivery. What is missing is an official one, which is why the row above says no rather than never.
See it for yourself
The fastest check on any row above is to run the thing: install it locally in one command, or read what an install puts on a box. The other comparisons are on the compare index.
Last updated . Every claim on this page is read from a published source and cited beside it.