Saleor Storefront

Last reviewed Sep 13, 2026 · 831 words

Saleor Storefront sells nothing on its own. It is a Next.js application that renders products, cart and checkout by calling a Saleor GraphQL API, so the first line of any self-hosting plan is "and also run Saleor Core with PostgreSQL, plus the Saleor Dashboard for administration". Budget for that full stack, roughly 2 GB of RAM across three services in practice, and the storefront's own 512 MB is the small part. What you get for the effort is a headless commerce setup on a modern React stack, MIT-licensed, and a reference implementation that Saleor's own team keeps current with their API.

What the reference build ships

The repository is a working shop, not a component library: product listing and detail pages, search, collections, a cart, a multi-step checkout with address and shipping selection, and order confirmation, all server-rendered through the Next.js App Router with GraphQL types generated from the Saleor schema. Payments are handled by Saleor apps installed on the backend, Stripe and Adyen being the maintained ones, and the storefront's checkout renders whatever gateway the API reports. Customer accounts, discounts, multi-channel pricing and multi-currency all come from Core; the storefront just displays them. That division is the whole architecture. If a feature is missing from the storefront, the question is always whether it is also missing from the API, because adding it to the front end is the easy half.

Configuration is two environment variables and a channel

The storefront reads NEXT_PUBLIC_SALEOR_API_URL for the GraphQL endpoint and NEXT_PUBLIC_STOREFRONT_URL for its own public address, which checkout redirects and payment callbacks need to be correct. Channels, Saleor's mechanism for separate markets or currencies, are selected by slug in the URL, so a fresh Core install with the default-channel channel works out of the box. Build with the project's package manager and run the production server behind your reverse proxy:

pnpm install
pnpm run generate   # regenerate GraphQL types against your API
pnpm run build
pnpm start          # listens on 3000

Run the generate step whenever you upgrade Core, because the storefront's queries are compiled against a specific schema version and a mismatch fails at build time rather than silently at runtime, which is the good kind of failure.

Hosting it yourself versus the Vercel path it was built for

The storefront is designed around Next.js features that Vercel makes easy, incremental static regeneration and edge caching among them, and Saleor's own documentation leans on Vercel for the front end and Saleor Cloud for the API. Self-hosting is fully supported but means a Node process you keep alive and a cache you own. Put it in a container, give it a health check, and terminate TLS at Caddy or whatever fronts the rest of your stack. Expect to pin Node and pnpm versions to whatever the repository's lockfile expects; this is a moving codebase and the "requires customization for production" con in the catalogue is partly about that churn.

It is a starting point, not a theme

Nobody runs the reference storefront unmodified past the first week. The branding, the product page layout, the category structure and usually the checkout copy all change, and because the code is yours, they change by editing React components rather than through a theme system. That is either the point or the problem. A developer comfortable with TypeScript and GraphQL will find it a clean base; a shop owner who wants to pick a template and upload a logo has picked the wrong tool, and WooCommerce or Bagisto will get them trading sooner.

Where Medusa and WooCommerce fit

Medusa is the closest rival: also headless, also a Next.js starter storefront, with the backend in Node rather than Python, which keeps the whole stack in one language for a JavaScript team. Saleor's advantages are a more mature multi-channel and multi-currency model and a GraphQL-only API that is consistent end to end. WooCommerce is the monolith that needs no separate front end and has every plugin ever written. Anyone escaping Shopify Hydrogen will feel at home in Saleor's storefront, since both are React front ends over a commerce API; the ecommerce category covers the rest of the field.

What I'd do

If I had a developer, a catalogue that needs multiple currencies or markets, and a reason to own the front end, I would run Saleor Core and Dashboard in Docker on one host, this storefront on the same host behind Caddy, and fork the repository on day one so upstream changes could be merged deliberately. If I did not have a developer, I would not run a headless commerce stack at all, and WooCommerce on a managed PHP host would be the honest answer. Saleor Storefront is a fine reference for people building a shop and a poor product for people who want one.