Saleor

Saleor is an e-commerce platform built for developers who want to construct an online store from parts rather than buy one pre-assembled. It is open source, meaning the code is public and free to inspect, run, and modify, and it is headless, meaning it provides only the commerce back end — products, carts, orders, payments, and checkout logic — through an application programming interface, leaving the storefront that customers actually see for developers to build separately. Saleor is GraphQL-first. It exposes its data through a GraphQL API, a query language that lets a front end ask for exactly the data it needs in one request. Around that core sit an admin dashboard for running the store and support for selling across many channels, from web to mobile and beyond. It is a commerce engine, not a finished shop.

This design suits a particular kind of builder. Because Saleor decouples the back end from the front end, a team can pair it with any framework or device and craft a completely bespoke shopping experience, then swap the front end later without rebuilding the commerce logic underneath. Being open source, it avoids licence lock-in and keeps a company's data in its own hands. Saleor is often described as part of the MACH and composable-commerce movement — the idea of assembling a store from best-of-breed, API-connected services instead of one monolithic suite. The trade for that flexibility is engineering effort. Saleor gives developers control and freedom, but it expects them to build and maintain the storefront and integrations that a hosted platform would hand over ready-made, which is a serious, ongoing commitment rather than a one-time setup.

The sharpest way to understand Saleor is against Shopify, and the contrast is nearly total. Shopify is a hosted, all-in-one platform. You sign up, pick a theme, add products, and Shopify runs the servers, security, checkout, and updates while giving you a working store the same day. It is closed-source and opinionated, trading flexibility for speed and simplicity. Saleor is the opposite bet. It is open-source and headless, so nothing about the storefront is decided for you. You build it. There is no drag-and-drop theme and no one hosting it by default, and that is the point. Shopify optimises for a merchant who wants to sell quickly without a developer. Saleor optimises for an engineering team that wants total control over how commerce behaves and looks, and is willing to build to get it.

Neither is simply better. They answer different questions. A small merchant who needs a store this week and has no developers should almost certainly choose a hosted platform like Shopify, because Saleor's freedom is useless without the engineering to wield it. A large brand with a specialist team, unusual requirements, or a need to avoid vendor lock-in may find Shopify's guardrails constraining and reach for Saleor's open, composable core instead. The honest framing is a trade between control and convenience. Saleor gives you the keys to everything and the responsibility for everything, while Shopify keeps the keys and the responsibility and hands you a working shop. Choosing wrongly — Saleor without engineers, or Shopify when you truly need deep customisation — is where teams waste the most time and money.

Saleor makes sense when a team has real engineering capacity and a genuine reason to customise. Good candidates include brands with complex catalogues, unusual checkout or pricing logic, multiple sales channels to unify, or a strategic aversion to being locked into one vendor's roadmap. Using it well means treating it as the commerce core in a composable stack — connecting it by API to a chosen front-end framework, payment providers, search, and content tools — and investing in the front end and integrations that turn the engine into a shopping experience. Because the code is open, teams can extend it through its documented mount points and apps rather than forking it. The discipline is to exploit the flexibility deliberately, building only the custom experience that actually differentiates the business rather than reinventing commerce basics for their own sake.

The clearest failure is choosing Saleor for the wrong reasons. A team with no developers, or one that just needs a standard store, will find its openness a burden rather than a gift, because someone still has to build and maintain the storefront, hosting, and integrations a hosted platform provides automatically. Underestimating that ongoing engineering cost is the common trap. Others treat headless commerce as a fashion rather than a fit, adopting a composable stack they do not need and paying in complexity. And confusing Saleor's model with a hosted, closed platform leads to mismatched expectations on both sides. Saleor rewards teams that want and can afford control. It punishes those who wanted convenience and picked it by reputation rather than requirement, then discovered the storefront was theirs to build.

Saleor began as an open-source project from the software company Mirumee and grew into a GraphQL-first, headless commerce platform for building custom online stores.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where saleor is a core concern: