Medusa vs Saleor vs Vendure: which fits which team
If your team is choosing a self-hosted headless commerce backend, the answer depends mainly on the language your engineers already run in production and on whether you need the commercial features that sit behind each vendor's paid tier. Medusa and Vendure are both TypeScript and Node.js frameworks, while Saleor is a Python and Django platform with a GraphQL API. All three are open-source options you can run in your own infrastructure, so the decision is about fit, licensing terms and operating effort rather than whether the code is open.
Medusa fits a team with strong TypeScript and Node.js skills that wants a commerce framework with an MIT-licensed core, where the commercial agreement with MedusaJS, Inc. matters only if you need the Enterprise Edition features based on role-based access control. Saleor fits a team with Python and Django experience that wants a BSD-3-Clause platform exposing everything through GraphQL, with its extension model built on webhooks, apps and metadata instead of in-process plugins. Vendure fits a TypeScript team that wants GPLv3 by default, with a commercial license available if your legal review cannot accept GPL obligations, and that values plugins able to extend or override services without forking the core. Before you shortlist, confirm three things with each vendor: which license terms your legal team will accept for your planned distribution model, which paid features (such as B2B company accounts, approvals, single sign-on or audit logs) you need on day one, and which skills your operations staff can support over time. Treat any single-language preference as a hiring and maintenance question as much as a technical one.
Which platform fits which buying scenario
This table maps common buying scenarios to the platform that fits best and the condition that makes the fit hold. Read each row against your own team skills, hosting model and licensing constraints, then confirm the cloud and support details flagged in the last column with the vendor before you commit.
| Scenario | Best fit and why | Condition and what to confirm |
|---|---|---|
| TypeScript team building a custom storefront | Medusa or Vendure. Both are Node.js and TypeScript backends, so the same language runs the API, extensions and often the storefront. | Holds if your team is comfortable with NestJS-style services (Vendure) or Medusa modules. Confirm Medusa's REST and storefront starter approach against your front end stack. |
| Python and Django shop wanting a GraphQL-first API | Saleor. It is built on Python, Django and GraphQL and exposes its full surface through one GraphQL API. | Holds if your engineers already maintain Django and PostgreSQL. Confirm that your integrations can work through webhooks and apps rather than in-process plugins. |
| Per-channel pricing and multi-warehouse fulfillment | Saleor. It supports per-channel pricing, currencies, stock and products across multiple warehouses in the core project. | Holds if channels and warehouses are core to launch. Confirm equivalent channel and warehouse modeling in Medusa and Vendure for your catalog before choosing. |
| B2B company accounts, quotes and approvals without an enterprise license | Evaluate Medusa and Vendure carefully. Medusa's RBAC features need a commercial agreement, and Vendure's B2B features sit in paid plans. | Holds only if you can accept a paid tier. Ask each vendor which B2B features are in the free code and which require a commercial agreement, and get pricing in writing. |
| Team that wants a managed cloud | Medusa Cloud or Saleor Cloud, depending on the stack you have chosen. Vendure Cloud is a managed runtime in design-partner preview with general availability planned for Q1 2027. | Holds if managed hosting outweighs self-hosting control. Confirm regions, data residency, support windows, usage allowances and upgrade handling directly with each vendor, since Vendure Cloud is not yet generally available. |
| Self-hosted with full control of the hosting stack | Any of the three can be self-hosted. Vendure self-hosting is free under its GPLv3 default, and Saleor offers Docker-based self-hosting. | Holds if your team can run PostgreSQL, Redis or Valkey, and background workers. Medusa needs separate server and worker instances, and Saleor needs Celery workers. |
| Strict copyleft or license-review constraints | Saleor, under BSD-3-Clause, and Medusa's MIT core are usually simpler to review. Vendure's GPLv3 default needs legal review before embedding in proprietary code. | Holds if your legal team treats GPL obligations as a blocker. Confirm with counsel whether Vendure plugins under its plugin exception meet your distribution model. |
| Teams needing a commercial license for proprietary extensions | Vendure's plugin exception may allow plugins under a different license. Medusa's commercial features require an agreement with MedusaJS, Inc. | Holds if you distribute extensions outside your company. Confirm the terms of each license with counsel before building product features that depend on them. |
What each license and edition covers and what is paid
Medusa is open core. The core commerce framework is MIT licensed, so your team can run, modify and redistribute it under permissive terms. The paid layer is narrower than the core: Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Medusa Cloud is the managed alternative to self-hosting, and it is a separate purchase from the license question.
- Core framework: MIT licensed, with no fee for running the open-source code yourself.
- Enterprise features: role-based access control features in the Enterprise Edition require a commercial agreement with MedusaJS, Inc.
- Hosting choice: Medusa Cloud managed hosting is offered alongside self-hosted deployments.
- Your own costs: PostgreSQL, Redis, S3 storage and the compute for two instances are paid to your cloud or data center providers, not to Medusa.
- Support: confirm with the vendor what support, if any, comes with a commercial agreement.
Before you commit, ask MedusaJS, Inc. exactly which modules and endpoints fall under Enterprise Edition, and confirm whether your planned access model needs them.
Saleor is BSD-3-Clause licensed, a permissive license that allows commercial use, modification and redistribution with attribution and disclaimer terms. The hosted option is Saleor Cloud, a managed service run by the vendor. Your sourcing question is which capabilities, if any, sit behind paid plans. Confirm that with Saleor before you assume the open-source edition covers your requirements.
- Core code: BSD-3-Clause, so self-hosting the code carries no license fee.
- Managed option: Saleor Cloud is the vendor-run hosted service, priced under the vendor's own terms.
- Paid features: confirm with the vendor which features, if any, are gated behind paid plans or commercial terms.
- Your own costs: the API, Dashboard, PostgreSQL, Valkey or Redis, Celery workers and infrastructure are paid to your providers when you self-host.
- Extensions: apps and webhooks are part of the open-source model, so confirm any third-party app licensing separately.
Ask for a written statement of which features are included in the open-source release and which need a paid Saleor Cloud plan or other commercial agreement.
Vendure is dual-licensed under GPLv3 and the Vendure Commercial License. Without a commercial agreement, GPLv3 applies by default. Internal use of an unmodified or modified Vendure instance is treated differently from distributing modified code to others, and that difference is the reason legal review matters here. Vendure also has a plugin exception that lets plugins be distributed under a different license, and paid plans add B2B and enterprise features.
- Default license: GPLv3 applies unless you hold a commercial agreement with Vendure.
- Internal use: running Vendure inside your own organization is not the same as distributing modified copies to customers or partners, so confirm with counsel how GPLv3 applies to your setup.
- Plugin exception: plugins may be distributed under a different license, which matters if you sell or share custom extensions.
- Paid plans: Starter, Growth, Scale and Enterprise add B2B features such as company accounts, quotes, contract pricing and approvals, plus single sign-on, audit logs, direct support and a commercial license.
- Cloud: Vendure Cloud is in design-partner preview, with general availability planned for Q1 2027.
Have legal counsel review the GPLv3 default and the plugin exception against how you plan to deploy and distribute, and compare the plan tiers against the features you need.
Why the Node.js and TypeScript stack differs from Python and Django
The runtime decides who maintains the platform after launch, so the language choice matters as much as the feature list. Medusa and Vendure are both built with TypeScript on Node.js, while Saleor is built on Python and Django with a GraphQL API and PostgreSQL. A team that already ships TypeScript services can usually staff Medusa or Vendure from its existing front-end and back-end pool. A team that runs Django applications will find Saleor's codebase familiar, and its Python skills may transfer more directly to custom work.
Vendure sets an explicit Node.js floor: version 20.19 or later, or 22.12 or later. Pin that range in your build images and check it against your own security patch policy before you pick a runtime. For Medusa, confirm its Node.js version policy with MedusaJS, Inc. before you standardize, including which versions it supports for the server and worker instances and how long each one stays supported. For Saleor, confirm the Python and Django versions the release you plan to run requires, since those will set your upgrade calendar.
Extension work also follows the language. In Vendure, plugins in TypeScript can extend or override services, entities and strategies without forking the core, and the admin dashboard in React can be extended with custom pages. In Saleor, the README describes extension through webhooks, apps, metadata and API extensions rather than in-process plugins, so custom logic usually runs as a separate service. Medusa's modules are also TypeScript. Ask your developers which model they can debug and test fastest, and run a short spike on one real integration, such as a payment or ERP connector, before you decide which stack carries the lower maintenance overhead.
How Medusa vs Saleor vs Vendure compare on APIs, extensions and services
This table compares the three headless commerce frameworks on license, stack, APIs, extension model, catalog and payment coverage, admin tooling, required self-hosted services and managed hosting. Cells marked as points to confirm are areas where the supplied research does not settle the answer, so check them with each vendor before you shortlist.
| Capability | Medusa | Saleor | Vendure |
|---|---|---|---|
| License | MIT core framework, with Enterprise Edition RBAC features under a commercial agreement | BSD-3-Clause | GPLv3 by default, or the Vendure Commercial License under a commercial agreement |
| Language and framework | Node.js and TypeScript | Python and Django | TypeScript on Node.js and NestJS |
| Database support | PostgreSQL | PostgreSQL | PostgreSQL, MySQL, MariaDB and SQLite |
| API style | Modules for carts, orders, product catalogs, pricing and inventory; confirm the full API surface with the vendor | GraphQL API covering all platform functions | GraphQL Shop and Admin APIs |
| Extension model | Module-based architecture; confirm the supported customization points with the vendor | 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 |
| Multi-channel and multi-warehouse | Confirm channel and multi-warehouse behavior with the vendor | Per-channel pricing, currencies and stock, with products across multiple warehouses | Single backend for D2C, B2B, marketplace and omnichannel sales; confirm warehouse handling with the vendor |
| Promotions and payments | Pricing module covers price handling; confirm promotion and split-payment support with the vendor | Split payments, returns, multi-gateway payments and a promotion engine with sales, vouchers, cart rules and gift cards | Confirm promotion and multi-gateway payment support with the vendor |
| Admin dashboard | Admin dashboard served by the server instance | Dashboard is a separate component to deploy | React and TanStack admin dashboard, extensible with custom pages |
| Required self-hosted services | PostgreSQL, Redis, S3 for production file storage, 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 with the vendor |
| Managed cloud option | Medusa Cloud | Saleor Cloud | Vendure Cloud, in design-partner preview with general availability planned for Q1 2027 |
What drives the running cost of each platform
Running cost for a headless commerce platform comes from the footprint of the stack, how many moving parts you patch, what you pay for paid features, and who on your team can operate it. The cards below separate these drivers so you can ask each vendor for the figures that matter to your environment.
Hosting footprint and memory
Saleor's Docker Compose setup asks for at least 5 GB of memory for Docker, before you size production capacity for your traffic. Saleor runs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, so the baseline is set by several processes. Medusa needs PostgreSQL, Redis and two Medusa instances. Vendure's footprint depends on your Node.js process layout and database choice. Ask each team to size a staging and a production environment in writing, not from the development defaults.
Services to run and patch
Every additional service is another component to back up, monitor, secure and upgrade. A self-hosted Medusa deployment runs a server instance for the API and admin dashboard and a separate worker instance for background tasks, alongside PostgreSQL and Redis. Production setups also depend on S3 for file storage. Saleor needs its API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers. Count the services in each design and assign an owner for each one.
Paid features and license terms
Medusa's core framework is MIT licensed, but Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc. Vendure is free to self-host, while its paid Starter, Growth, Scale and Enterprise plans add B2B features, single sign-on, audit logs and a commercial license. Saleor is BSD-3-Clause licensed. Map every feature your business needs against the edition that includes it, then request written pricing for that edition.
Cloud subscription versus self-hosting
Medusa Cloud, Saleor Cloud and Vendure Cloud pricing were not published in the material available here, so request written quotes from each vendor for the usage you expect. Vendure Cloud is a managed runtime in design-partner preview, with general availability planned for Q1 2027. Self-hosting shifts cost to your cloud accounts, staff time and on-call coverage. Compare a managed subscription with the full internal cost of running the same stack yourself.
Staffing skills and operating effort
Medusa and Vendure are built on Node.js and TypeScript, so a team with JavaScript skills can own both the storefront and the backend. Saleor is built on Python, Django and GraphQL, which fits teams already operating Django services. Check who will run database migrations, scale workers, rotate secrets and handle incidents. A mismatch between your team's skills and the platform stack increases the effort to operate it, whichever platform you pick.
Upgrade cadence and migration effort
Each platform ships releases on its own schedule, and each upgrade consumes engineering time for testing, plugin compatibility and schema changes. Medusa runs database migrations through a predeploy script before each startup, so upgrades touch the data layer on every release. Vendure's plugins can extend or override services without forking the core, so custom code must be retested after each core update. Plan a recurring upgrade window in your budget and ask each vendor for its support policy for older versions.
How a self-hosted rollout of each platform moves from setup to production
This sequence shows the order of work for running Medusa, Saleor or Vendure in your own infrastructure, from databases and secrets through migrations, process separation and health checks. Effort, duration and team size depend on the agreed scope and should come from a written quote.
Provision the databases and caches
Your platform or infrastructure team creates the stateful services each platform needs. Medusa requires a PostgreSQL database and a Redis database. Saleor requires PostgreSQL, Valkey or Redis, and Celery workers, and its Docker Compose setup asks for at least 5 GB of memory for Docker. Vendure supports PostgreSQL, MySQL, MariaDB and SQLite, so confirm which database your standards allow. The step is complete when each service is reachable from the application network and backups are configured for the database. Ask your vendor or partner which managed or self-hosted options they will support.
Set secrets and environment variables
The implementation team defines configuration outside the code. Saleor is configured through environment variables that follow 12-factor app principles, which suits secret injection from your vault or orchestrator. A self-hosted Medusa server and worker each need database credentials plus COOKIE_SECRET and JWT_SECRET values, so generate those separately for each environment and store them in your secrets manager. Vendure settings follow the same pattern through its configuration. The step is complete when every environment reads its values from the secrets store and no secret appears in source control.
Run database migrations before startup
The team runs schema migrations as a controlled release action rather than as a side effect of starting an application instance. Medusa runs its database migrations through a predeploy script before each startup, so your deployment pipeline should call that script and fail the release if it fails. For Saleor and Vendure, confirm the migration command and its order in the release runbook with the platform documentation and your own test environment. The step is complete when the migration job finishes on a staging copy of the database and the result is recorded in the change ticket.
Separate API and worker processes
The team deploys the storefront-facing API and the background processing as distinct processes so that long-running jobs do not compete with checkout traffic. A self-hosted Medusa deployment runs one instance in server mode for the API and admin dashboard and one in worker mode for background tasks. Saleor runs its API, Dashboard and Celery workers as separate components. Vendure separates its server and worker roles in the same way, which you should verify in its deployment guide. The step is complete when each process starts with its own role and scales independently in your orchestrator.
Switch production modules and storage
The platform team replaces development defaults with production services. Medusa's production setup moves caching, the event bus, the workflow engine and locking onto Redis, and it stores files in S3. Confirm equivalent production settings for Saleor and Vendure, including file storage, search and any cache or queue layer, against their documentation. This step is often where the infrastructure footprint becomes clear, so review the resulting service list with your security and operations leads. The step is complete when no development module is active in any production environment.
Check health and verify the release
The operations team confirms that each process is ready to serve before traffic is routed to it. Medusa deployments are checked through the /health endpoint, and your load balancer or orchestrator should poll it for each server and worker instance. For Saleor and Vendure, define an equivalent liveness and readiness check against the API and background workers. The step is complete when health checks pass on every instance, a test order or catalog query runs end to end in staging, and the results are stored with the release record.
What it costs to switch platforms after launch
Switching platforms after go-live costs more than a re-platform of the storefront. The main cost components are data migration for catalog, orders, customers and integration records, rebuilding the storefront against a different API, and reconnecting payment and fulfillment integrations. Medusa and Vendure both expose their data through their own module or entity models and service layers, while Saleor exposes its data through a GraphQL API with webhooks and apps. Each of those shapes means the export, mapping and reconciliation work starts from a different place, so the cost of leaving one platform depends on how cleanly its data can be pulled out and reloaded into the next.
Custom plugins, modules and extensions written for one framework do not transfer directly to another. A Vendure plugin that overrides services and strategies in NestJS, a Medusa module or workflow that depends on its module container, and a Saleor app that reacts to webhooks each need to be rewritten in the target's model. The GraphQL or REST choice affects the storefront rebuild more than the data move: a storefront built on Saleor's or Vendure's GraphQL schema, or on Medusa's REST routes, has to be re-pointed and retested against the new API, even if the product data itself maps cleanly. License terms also matter at exit. A plugin distributed under GPLv3 or a commercial agreement may carry obligations that a custom build does not, so legal review should happen before code is moved or reused.
Ask any implementation partner for a written migration scope before committing. The scope should name which entities move (products, variants, prices per channel, orders, customers, addresses, gift cards, promotions), how historical orders and tax records are retained, which payment gateways and fulfillment providers must be reconnected and tested, and who owns each mapping decision. Ask for the work to be split into one-time items such as data mapping, storefront rebuild and cutover rehearsal, and any recurring items such as running parallel systems during a transition. Confirm with the vendor and your own environment how each platform's export and API limits affect large catalogs before you commit.
Questions buyers ask before choosing Medusa, Saleor or Vendure
How much does a self-hosted headless commerce deployment cost to run?
The software licenses for the core frameworks are free to self-host, so the recurring cost is infrastructure, people and support. For Medusa, the core is MIT licensed and self-hosting needs PostgreSQL, Redis, S3 for file storage, and two Medusa instances, one in server mode and one in worker mode. For Saleor, you run the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. For Vendure, self-hosting is free, and the stack is Node.js with PostgreSQL, MySQL, MariaDB or SQLite. The main cost drivers are the number of services you operate, traffic and search load, backup and monitoring, and the engineers who patch and upgrade each release. Ask each vendor and your DeployOpen scope for a written breakdown of one-time versus recurring items.
How long does a headless commerce implementation take?
No fixed duration applies to all projects, because the timeline depends on the catalog model, the number of channels, payment and tax integrations, and how much storefront work is included. Medusa, Saleor and Vendure each expose a GraphQL or REST commerce API, so the storefront and integration layers often take the most time. Checkpoints that tend to move the schedule include B2B account rules, multi-warehouse fulfillment, promotion logic and data migration from an existing platform. DeployOpen works from a written scope with agreed deliverables and timelines before work starts, so ask for the schedule to be tied to those items rather than to a generic estimate.
Can our team implement Medusa, Saleor or Vendure without outside help?
Yes, if the team has the skills for the chosen stack and the capacity to operate it. Medusa and Vendure are built with TypeScript on Node.js, so a team with strong TypeScript and Node.js experience has a direct path. Saleor is built on Python and Django, so it suits a team that already runs Django or Python services. The skills you need beyond the language include PostgreSQL administration, Redis or Valkey operations, container or runtime deployment, and upgrade discipline. An outside partner can carry implementation, hardening, backup and upgrade work under a fixed scope, or as a retainer after go-live. Confirm your skill gaps in a written assessment before choosing a path.
Does B2B commerce require Medusa Enterprise or a paid Vendure plan?
It depends on which B2B features you need and whether they are open or commercial. Medusa's core is MIT licensed, but Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Vendure's paid Starter, Growth, Scale and Enterprise plans add B2B features such as company accounts, quotes, contract pricing and approvals, along with single sign-on, audit logs and a commercial license. Medusa's README also lists B2B stores among supported use cases, so confirm with MedusaJS which B2B capabilities sit in the open core. Saleor's B2B needs should be checked against its own feature set and the apps you plan to use. Ask each vendor to map your required B2B features to licenses and editions in writing.
Is Saleor a good fit for a team without Python experience?
Saleor can work for a team without Python experience, but the fit depends on who will maintain the backend. Saleor is built on Python and Django, and it extends through webhooks, apps, metadata and API extensions rather than in-process plugins. A team that writes mainly TypeScript can build storefronts and integrations against its GraphQL API without writing Python, but operating and customizing the core will need someone comfortable with Django. Consider whether you will keep the core unmodified and extend it through apps, or whether you need deeper backend changes. Confirm the skills you need in a scoped assessment before selecting Saleor.
Which license terms affect commercial use of these platforms?
Each license sets different obligations, so check them with counsel before committing. Medusa's core is MIT licensed, and its Enterprise Edition features need a commercial agreement. 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 allows Vendure plugins to be distributed under a different license, but you should confirm how that applies to your custom code. If you distribute modified versions or host the software for others, the copyleft terms of the GPLv3 matter more. Ask each vendor for written confirmation of how their terms apply to your use case.
How do the upgrade cycles compare when we self-host?
Each project publishes its own release cadence, so compare the latest versions and your upgrade process rather than assuming a shared schedule. Medusa v2.21.2 was released on September 28, 2026, and Vendure v3.8.0 was published on October 12, 2026, after v3.7.4 on October 5, 2026. Saleor 3.23.42 was released on October 16, 2026. Medusa runs database migrations through a predeploy script before each startup, which should be part of your upgrade runbook. Ask each vendor for its supported version policy, its migration guidance and how breaking changes are announced, then plan a staging rehearsal before any production upgrade.
How DeployOpen helps teams choose and implement a headless commerce platform
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Medusa vs Saleor vs Vendure decision, that means turning a shortlist into a written scope for the platform your team actually picks, with the hosting stack, licensing position and upgrade path confirmed before any build work starts.
How we scope
- Confirm which license position applies to your planned use, including Medusa's commercial Enterprise features and Vendure's GPLv3 default.
- Map the required services for your chosen platform, such as PostgreSQL, Redis, Valkey, Celery or separate worker instances, against your environment.
- Agree the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
How we build
- Set up the chosen platform in your own cloud account, data center or air-gapped network, with environment-based configuration throughout.
- Build the required extensions through the platform's own model, such as Medusa modules, Saleor webhooks and apps, or Vendure plugins, without forking the core.
- Test the storefront, admin, payment and fulfillment paths, including the security testing needed before go-live.
How we hand over
- Document the deployment, configuration, secrets handling, migration steps and health checks so your team can run the platform independently.
- Walk your engineers through the upgrade procedure for the release line you select, including database migrations and rollback steps.
- Deliver backup and restore procedures and the operational runbooks agreed in the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Plan upgrades against each vendor's published release and support windows, which you should confirm directly with the vendor before committing.
- Ask for a quote built from the written scope, listing build, integration, testing and retainer components as separate line items.
