What is Saleor?

Saleor is an open-source headless commerce platform. Its core, Saleor Core, is a GraphQL API written in Python on Django, and the saleor/saleor repository describes it as a composable, headless commerce API. According to the README, APIs are the only way to interact with, configure or extend the backend: there is no template or theme layer inside Core, and storefronts, back-office tools and integrations are separate clients. The project is developed by Saleor Commerce, which also operates the hosted Saleor Cloud service. The LICENSE file lists copyright holders Saleor Commerce (2020 to 2023) and Mirumee Software (2010 to 2020), and the GitHub repository dates from February 2013.

A Saleor installation has three documented parts. Saleor Core provides the API, background workers and a periodic task scheduler. The Saleor Dashboard is a GraphQL-powered single-page admin application in TypeScript, also under BSD-3-Clause. The Saleor Storefront is an example storefront built with Next.js App Router, React, TypeScript, GraphQL and Tailwind CSS. The README states that 3.x is the production-ready line for all three components, and the Docker image docs state that Dashboard minor versions match Core, so Dashboard 3.23 pairs with Core 3.23. The main branch is the development version; its pyproject.toml currently carries 3.24.0-a.0 and requires Python 3.12 and Django 5.2.

Distribution follows two paths. For self-hosting, Saleor publishes Core and Dashboard images on GitHub Container Registry (ghcr.io/saleor/saleor and ghcr.io/saleor/saleor-dashboard), and the Docker images page calls Docker the preferred deployment method. The separate saleor-platform repository runs Core, Dashboard, PostgreSQL 15, Valkey 8.1, a Celery worker, Jaeger and Mailpit with Docker Compose for local development only. Saleor Cloud is the managed option; according to the regions page, its environments run on AWS in Ireland (eu-west-1) or N. Virginia (us-east-1), with secondary regions in France and Ohio for disaster recovery.

The latest release is 3.23.48, published November 10, 2026, which fixes product filters that generated SQL causing PostgreSQL to scan the whole catalogue. 3.23.47 upgraded Django to 5.2.19 and the OAuth libraries for security patches. 3.23.46 added filtering of product variants by externalReference, ported OpenTelemetry autoinstrumentation and added the app_list, app_set_active and webhook_set_active management commands. 3.23.45 fixed several OIDC issues, and 3.23.44 upgraded certifi to revoke a compromised certificate. The 3.22 line still receives patch releases such as 3.22.77. The unreleased 3.24 changelog removes deprecated legacy payment plugins (Authorize.Net, Razorpay, Braintree and Dummy), removes the Sendgrid email plugin and limits bulk delete mutations to 100 IDs per call by default.

Saleor Core is licensed under BSD-3-Clause. The README states that there is a single version of Saleor without feature fragmentation or commercial limitations. Self-hosted instances send anonymous, aggregate usage telemetry at most once a day by default (Saleor version, object counts, currencies and installed apps, no customer or order data); it is turned off with SEND_USAGE_TELEMETRY=false. The README also notes that the service-oriented approach can feel more complex than WordPress or Magento for a single developer with a small, low-traffic shop. Other open-source commerce backends listed on iThub include Medusa and Bagisto.

Inside the application

Saleor screenshots

Explore the interface. Open a screenshot to view it at full size.

View full size ↗

Saleor screenshot 1

Saleor Dashboard order view from the saleor-dashboard README, with navigation for catalog, fulfillment, discounts, modeling, translations and extensions, shown with sample store data.

View full size ↗

Example storefront

Official image of the Saleor Storefront from the saleor/storefront README: mobile product grid, product page with discounted variants and step one of checkout.

View full size ↗

Channel data model

Official diagram from the Saleor channels documentation showing which objects relate to a channel and their cardinality.

View full size ↗

Dashboard payments and availability

Dashboard image from the saleor/saleor README: an order with payment balance, captured transactions per payment app and product availability across channels, shown with sample data.

Source: official Saleor project page.

Key capabilities

GraphQL API Saleor Core exposes one GraphQL API for storefronts, the Dashboard and apps; the README describes it as GraphQL only, without a second API style. The API reference documents queries, mutations, objects and enums per domain, and the docs cover authentication, filtering, pagination, metadata, translations and usage limits. The current Dashboard includes a Playground entry for running queries.
Channels for markets and brands A channel models a region, brand or business model inside one backend instance. Each channel has a single currency and its own variant prices, product visibility and publication dates, warehouses, shipping zones and rates, tax settings, payment flow settings and permission groups. Products and other shared objects can belong to several channels.
Product catalog and attributes Products are built from product types, attributes, variants, categories and collections, with media and SEO fields, and the README describes a rich content model for large catalogs. The catalog is fully translatable, and objects carry public and private metadata that apps can read and write. From 3.24, attribute mutations require the permission matching the attribute type.
Warehouses and stock Stock records link each variant to a warehouse and return quantity, allocated and reserved amounts. Every warehouse is assigned to one or more channels. A warehouse can act as a click-and-collect point in LOCAL_STOCK or ALL_WAREHOUSES mode, and stock webhooks cover out-of-stock, back-in-stock and quantity changes.
Checkout The checkout API holds lines, addresses, shipping method and promo codes, scoped to a channel. In the unreleased 3.24, checkoutCreate can create a checkout without lines. Shipping methods and taxes can be supplied by apps through synchronous webhooks.
Orders and fulfillment The order model supports draft orders created by staff, fulfillments, returns and refunds, order expiration and several payments per order; the README lists split payments, multi-warehouse orders and returns. Order data is scoped to channels, and staff access to it is controlled through channel permissions.
Payments through the Transaction API and apps Saleor acts as middleware between the storefront and a payment app, so the storefront does not call the provider directly. The payments docs describe the Transaction API for custom flows and refunds, and name Adyen and Stripe integrations; the App Store docs also include an NP Atobarai app and a Square app, which requires Saleor 3.23 and is not publicly available yet. Several legacy payment plugins are removed in 3.24.
Promotions, vouchers and gift cards Discounts come as catalogue promotions (line level), order promotions (subtotal or shipping), vouchers entered as codes, manual discounts by staff and gift cards. Values are fixed or percentage. Vouchers are scoped to channels, while gift cards are created per currency and work across channels with that currency.
Taxes Tax configuration is set per channel, including the calculation method, gross or net prices and country exceptions. Tax calculation can be delegated to an app through a synchronous tax webhook; the documented app integrations include AvaTax.
Webhooks Webhooks are asynchronous (sent after a request) or synchronous (sent during a GraphQL request, for payments, shipping and taxes). Payloads are defined with GraphQL subscription queries and signed with HMAC in the Saleor-Signature header. Each request has a 20 second limit, a webhook may define up to 5 custom headers, and webhookDryRun previews asynchronous payloads.
Apps Apps are technology-agnostic services that talk to Saleor through the API and webhooks, installed from a manifest with their own permissions and tokens. Saleor provides a Next.js App Template, app examples and the App SDK. The App Store with one-click installs is a Saleor Cloud feature; self-hosted users install apps manually, and the docs state that most Saleor Apps are open source.
Dashboard extensions Apps add buttons, menu items, pages and widgets to the Dashboard without forking it, declared in the manifest extensions array. Targets are POPUP, APP_PAGE, NEW_TAB and WIDGET, and contributed views run in an iframe. Saleor 3.23 added home page widgets and 3.23.21 added a command palette action mount.
Saleor Dashboard The admin covers catalog, orders and drafts, customers, discounts, modeling, translations, extensions and configuration, with a command menu. It is a static single-page app; development needs Node.js v24 and pnpm. A Docker image is available, while the docs recommend static hosting such as S3 with CloudFront or Vercel, pointed at the API through API_URL.
Example storefront The storefront quickstart clones saleor/storefront, installs dependencies with pnpm and sets NEXT_PUBLIC_SALEOR_API_URL to the GraphQL endpoint. The checkout is built as a standalone component that can be reused in other React apps, and a draft endpoint bypasses Next.js caching. A public demo runs at storefront.saleor.io.
Configurator Saleor Configurator keeps store configuration in a YAML file that can be versioned in Git. It runs with npx @saleor/configurator on Node.js 20 or later with an app token, and provides introspect, diff and deploy commands plus recipes. Documented entities include channels, warehouses, shipping zones and product types.
Local development stack The Docker Compose guide uses saleor-platform: docker compose run --rm api python3 manage.py migrate, optional populatedb sample data, createsuperuser and docker compose up. The API listens on port 8000, the Dashboard on 9000, Jaeger on 16686 and Mailpit on 8025. Docker Desktop on macOS and Windows needs at least 5 GB of memory, and the repository is for local development only.
Self-hosted production setup Core runs from one image as api, a Celery worker and a Celery beat scheduler. The architecture page shows horizontally scaled web and background workers, a PostgreSQL writer with read replicas, separate Redis cache and queue, and S3 or Google Cloud Storage for media. Configuration uses environment variables: RSA_PRIVATE_KEY is required in production, and ALLOWED_CLIENT_HOSTS is required when DEBUG is false. The Kubernetes page lists community-maintained Helm and Kustomize resources only.
Observability Saleor emits OpenTelemetry spans; 3.23.46 ported autoinstrumentation to the stable line, and the 3.24 changelog adds instrumentation for psycopg, Celery, Redis and botocore controlled by TELEMETRY_INSTRUMENTORS. The docs also include a Sentry monitoring guide, and the saleor.io site lists OpenTelemetry observability as Beta.
Saleor Cloud and CLI Saleor Cloud runs Saleor on managed, auto-scaling infrastructure. The README describes developer accounts and the Saleor CLI: npm i -g @saleor/cli, saleor register and saleor storefront create --url with a GraphQL endpoint. The pricing page lists PCI DSS, SOC 2 and GDPR compliance.
Saleor Cloud plans The pricing page lists Sandboxes as free and for non-commercial use only, Select at $1,599 per month up to $200,000 monthly GMV with a 0.8% fee above it, Volume at $3,999 per month up to $1,000,000 monthly GMV with a 0.4% fee, and a negotiable Enterprise plan. Optional one-time add-ons are an Accelerator Plan and Forward Deployed Engineering. The page states that merchants can move between Saleor Cloud and self-hosted Saleor.

Where Saleor fits

Running several markets from one backend

Each market, brand or sales model is set up as a channel with its own currency, prices, product availability, warehouses, shipping zones, tax configuration and payment settings. Storefronts query the API with a channel slug and receive the prices, stock and products of that channel, while staff permission groups restrict which channels' orders a user can see. The multi-region recipe covers this setup.

Building a headless storefront

Any frontend that can send GraphQL requests can act as the storefront. Saleor's own example is the Next.js storefront, configured through NEXT_PUBLIC_SALEOR_API_URL, with GraphQL types regenerated by pnpm run generate. The same API serves other clients such as mobile apps or a Next.js site, since Core has no rendering layer of its own.

Accepting payments through payment apps

The storefront asks Saleor to initialize and process a transaction, and Saleor forwards the request through synchronous webhooks to the installed payment app, which talks to the provider. Documented apps include Adyen and Stripe, with a Square app limited to a small group of customers so far. Backend systems that record payments elsewhere can write transactions to orders through the Transaction API.

Extending the back office with apps

Custom logic, such as tax, search, emails or product feeds, runs in an app deployed separately from Core. The app declares its permissions, webhooks and Dashboard extensions in a manifest, receives events as signed webhook payloads shaped by subscription queries, and can show its own screens inside the Dashboard as pages, popups or widgets. Saleor Cloud adds one-click installs from the App Store.

Multi-warehouse fulfillment and click-and-collect

Stock is kept per warehouse and variant, and warehouses are assigned to channels. Order lifecycle events allocate and release stock, and stock levels are reported per warehouse. A warehouse can serve as a pickup point using its own stock or the combined stock of the channel, as described in the click-and-collect recipe.

Managing store configuration as code

Configurator exports an instance's channels, warehouses, shipping setup and product types to YAML with introspect, shows pending changes with diff and applies them with deploy. The documented purpose is to track changes in Git, review them in pull requests and repeat them across environments, with the Configurator release matched to the Saleor version.