Which open-source headless commerce platforms fit your team?
Choose Medusa when your team is already fluent in Node.js and TypeScript, wants a commerce framework that its own engineers can shape deeply, and is ready to run the operating parts itself. The core framework is MIT licensed, and its modules cover carts, orders, product catalogs, pricing and inventory on PostgreSQL. The condition that matters is operational: a self-hosted Medusa deployment needs PostgreSQL, Redis, and two Medusa instances, one in server mode and one in worker mode, plus S3 for files in production. Role-based access control features sit in the Enterprise Edition, which requires a commercial agreement with MedusaJS, Inc. and is not OSI open source. If you need RBAC in the admin, put that cost into the licensing conversation before you commit.
Choose Saleor when your storefront team works mainly against a GraphQL API and you need multi-warehouse fulfillment, per-channel pricing and multiple payment gateways out of the box. Saleor is BSD-3-Clause licensed and built on Python, Django and PostgreSQL, and it extends through webhooks, apps and metadata rather than in-process plugins. That model suits teams that want to keep the core unmodified and integrate through services. The trade-off is the stack: you will run the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, and Docker Compose asks for at least 5 GB of memory. Confirm that your Python and Django skills, not only your storefront skills, are available for upgrades and custom apps.
Choose Vendure when you want one TypeScript backend that serves D2C, B2B and marketplace sales through a single GraphQL API, and you expect to extend the core heavily. Its plugins can extend or override any service, entity or strategy without forking, and the admin dashboard can take custom pages. The license needs careful reading: Vendure is dual-licensed under GPLv3 and the Vendure Commercial License, and without a commercial agreement GPLv3 applies. The plugin exception lets Vendure plugins ship under a different license, but the Commercial License itself is not OSI open source. B2B features such as company accounts, quotes, contract pricing and approvals, along with single sign-on and audit logs, sit in the paid Starter, Growth, Scale and Enterprise plans. Confirm with Vendure which tier covers your identity and audit requirements before you design around them.
Which platform fits which scenario
This table matches common headless commerce scenarios to the platform that fits best and the condition that would change that choice. Read each row as a starting point, then test the condition against your own team, hosting constraints and sales model before shortlisting.
| Scenario | Best fit | Why and what would change the choice |
|---|---|---|
| B2B-heavy stores with company accounts and approvals | Vendure | The README lists company accounts, quotes, contract pricing and approvals as B2B features, but in the paid Starter, Growth, Scale and Enterprise plans. Confirm whether your approval flows need those plans or can be built in the open-source core. |
| Marketplace or multi-channel sales from one backend | Vendure or Medusa | Vendure's README positions one backend for D2C, B2B, marketplace and omnichannel sales through a single GraphQL API. Medusa also supports B2B stores, marketplaces and point of sale, so compare module coverage for your channels before choosing. |
| Per-channel pricing and multi-warehouse fulfillment | Saleor | Saleor supports per-channel pricing, currencies and stock across multiple warehouses, with split payments and returns. Pick it when channel pricing is central; confirm that your fulfillment logic fits its model. |
| Teams that prefer GraphQL-first with Python | Saleor | Saleor is built on Python, Django, GraphQL and PostgreSQL and extends through webhooks and apps. Teams without Python skills should weigh the maintenance effort against a TypeScript option. |
| Teams standardized on TypeScript and Node.js | Medusa or Vendure | Both are built with TypeScript on Node.js. Medusa needs PostgreSQL, Redis and a server plus worker split, while Vendure supports PostgreSQL, MySQL, MariaDB and SQLite. Choose by which data services and extension model your team wants to operate. |
| Teams that want a managed runtime | Medusa Cloud or Saleor Cloud | Medusa Cloud and Saleor Cloud are offered as managed hosting. Vendure Cloud is in design-partner preview with general availability planned for Q1 2027, so do not plan production around it without a current status check. |
| Teams that need self-hosting with no vendor-managed runtime | Vendure or Medusa | Self-hosting Vendure is free under the license terms, and Medusa's core is MIT licensed. Confirm which Enterprise Edition features, such as role-based access control, you need, since those require a commercial agreement with MedusaJS, Inc. |
How each platform is built and licensed
Each platform sits on a different language stack, database set and license model, and those choices decide who on your team can operate and extend it. The cards below set out the facts that matter most when you build a custom storefront on a commerce API.
Medusa: Node.js and TypeScript on PostgreSQL
Medusa is built with Node.js and TypeScript on PostgreSQL, with modules for carts, orders, catalogs, pricing and inventory. Self-hosting also needs Redis, plus two Medusa instances: one in server mode for the API and admin dashboard, and one in worker mode for background tasks. Its MIT-licensed core is open source, but Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc. Check which features your team needs before you assume the MIT label covers them.
Saleor: Python, Django and GraphQL
Saleor is BSD-3-Clause licensed and built on Python, Django, GraphQL and PostgreSQL. It exposes everything through one GraphQL API, and running it needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. Your team must operate Python services and background workers in the same way it runs the storefront, so confirm it can run Celery in production. The BSD-3-Clause license is permissive and OSI-approved, so your main open question is operational.
Vendure: TypeScript on NestJS
Vendure is built with TypeScript on Node.js and NestJS, with GraphQL Shop and Admin APIs. It supports PostgreSQL, MySQL, MariaDB and SQLite, which gives teams more database choice than the other two platforms in this comparison. The project is dual-licensed under GPLv3 and the Vendure Commercial License, and GPLv3 applies by default without a commercial agreement. Its plugin exception lets plugins ship under a different license, so review how your custom plugins are distributed before you build.
Which licenses are open source
Open source here means OSI-approved. The BSD-3-Clause license (Saleor), the MIT core (Medusa) and the GPLv3 default (Vendure) are all OSI-approved licenses. Medusa Enterprise Edition features and Vendure's Commercial License are proprietary agreements that fall outside open source. Ask each vendor which feature set your order requires, and have counsel map each feature to the license that governs that code.
Capability comparison across the three platforms
This table sets Medusa, Saleor and Vendure side by side on license, latest supplied release, API style, database support, extension model, built-in B2B and promotion features, required services and managed hosting. Read each row as a starting point for your own evaluation: where a cell says to confirm, check the vendor documentation against the exact edition and version you plan to run.
| Capability | Medusa | Saleor | Vendure |
|---|---|---|---|
| License | MIT core, with Enterprise Edition role-based access control features under a commercial agreement | BSD-3-Clause | GPLv3 by default, or the Vendure Commercial License under a commercial agreement |
| Latest supplied release | v2.21.2, September 28, 2026 | 3.23.42, October 16, 2026 | v3.8.0, October 12, 2026 |
| API style | Node.js and TypeScript framework; confirm the exact store and admin API surface in the docs | GraphQL API for all functions | GraphQL Shop and Admin APIs |
| Database support | PostgreSQL | PostgreSQL | PostgreSQL, MySQL, MariaDB and SQLite |
| Extension model | Modules and framework customization; confirm the plugin approach for your version | Webhooks, apps, metadata and API extensions, not in-process plugins | Plugins can extend or override any service, entity or strategy without forking the core |
| Built-in B2B features | B2B stores are supported; confirm which account, quote and approval features ship in the core | Multi-channel and multi-warehouse support; confirm B2B account features in the docs | Paid Starter, Growth, Scale and Enterprise plans add company accounts, quotes, contract pricing and approvals |
| Promotions and payments | Pricing and promotion modules; confirm promotion types and split payment support | Sales, vouchers, cart rules and gift cards, plus split payments and multi-gateway support | Confirm promotion and payment capabilities against the plugin and version you plan to use |
| Required services | PostgreSQL, Redis, S3 for files, and two instances (server and worker) | API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers | Node.js runtime and a supported SQL database; confirm any queue or cache services for production |
| Managed cloud option | Medusa Cloud, or self-hosted | Saleor Cloud, or self-hosted with Docker | Self-hosting is free; Vendure Cloud is in design-partner preview with general availability planned for Q1 2027 |
What running each stack asks of your operations team
Operating effort starts with how many moving parts each platform needs before the first storefront request is served. A self-hosted Medusa deployment needs a PostgreSQL database, a Redis database, and two Medusa instances: one in server mode for the API and admin dashboard, and one in worker mode for background tasks. Your team owns both processes, their health, and their scaling. Before each startup, the predeploy script runs database migrations, so your release pipeline must allow for that step and for rollback if a migration fails. Each server and worker needs database credentials plus COOKIE_SECRET and JWT_SECRET values, which should come from your secrets manager rather than a shared file. Confirm that your deployment checks pass against the /health endpoint before traffic is switched over.
Saleor's footprint is set by its Docker Compose layout. Running it needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, all configured through environment variables that follow 12-factor app principles. The Saleor Docker Compose documentation asks for at least 5 GB of memory for Docker, which is a floor for evaluation rather than a production sizing. Production sizing, high availability and backup design are not covered by that figure, so ask Saleor and your own load testing for those numbers before you commit to a hosting plan. Vendure, by contrast, is a Node.js application that requires Node.js 20.19 or later or 22.12 or later, so your runtime upgrade schedule must match one of those lines. Its supported databases are PostgreSQL, MySQL, MariaDB and SQLite, and choosing among them is a decision you should make early, because the database engine shapes backup tooling, skills and migration effort.
The buyer pays for three cost components. Internal platform time is the largest and recurs every month for patching, upgrades, monitoring and incident response. Hosting is also recurring and scales with the number of services each stack requires. Implementation or retainer work from an outside partner is usually a one-time build cost plus optional ongoing support, and should be priced from a written scope. When you request quotes, ask each vendor or partner to separate one-time setup from recurring support, to state which services are included, and to name who handles migrations, secrets rotation and version upgrades. Those answers show more about operating effort than any feature table.
Licensing and paid tiers by platform
Medusa is an open-core project. The core commerce framework is MIT licensed, so you can self-host it, modify it and run it in your own cloud accounts or data centers without paying the project for the core code. The paid layer is the Enterprise Edition features based on role-based access control. Those features require a commercial agreement with MedusaJS, Inc., so the license cost depends on what you need from the admin side rather than on the storefront.
- MIT core: The commerce framework (carts, orders, product catalogs, pricing and inventory modules) is available under MIT terms.
- Enterprise features: Role-based access control features sit outside the MIT core and need a commercial agreement with MedusaJS, Inc.
- Managed option: Medusa Cloud is offered as managed hosting, alongside the self-hosted route.
- Self-hosted footprint: A self-hosted deployment runs PostgreSQL, Redis and two Medusa instances (server and worker), so hosting costs and operating effort do not change with the license.
- Fit: Teams that need multi-role admin access control should confirm early whether the open core covers their roles or whether the commercial agreement is required.
Ask MedusaJS, Inc. which specific RBAC capabilities sit inside Enterprise Edition, what the agreement covers in terms of term and support, and whether pricing is tied to usage or seats. Confirm these in writing before you commit the storefront design to them.
Saleor is licensed under the BSD-3-Clause license, a permissive license that allows commercial use, modification and redistribution with attribution and warranty disclaimers. It is built on Python, Django, GraphQL and PostgreSQL. For self-hosting, the license means you do not owe a license fee to run the platform in your own infrastructure. The alternative is Saleor Cloud, a managed hosting option, which replaces infrastructure work with a hosting contract.
- BSD-3-Clause: The core platform is available under a permissive license with no copyleft obligation on your storefront code.
- Self-hosted: Saleor runs with Docker, so the license cost is zero while your team carries hosting, upgrades and security patching.
- Saleor Cloud: The managed option moves hosting operations to the vendor and is priced under its own terms, which you should request in writing.
- Extensions: Webhooks, apps and metadata extend the platform, so extension work does not require a fork under this license.
- Scope of the license: Confirm with the vendor which features, if any, sit in separately licensed or paid offerings before you plan around them.
Request the current Saleor Cloud terms, including what the managed service includes and how support and upgrades are handled, and compare them with the staff time and infrastructure cost of your own self-hosted deployment.
Vendure is dual-licensed under GPLv3 and the Vendure Commercial License. Without a commercial agreement, the GPLv3 applies by default, which matters if you plan to distribute modified copies of the core. Vendure's license includes a plugin exception that allows Vendure plugins to be distributed under a different license. Self-hosting Vendure is free. Vendure Cloud was described in the README as a managed runtime in design-partner preview, with general availability planned for Q1 2027.
- Dual license: GPLv3 applies by default, and the Vendure Commercial License is available through a commercial agreement.
- Plugin exception: Vendure plugins can be distributed under a different license, which helps teams that ship proprietary extensions.
- Paid plans: Starter, Growth, Scale and Enterprise plans add B2B features such as company accounts, quotes, contract pricing and approvals, plus single sign-on, audit logs, direct support and a commercial license.
- Self-hosting: Self-hosting is free, so the cost of running Vendure is your infrastructure and staff time.
- Vendure Cloud: The managed runtime was in design-partner preview, with general availability planned for Q1 2027, so confirm its status and terms when you evaluate it.
Before you select a plan, map your B2B, SSO and audit log requirements to the named features, and ask Vendure which tier includes each one and what the commercial license changes for your distribution model.
How to choose and pilot a headless commerce platform
This sequence moves a team from business requirements to a tested shortlist of Medusa, Saleor and Vendure, so each decision rests on evidence from the team's own storefront, extension needs and upgrade plan.
Define B2B, marketplace and channel requirements
The commerce lead and the product owner write down which sales models the store must support: direct-to-consumer, B2B with company accounts and contract pricing, marketplace listings, point of sale, and any multi-warehouse or multi-currency needs. Each requirement is tagged as must-have or nice-to-have. Medusa describes B2B stores, marketplaces and point of sale as supported use cases, Saleor covers per-channel pricing, currencies and multi-warehouse stock, and Vendure positions one backend for D2C, B2B, marketplace and omnichannel sales. Done means a signed requirements list that the architecture lead and finance have both approved.
Confirm license terms against the paid features you need
The procurement lead and legal counsel map each must-have requirement to the edition that provides it. Medusa's core is MIT licensed, but role-based access control features in its Enterprise Edition need a commercial agreement with MedusaJS, Inc. Vendure's Starter, Growth, Scale and Enterprise plans add B2B features, single sign-on and audit logs, and without a commercial agreement the GPLv3 applies by default. Saleor is BSD-3-Clause. Ask each vendor in writing which features are covered by which license and how plans change with usage. Done means a written license matrix signed by legal, with open questions listed.
Check required services against your hosting standard
The platform engineering lead inventories the services each candidate needs and compares them with the organization's approved stack. Medusa self-hosted needs PostgreSQL, Redis, S3-compatible file storage and two instances, one in server mode and one in worker mode. Saleor needs the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers, with at least 5 GB of memory for its Docker setup. Vendure supports PostgreSQL, MySQL, MariaDB and SQLite on Node.js 20.19 or later or 22.12 or later. Done means a reviewed architecture diagram and a list of any service that is not already approved, signed off by the infrastructure owner.
Build a storefront spike against each shortlisted API
A front-end engineer builds the same narrow storefront flow on each candidate: browse products, price by channel, add to cart, check out with one payment provider and read order status. All three expose GraphQL, so the team compares schema design, codegen tooling, authentication for the storefront and the admin API, and how errors are returned. Keep the spike to the flows in step one and time-box it to the team's own sprint capacity. Done means a short written comparison of the three spikes, with the code kept in a repository, reviewed by the lead engineer.
Test the extension path for your custom logic
The lead backend engineer implements one piece of business logic that the store really needs, such as a custom pricing rule, a fulfillment rule or an integration with an internal ERP. Saleor extends through webhooks, apps and metadata rather than in-process plugins. Vendure plugins can extend or override any service, entity or strategy without forking the core, and its admin can be extended with custom pages. Medusa uses its module and workflow model. Record how much code sits inside the platform versus in a separate service, and how each choice would survive a core upgrade. Done means a tested proof of concept and a short extension design note approved by the architecture lead.
Review the upgrade path against published release dates
The platform owner builds a release calendar from each vendor's published cadence and recent versions: Medusa v2.21.2 (September 28, 2026), Saleor 3.23.42 (October 16, 2026) and Vendure v3.8.0 (October 12, 2026). The team also reviews how many releases its own custom code would need to absorb, and who on the staff or DeployOpen retainer would perform each upgrade and test it. Ask each vendor for its support window and deprecation policy in writing, since these are not covered by the supplied facts. Done means a documented upgrade plan and a go or no-go recommendation signed by the CTO or head of engineering.
What buyers ask before hiring help with headless commerce
Can a team self-host Medusa, Saleor or Vendure without outside help?
Yes, each one is open source and can run in your own infrastructure, but the work goes beyond installing software. Medusa needs PostgreSQL, Redis, an API instance and a separate worker instance, plus S3 for file storage in production. Saleor needs its API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers. Vendure needs Node.js and a supported database, and its paid tiers add features rather than replacing the core. Ask whether your engineers have run this stack before, how many people can respond to incidents, and who owns upgrades. Outside help is most useful for the parts your team has not done before, such as the first production hardening pass.
What does our team have to supply when we self-host?
Plan to supply the infrastructure and the people who run it. For Medusa, that means PostgreSQL, Redis, S3-compatible storage and two Medusa processes, one in server mode and one in worker mode. Each process needs database credentials plus COOKIE_SECRET and JWT_SECRET values, and a deployment is checked through the /health endpoint. Saleor adds Valkey or Redis and Celery workers. Your side also covers:
- Cloud or data center accounts, networking and backups
- A secrets management approach for the environment variables each platform reads
- On-call coverage for payments, checkout and order processing
- Someone who reviews each release and applies security updates
Confirm each item with your platform team before committing to a timeline.
What drives implementation effort for a headless commerce build?
The biggest drivers are usually the integrations around the commerce core, not the core itself. Payment gateways, tax calculation, shipping carriers, ERP or inventory sync, and the search and content systems your storefront reads from each add work. Custom B2B workflows, such as company accounts, quotes, contract pricing or approval chains, add more. Vendure lists these B2B features in its paid tiers, so confirm whether you need them in the open-source core or the commercial plan. Ask any firm to split the effort by integration and to name which items are in scope and which are assumed.
Which costs are one-time and which recur after launch?
One-time costs cover architecture, initial build, integrations, data migration, testing and hardening. Recurring costs cover hosting, managed database and cache services, monitoring, backups, security patching, platform upgrades, and the staff who respond to incidents. Commercial licenses are a separate recurring line for Medusa Enterprise Edition features, Vendure paid tiers and Saleor Cloud if you choose managed hosting. Shopware, if it appears in your shortlist, prices its paid plans on gross merchandise value, so its recurring cost rises with sales. Ask vendors for current price sheets, since these change.
Does the open-source license allow commercial use of the storefront?
Generally yes for the core platforms, but the terms differ and your legal team should read them. Medusa's core framework is MIT licensed, while Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc. Saleor is BSD-3-Clause licensed. Vendure is dual-licensed under GPLv3 and the Vendure Commercial License, and without a commercial agreement the GPLv3 applies by default. Vendure's license includes a plugin exception that lets plugins ship under a different license, which matters if you plan to sell or distribute custom extensions. Confirm with counsel how your extensions and any distributed code are licensed.
What should we request in a fixed-scope quote for headless commerce?
Ask for a written scope that names each platform component, integration, environment and deliverable. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and does not publish a price list, so the quote follows from that scope. Request a breakdown by workstream, such as platform setup, each payment and tax integration, custom B2B logic, data migration, security testing and handover documentation. Ask what is excluded, which items depend on your decisions or third-party access, how changes are priced, and whether ongoing support, upgrades or continuous testing are offered as a separate retainer.
How hard is it to switch platforms after a headless commerce launch?
Switching is expensive mainly because catalog, order, customer and integration logic get tied to one API and data model. Medusa, Saleor and Vendure each expose their own GraphQL or REST interfaces and extension patterns, so a storefront built against one does not port directly to another. Plan for data export, mapping of products, prices, customers and orders, and rebuilding webhooks or plugins. Keep your storefront calls behind an internal API layer where practical, and document extension points from the start. Ask any implementation partner how they handle data portability and whether the exit plan is part of the written scope.
How do we check a platform's upgrade effort before we commit?
Read each project's release history and confirm how long its supported versions last before you choose. Medusa's current release is v2.21.2, Saleor's is 3.23.42 and Vendure's is v3.8.0, all as of the dates in their release pages, so check whether the release line you adopt receives fixes. Measure the upgrade path by testing your own extensions and integrations against a newer release in a staging environment. Confirm whether Medusa's predeploy migration step, Saleor's environment variable changes or Vendure's plugin APIs affect your code. Budget upgrade effort as recurring work, not a one-off.
How DeployOpen scopes headless commerce selection and implementation
DeployOpen works on headless commerce platforms as a self-hosted implementation partner, inside your own cloud accounts, data centers or air-gapped networks. We start from your storefront, integration and compliance requirements, then agree a written scope before any build work begins.
How we scope
- Map your storefront, checkout and back-office integration requirements before naming a platform
- Confirm the database, cache, worker and file storage services your hosting team already supports
- Agree deliverables, timelines and exclusions in writing before work starts, since engagements are fixed-scope
How we build
- Implement the chosen commerce backend, admin setup and custom storefront against your API contracts
- Configure production services such as caching, background workers and object storage in your environment
- Run security testing of the APIs, storefront and infrastructure before go-live, with findings tracked to closure
How we hand over
- Document the architecture, deployment steps, environment variables and upgrade procedure for your team
- Provide backup and restore procedures and walk your operators through them before handover
- Deliver evidence and configuration records that your auditors or compliance leads can review directly
How we support
- Offer ongoing support, platform upgrades and continuous security testing as a retainer after launch
- Plan version upgrades against the vendor's published release and support windows you confirm
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list
