Saleor vs Vendure: which to choose

Saleor vs Vendure: when each one fits

Choose Saleor when your team wants a BSD-3-Clause core, works comfortably in Python and Django, and needs commerce features such as per-channel pricing, multi-warehouse fulfillment, multi-gateway payments, split payments and returns. Saleor extends through webhooks, apps and metadata rather than in-process plugins, which suits teams that want their customizations to sit outside the core. Choose Vendure when your developers are strong in TypeScript and NestJS, you expect to write plugins that extend or override services and strategies inside the application, and your roadmap includes B2B features such as company accounts, quotes, contract pricing and approvals. Those B2B features sit in Vendure's paid Starter, Growth, Scale and Enterprise plans, so budget for them from the start.

The decision turns on four questions. First, which language your engineers will maintain for the next several years, because both platforms are self-hosted and every upgrade and custom extension will be written in that stack. Second, how much B2B logic you need on day one. If quotes, approvals and contract pricing are core requirements, Vendure's paid tiers become part of the cost model. Third, licensing comfort. Vendure's core is GPLv3 unless you hold a commercial agreement under the Vendure Commercial License, and Vendure's plugin exception allows plugins to be distributed under a different license. Have legal confirm how your own modifications and distribution would be treated under the GPLv3 terms before you commit. Fourth, whether you intend to keep the core unmodified. Saleor's webhook model is designed to keep customizations outside the core, while Vendure's plugin model can reach deeper into the application.

Before you shortlist either platform, run a short proof of concept against your hardest workflow, such as a multi-warehouse order with a split payment and a return. Confirm the current version and its support window in the Saleor GitHub releases and the Vendure releases pages, and confirm which B2B features your edition includes by asking Vendure directly. Ask both vendors and your implementation partner what a fixed-scope quote covers, including the environments, the upgrade path and who owns the webhook apps or plugins after handover.

Which platform fits which commerce scenario

This table maps common commerce scenarios to the platform that fits each one better, with the supplied facts behind the choice. Read each row as a starting point, then test it against your own catalog, channels and team skills before deciding. Rows that depend on Vendure's paid plan contents need confirmation with Vendure before you rely on them.

Scenario	Better fit	Why
D2C brand with multi-warehouse fulfillment	Saleor	Saleor supports per-channel pricing, currencies and stock across multiple warehouses, with returns and split payments included in the core API.
Multiple payment gateways and complex promotions	Saleor	Saleor includes multi-gateway payment support and a promotion engine with sales, vouchers, cart rules and gift cards.
B2B wholesaler needing company accounts and contract pricing	Vendure, if on a paid plan	Vendure's paid Starter, Growth, Scale and Enterprise plans add company accounts, quotes, contract pricing and approvals. Confirm the current plan contents with Vendure before selecting.
Marketplace or omnichannel operator on one API	Vendure	The Vendure README positions one backend and one GraphQL API for D2C, B2B, marketplace and omnichannel sales. Validate that the model matches your marketplace rules during a proof of concept.
Team with strong Python and Django skills	Saleor	Saleor is built on Python, Django and GraphQL with PostgreSQL, so existing Django engineers can work in a familiar stack. Extensions run as webhooks and apps, not in-process plugins.
Team with strong TypeScript and NestJS skills	Vendure	Vendure is built with TypeScript on Node.js and NestJS. Plugins can extend or override services, entities and strategies without forking the core, and the admin dashboard can be extended with custom pages.
Team that wants a free self-hosted core with no commercial license	Saleor	Saleor is BSD-3-Clause licensed. Vendure is dual-licensed, and without a commercial agreement GPLv3 applies, which may matter for proprietary modifications.
Team needing single sign-on and audit logs out of the box	Vendure, if on a paid plan	Vendure's paid plans list single sign-on and audit logs. Confirm whether your required identity integration is covered by the plan you choose.

How each platform is built and what that means for operations

Both platforms are GraphQL-first commerce backends that you would run inside your own infrastructure, but they ask for different runtimes, service sets and database choices. The cards below show what each stack means for patching, moving parts and the skills your team must already have.

Saleor runs a Python and Django core

Saleor is built on Python, Django, GraphQL and PostgreSQL, so your platform team patches a Python application stack and a PostgreSQL database. Extension happens through webhooks, apps, metadata and API extensions rather than in-process plugins, which keeps custom logic outside the core process. Check that your Python and Django engineers can own upgrades, and confirm the supported Python and Django versions against the release page for the current Saleor line, which is 3.23.42 at the time of research.

Saleor has more moving parts

A production Saleor install needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. Each of these is a separate service with its own scaling, monitoring, backup and failure modes, so the operational surface is wider than a single application process. The Docker Compose setup asks for at least 5 GB of memory for Docker, which is a floor for evaluation and should be validated against your expected load before you size production hosts.

Vendure runs on Node.js and NestJS

Vendure is written in TypeScript on Node.js with NestJS, and it exposes GraphQL Shop and Admin APIs from one backend. Your team patches a Node.js runtime and the NestJS dependency tree, which suits organizations already operating JavaScript or TypeScript services. Vendure plugins can extend or override any service, entity or strategy without forking the core, so the custom code lives in the same runtime that serves commerce traffic. Review how plugin upgrades track core changes before you commit to heavy customization.

Vendure pins Node.js versions

Vendure requires Node.js 20.19 or later, or 22.12 or later, so your runtime policy must track both supported version lines. Confirm which Node.js line your security team accepts and how quickly you can move when a runtime reaches end of support. Node.js patch cadence becomes a recurring task alongside Vendure's own release cycle, and both should be in your upgrade calendar before go-live.

Database engine choice differs

Vendure supports PostgreSQL, MySQL, MariaDB and SQLite, while Saleor is built around PostgreSQL. If your database standard is PostgreSQL, the two stacks converge on the same engine, but a MySQL or MariaDB shop will need to confirm Vendure's support matrix with its own DBA team. SQLite suits evaluation and small test environments, and production choices should be confirmed with Vendure before you design backup and failover around them.

What each license allows and what the paid tiers add

Saleor is licensed under BSD-3-Clause, a permissive license that lets a team run, modify and redistribute the code with conditions that are light by comparison. Self-hosting carries no license fee, and the project supports a Docker-based setup alongside Saleor Cloud as managed hosting. The license matters most when you plan to ship a modified core to other organizations or embed the platform in a product you sell.

Permissive terms: BSD-3-Clause asks you to keep the copyright notice and license text, and it does not require you to publish your modifications.
Self-hosting with Docker: The Docker Compose setup runs the API, the Dashboard, PostgreSQL, Valkey or Redis and Celery workers, and it asks for at least 5 GB of memory for Docker.
Saleor Cloud: Managed hosting is a separate decision with its own plan terms, so the license alone does not settle what you will pay to host.
Extension model: Custom logic runs through webhooks, apps and metadata, which keeps your code outside the core and reduces the chance that a core change forces distribution of your own work.
Feature availability: Split payments, returns, multi-warehouse fulfillment and the promotion engine are described as part of the open-source codebase, so confirm with the project whether any hosted or enterprise offering adds capabilities.

Check the Saleor GitHub repository for the current license file and confirm with the project whether any commercial support or hosted terms apply to your deployment.

Capability comparison: Saleor and Vendure

This table compares Saleor and Vendure on licensing, stack, extension model, commerce features and hosting. Where a capability is supplied for only one platform or depends on a paid plan, the cell says so, so confirm those items against your own requirements before you shortlist either platform.

Capability	Saleor	Vendure
License	BSD-3-Clause, with no paid license tier required to self-host	GPLv3 by default, or the Vendure Commercial License under a commercial agreement; confirm which fits your distribution model
Core language and framework	Python and Django on PostgreSQL, with GraphQL	TypeScript on Node.js and NestJS, with GraphQL Shop and Admin APIs
Supported databases	PostgreSQL	PostgreSQL, MySQL, MariaDB and SQLite
API style	GraphQL API covering the full platform	GraphQL Shop and Admin APIs from one backend
Extension model	Webhooks, apps, metadata and API extensions rather than in-process plugins	Plugins that extend or override any service, entity or strategy without forking the core
Per-channel pricing, currencies and stock	Supported, including multiple warehouses	Not covered by the supplied facts; confirm channel and multi-warehouse behavior in Vendure's documentation
Split payments and multi-gateway payments	Both supported	Not covered by the supplied facts; confirm against your payment provider requirements
Promotion engine	Sales, vouchers, cart rules and gift cards	Not covered by the supplied facts; confirm promotion types with Vendure
B2B features (company accounts, quotes, contract pricing, approvals)	Not covered by the supplied facts; confirm before assuming parity	Available in paid Starter, Growth, Scale and Enterprise plans; confirm the plan that includes each feature
Single sign-on and audit logs	Not covered by the supplied facts; confirm with Saleor	Available in paid plans; confirm which tier includes each option
Admin extension approach	Extensions through apps and the GraphQL API; confirm dashboard customization options	Admin dashboard built with React and TanStack, extendable with custom pages
Managed hosting status	Saleor Cloud is offered as managed hosting, with GMV-based plans covered on its sibling page	Vendure Cloud is in design-partner preview, with general availability planned for Q1 2027

How extensions and identity integration differ in practice

The extension model is the first thing to settle, because it decides where your custom code lives and how often it has to change. Saleor extends through webhooks, apps, metadata and API extensions rather than in-process plugins. Your integration sits outside the core process and reacts to events or calls the GraphQL API, so an ERP sync, a tax engine or a fulfillment partner can be built, deployed and rolled back without touching Saleor's codebase. The cost is that everything you build is bound by event payloads and API contracts. If your main need is heavy ERP or warehouse synchronization, that boundary is usually a benefit, because the integration can fail, retry and scale on its own. Confirm the webhook event coverage for each workflow you need before you design around it.

Vendure takes the opposite position. Its plugins can extend or override any service, entity or strategy without forking the core, and the React and TanStack admin dashboard can be extended with custom pages. That gives deeper control over checkout logic, pricing rules, or a back-office workflow such as approvals that a webhook alone cannot shape. The trade-off is coupling. Code that overrides internal services must be retested against each Vendure release, so your upgrade effort grows with the number of overrides you keep. For a team with a custom admin workflow and a steady release schedule, this model is often the right one. For a team that wants the core to stay untouched, it is a maintenance commitment.

Identity integration works differently on the two sides and needs its own check. Vendure lists single sign-on among the features of its paid Starter, Growth, Scale and Enterprise plans, so SSO is a licensing decision as well as a technical one. Saleor's identity handling for staff in the Dashboard and for storefront customers depends on your deployment and on the apps you attach, so ask the vendor and your own platform team to confirm how staff authentication, customer accounts and token lifetimes are handled in your setup. Ask whether SSO for Dashboard staff is supported in your target version, and who maintains the connector if it is not.

What drives the running cost of each platform

Running costs for Saleor and Vendure come from the same few places: the services you operate, the people who can change them, the license tier you pick and how often you absorb upgrades. Each card below names one of those drivers and the question to put in a quote, so the comparison rests on your scope rather than on license headlines.

Services you operate

Saleor needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, and its Docker Compose setup asks for at least 5 GB of memory for Docker. Vendure runs as a Node.js server with a database and an admin build that you host yourself. Count each service, its backups and its monitoring in your estimate. Ask the implementer to list every component, the environments (development, staging, production) and who patches each one.

Engineering skills to hire or retain

Saleor is Python and Django with a GraphQL API, so your extensions and webhook apps will be written in Python. Vendure is TypeScript on NestJS, so customizations use NestJS services and the React and TanStack admin extension model. Your recurring cost follows the people you can hire and keep for that stack. Ask for named developers who have shipped production work on the chosen framework, and price in onboarding time for anyone new to it.

Paid editions and managed options

Vendure's paid Starter, Growth, Scale and Enterprise plans add B2B features such as company accounts, quotes, contract pricing and approvals, plus single sign-on, audit logs and a commercial license. Saleor Cloud is a managed option with GMV-based plans. Decide early whether you need the B2B or SSO features, because they recur as license fees and change your architecture. Ask the vendor which features are in which tier and how plan changes are billed.

Upgrade testing cadence

Vendure published v3.7.4 on October 5, 2026 and v3.8.0 on October 12, 2026. Saleor published 3.23.42 on October 16, 2026. Each release needs regression testing of your webhook apps, plugins and storefront integrations before it reaches production. Plan for a recurring upgrade window rather than an occasional one. In the quote, ask how many upgrade cycles per year are included and who owns the regression suite.

Support and partner coverage

Vendure's paid plans include direct support, which is a recurring license cost you can plan against. Saleor support for a self-hosted deployment usually comes from your own team or a third-party partner, so the support cost is set by the partner contract you negotiate. Confirm the response expectations in writing for whichever path you choose, and confirm whether the partner covers security patches and on-call work outside business hours.

Moving from one platform to the other

This sequence moves a working shop from Saleor to Vendure or the reverse without losing catalog structure, order history or customer accounts. The output is a cutover you have tested in parallel, with each step signed off against a written inventory.

Inventory the commerce configuration
Your team lists every catalog product type, category, attribute, channel, currency, warehouse, promotion, voucher, gift card and customer account group in the source platform. Export each set into a spreadsheet or JSON file and record counts per item type. Done means a signed inventory that the commerce owner and the finance lead have both reviewed, so nothing is found for the first time at cutover.
Map the data model and identifiers
Engineers compare how each platform models channels, pricing, stock and variants, since Saleor scopes pricing and stock per channel and warehouse while Vendure structures these differently. Write a mapping table from every source field to a target field, and decide how old product, order and customer IDs will be stored as external references. Done means the mapping has been checked against a sample of a few hundred real records and every field has an owner.
Rebuild custom logic on the target
Developers rewrite custom behavior in the target's extension model: Saleor webhooks and apps on one side, Vendure plugins, services and strategies on the other. Each custom feature gets a test that proves the same input produces the same output as the source. Done means every item on the custom logic inventory passes its tests in a staging environment, and any feature without a clear equivalent is escalated for a business decision.
Rebuild the storefront and admin pages
Front-end developers rewrite storefront queries and mutations against the other GraphQL API, since the schemas differ in types and field names. Operations staff also rebuild any custom admin pages, which in Vendure use React and TanStack and in Saleor sit in the Dashboard or in apps. Done means checkout, search, account and order-history pages run end to end on the target in staging.
Migrate orders, customers and payment tokens
Migrate order history and customer records through scripts written from the mapping, and confirm the payment provider's guidance before moving any stored payment tokens or card references. Where the provider does not permit token transfer, plan for customers to re-enter payment details. Your privacy and compliance owners approve the data handling for personal and payment data. Done means record counts and sample checks match the source, and the signed approval is on file.
Run parallel testing
Run the target alongside the source with test orders, refunds, returns, partial fulfillment and promotion stacking, and compare results line by line. Security testers also verify authentication, API permissions and webhook or plugin behavior in the new stack. Done means every test case in the agreed test plan has a recorded pass, and open defects have an owner and a fix before cutover.
Cut over and retire the source
Freeze catalog and order writes on the source, run the final delta migration, switch DNS or routing to the target, and watch order flow and error logs closely. Keep the source read-only and retained for a period your records and compliance policy require. Done means live orders complete on the target, the cutover runbook is signed, and the source is archived with an access plan.

What implementing each platform involves and where projects run long

Implementation on either platform starts with the same core work: environment setup, data modeling, payment and promotion configuration, a storefront, and hardening and backup of the self-hosted stack. On Saleor, the environment is the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, configured through environment variables, so the first decision is how those services are packaged and who owns their upgrades. On Vendure, the runtime is a Node.js application on NestJS with PostgreSQL, MySQL, MariaDB or SQLite, and the first decision is how custom plugins are structured. For both, model channels, currencies, warehouses and stock early, because changing them after products and prices are loaded is expensive. Payment gateway integration, split payments and promotion rules (sales, vouchers, cart rules and gift cards on Saleor) should be tested against a written list of order scenarios, including returns and partial fulfillment. Confirm the exact Docker Compose memory and service requirements for your chosen Saleor version with the Saleor Docker Compose setup guide before sizing hosts.

Projects usually run long in three places. On Vendure, complex B2B pricing and approval flows are the most common: company accounts, quotes, contract pricing and approvals are paid-plan features, so confirm with Vendure which plan covers your needs before design starts, then model approval chains as plugin code and test them with real buyer hierarchies. On Saleor, webhook-based integrations with ERP and tax systems tend to take the most time, because each event, retry, idempotency rule and failure path is code your team or DeployOpen must write and monitor. On either side, upgrade testing for custom code is the recurring cost that is often underestimated. Vendure's releases, including v3.8.0 published on October 12, 2026, and Saleor's, including 3.23.42 on October 16, 2026, change internal APIs your extensions may depend on, so budget a regression suite and a staging environment before go-live.

DeployOpen plans, implements and hardens these systems inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask each vendor or partner for a written breakdown of environment setup, integrations, data migration, testing, backup and handover, and check which items are included and which are optional. Timelines follow from that scope, so the scope document, not a general estimate, is what you compare between the two platforms. A useful illustrative check: list every external system the store must talk to, every payment method, and every B2B approval rule, then ask which of them each platform handles natively and which become custom code to maintain.

Questions buyers ask before choosing Saleor or Vendure

Is self-hosting Saleor or Vendure free?

Self-hosting Vendure is free, according to the Vendure README, so the license cost is zero while you run the software yourself. Saleor is BSD-3-Clause licensed and can be self-hosted with Docker, so there is no license fee for the core either. The recurring costs are the ones you pay for: the servers or cloud accounts for the API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, plus the engineers who operate, patch and upgrade them. If you want managed hosting, Saleor offers Saleor Cloud on GMV-based plans, and you should ask Saleor for current terms. Ask any implementation partner for a written quote that separates one-time build work from ongoing operations and support.

What does GPLv3 mean if we modify the Vendure core?

Vendure is dual-licensed under GPLv3 and the Vendure Commercial License, and without a commercial agreement the GPLv3 applies by default. Under GPLv3, distributing a modified core generally means you must make the corresponding source available under the same terms, so a private modification you only run internally is treated differently from one you ship to others. Vendure's license includes a plugin exception that allows plugins to be distributed under a different license, which matters if your custom work lives in plugins. Have your legal counsel confirm how your use, hosting and distribution model fits, and ask Vendure whether a commercial license is needed for your case.

Is Vendure Cloud ready for production workloads?

Not yet, based on the information available for this comparison. The Vendure README describes Vendure Cloud as a managed runtime in design-partner preview, with general availability planned for Q1 2027. A preview is not a commitment to production terms, so do not plan a production launch around it without written confirmation of service levels, support and data handling. If you need managed hosting today, self-hosting Vendure on infrastructure you control is the documented path, and Saleor Cloud is an alternative to evaluate on its own terms.

How much effort does each stack need in-house compared with a partner?

Both platforms are multi-service systems, so the effort sits in operations and extension work. Saleor needs the API, the Dashboard, PostgreSQL, Valkey or Redis and Celery workers, and its Docker Compose setup asks for at least 5 GB of memory for Docker, according to the Saleor docs. Vendure runs on Node.js 20.19 or later, or 22.12 or later, with NestJS and a choice of PostgreSQL, MySQL, MariaDB or SQLite. Your in-house team needs Python and Django skills for Saleor or TypeScript and NestJS skills for Vendure, plus Kubernetes or Docker, database and monitoring experience. A partner can take on planning, configuration, integration, hardening, backups and upgrades under a fixed-scope written agreement, while your team keeps ownership of the business rules.

Can a small team run either platform on its own?

It depends on your team's skills and how much you extend the platform. A team with strong backend and DevOps experience can run either one, but both need routine work: upgrades, database maintenance, worker monitoring, security patches and backups. Saleor extends through webhooks, apps and metadata rather than in-process plugins, which keeps custom code separate from the core and can simplify upgrades. Vendure plugins can extend or override any service, entity or strategy without forking the core, which is powerful for deep customization but raises the upgrade testing burden. If you have no one who can own that work, consider a retainer for ongoing support and upgrades, scoped in writing before work starts.

How long does a migration take, and what drives the timeline?

The timeline depends on the scope of what you move, and no duration can be stated responsibly from this comparison alone. The main drivers are the volume and cleanliness of product, price and inventory data; how many channels, currencies and warehouses you run; how many payment gateways and promotion rules must be reproduced; and how many integrations with ERP, tax, shipping and search must be rebuilt. Moving between two different architectures, such as a Saleor webhook model and a Vendure plugin model, means redesigning extensions rather than copying them. Ask any partner for a written plan that lists the data mapping, integration rebuild, test cycles and cutover steps before agreeing a timeline.

What should we ask for in a written quote?

Ask for a quote that follows from a written scope, listing deliverables, environments and assumptions, since DeployOpen does not publish a price list. Request the following: what is one-time (architecture, build, data migration, integration, hardening, documentation) and what recurs (hosting, support, upgrades, testing and security reviews); which platform versions and dependencies are covered; how licensing is handled, including any Vendure commercial license or Saleor Cloud fees you would pay separately; what testing and acceptance criteria apply; and how changes to scope are priced. Confirm exclusions in writing, including any compliance evidence, which DeployOpen prepares but independent auditors issue.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Saleor vs Vendure, we start from your commerce requirements and hosting constraints, then write down what each option would need to run in your environment.

How we scope

Map your channels, B2B needs, payment gateways and warehouse structure against both platforms before choosing.
Confirm whether you need Saleor's webhook and app model or Vendure's in-process NestJS plugins.
Agree scope, deliverables and timelines in writing before any work starts, with a quote following from that scope.

How we build

Stand up the chosen stack, including database, cache or queue, workers and admin front end, inside your infrastructure.
Build integrations for payments, tax, ERP and identity, then test promotions, returns and stock flows end to end.
Run security testing and harden the deployment, covering secrets, network paths and access to the admin interfaces.

How we hand over

Document configuration as environment variables, deployment steps, data flows and the upgrade procedure for your team.
Deliver backup and restore procedures and walk your engineers through the operational runbook.
Prepare controls and evidence for any compliance assessment you run, without issuing audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Plan upgrades against each vendor's release cadence, including Saleor and Vendure version changes, before they reach production.
Ask any partner, including DeployOpen, to confirm current license terms and paid-plan features in writing before you commit.

Saleor vs Vendure