Makro PRO uses MedusaJS to orchestrate around 5,000 orders a day across a three-digit shop network. At the same time, over the last twelve months we have spoken to two German SMEs who deliberately cancelled their Medusa evaluation and continued to build on a suite solution instead. Both decisions were rational - and they explain what Medusa 2026 is really good for, and what it's not.
MedusaJS is an open source commerce framework written in TypeScript and based on Node.js. It provides a modular commerce backend with over 18 domain modules, a workflow engine, a React admin and a strict separation of storefront, admin and data management. The licence is MIT - no licence fee, no GMV participation.
This article provides a neutral overview with the details that are typically missing in marketing overviews: What does the framework do technically, for which scenarios is it worthwhile, and when should you keep your hands off it
What MedusaJS is - and what it isn't
Medusa launched in 2020 as an open source alternative to Shopify Plus and commercetools and was completely relaunched with version 2.0 on 23 October 2024. With over 33,000 GitHub stars and around 150,000 NPM downloads per month (as of May 2026), Medusa is the most active open source commerce project ever.
Two categorisations help to correctly locate the framework:
Medusa is not a shop system in the classic sense. It is a commerce backend with a modular architecture. What you understand by "shop" - storefront, product detail page, checkout UI - Medusa does not deliver out of the box. Instead, there is an official Next.js starter, community starters for other frameworks and a REST/GraphQL API layer to which you can dock your own frontend. If you're looking for a ready-to-sell shop like Shopify or Shopware, with Medusa you get a framework - not a platform.
Medusa is not a pure "headless" product. It comes with a complete admin panel written in React, which has been fundamentally revised with Medusa 2.0. Order management, product maintenance, promotions, B2B accounts, multi-warehouse - everything available, everything expandable.
In practice, Medusa does not compete with Shopify or WooCommerce, but with commercetools, Saleor and customised composable stacks. The comparison class is enterprise-orientated, but the entry point is open source.
Architecture diagram: MedusaJS backend with modules, module links between domains, workflow engine, admin dashboard and separate storefront.
The architecture in detail
With Medusa 2.0, the originally monolithic backend has become a truly modular architecture. This is more than just a marketing term - it has tangible consequences for maintenance and expandability.
Commerce modules without hard database coupling
Medusa divides each business domain - Products, Carts, Orders, Payments, Pricing, Inventory, Promotions, Customers - into an independent module. The core contains around 18 commerce modules. Crucially, there are no foreign key relationships between these modules at database level. Links are mapped via so-called module links, which are resolved at runtime.
What sounds like architectural theory is tangible in comparison: In Shopware, the customer is closely linked to the order, both live in the same database with constraints. In Medusa, you can replace the customer module with a Salesforce connection without touching the order table. Two practical scenarios:
Selective adoption. A PIM-driven manufacturer only adopts the Order and Pricing module from Medusa and continues to flow product data from its existing PIM. No major data migration as a prerequisite.
Module replacement. If the supplied pricing module is not sufficient - for example because a complex graduated pricing model with contract individuality is needed - you can replace it with your own implementation without touching the rest of the system.
This is a relevant feature for grown SME stacks with ERP, PIM and their own OMS. Classic suites often require you to either fully engage with their data model - or not at all.
The workflow engine
The workflow engine gets too little attention in most Medusa discussions, even though it is one of the strongest arguments in favour of the framework. Background: Anyone who has ever searched logs at three o'clock in the morning for a half-finished checkout knows the basic problem of multi-stage commerce processes. Stock reserved, payment authorised, but the ERP booking fails - and now?
Medusa models such processes as workflows consisting of atomic steps. The engine takes care of:
Compensation - if step 4 fails, steps 1 to 3 are rolled back cleanly, each with its own
compensatefunction.Retry logic - transient errors (e.g. payment provider timeout) trigger automatic retries with configurable backoff.
Idempotency - the same workflow does not run twice with multiple triggers; each step can provide an idempotency key-based guarantee.
A typical order placement workflow looks like this: validateCart → reserveInventory → authorisePayment → createOrder → triggerFulfillment. If triggerFulfillment fails because the interface to the WMS is currently not responding, the engine cancels the inventory reservation and releases the payment authorisation - and makes this traceable in an audit trail. If you want this mechanism in a classic shop system, you can build it yourself or supplement it with an external workflow tool such as Temporal.
Sequence diagram: Checkout workflow with five steps - automatic rollback through steps 1-4 in the event of an error in step 5.
Storefront, admin and hosting strictly separated
Architecturally, a Medusa installation is divided into three components that can be deployed independently:
Medusa backend - Node.js server with all modules.
Admin Dashboard - React-SPA, hosted in the backend or separately.
Storefront - completely decoupled from the backend; usually Next.js, but any frontend that speaks REST or GraphQL will work.
This separation is not an end in itself. It allows the frontend team to work at its own pace, the backend at its own - and for performance tuning for the storefront (edge caching, ISR, static pre-rendering) to take place independently of the commerce backend.
What MedusaJS is suitable for
Medusa is not an all-purpose tool. It shows its strengths in certain constellations.
B2B with complex pricing and account models. Customer-specific price lists, approved product ranges per account, multi-level order approvals - such requirements can be mapped cleanly in Medusa because the pricing and customer module are designed for multidimensionality by default. Makro PRO demonstrates its resilience: the wholesaler uses Medusa to orchestrate around 5,000 orders per day via a three-digit network of shops and distribution partners, with an annual GMV in the three-digit million range.
Marketplaces and multi-vendor setups. Medusa does not have a built-in marketplace mode, but thanks to sales channels, stock locations and module links, multi-tenant and multi-vendor architectures can be built with manageable effort.
Order orchestration beyond the classic web shop. If you don't see Medusa as a front store, but as an order backbone - for example to consolidate orders from several sales channels or as a hub between several ERPs - you can use it exactly where the modular data model is superior. Example: INSPIRED Pet Nutrition uses Medusa as AI-supported order management between two separate ERPs, thereby reducing the operational costs of order processing by 80 per cent.
Custom workflows that cannot be mapped in standard suites. Rental models, subscriptions with irregular delivery cycles, booking commerce, pay-per-use - all scenarios where suites quickly reach their limits. Concrete example: Viessmann operates a B2B rental platform for mobile heating and cooling appliances with Medusa.
Internationalisation with genuine multi-region logic. Multiple currencies, region-specific tax rates, shipping zones and payment methods are part of the core and are not cobbled together using plugins.
Comparison: For which scenarios MedusaJS fits - and for which it does not.
What MedusaJS is not suitable for
The other side is just as important.
Fast out-of-the-box shops. If you want to launch a B2C shop in four weeks and don't have a DevOps team within reach, you're better off with Shopify, Shopware or a cloud suite. Medusa requires someone to design the front end, run the hosting and write the integrations.
Teams without JavaScript/TypeScript depth. All customising - new modules, custom workflows, admin extensions - is done in TypeScript. A PHP-heavy team can operate Medusa, but cannot expand it efficiently.
Marketing teams that expect a WYSIWYG frontend. Unlike Shopware or Shopify, there is no built-in "Shopping Experiences" tool. Storefront editing runs via the frontend framework, not via the admin panel.
Very small product catalogues with classic B2C needs. If you sell 50 products and need standard functionality, you pay a complexity tax with Medusa that doesn't pay for itself.
Total cost of ownership - honestly calculated
Open source doesn't mean free. Even if the licence is zero euros, real costs are incurred in four areas:
Hosting. Self-hosting on a platform such as Railway, Render or DigitalOcean realistically starts at €35-110 per month for a lean setup with backend and database.
Medusa Cloud. Available as a self-service since October 2025. As of 2026, the plans are $29 (Develop), $99 (Launch) and $299 (Scale) per month.
Development and maintenance. This is the largest item. Experience has shown that a concrete example setup takes 60-120 days to implement and has a budget of between €80,000 and €130,000.
Third-party systems. Medusa itself has no search engine, no in-built CMS and no mailing solution of its own. Algolia, Meilisearch, Sanity, Postmark - everything is optional, everything adds up.
The statement that Medusa saves 30-50 per cent development time is only half true. If you have to build a custom platform anyway, you will get there faster with Medusa than with a fresh start. Compared to a suite solution with a ready-made frontend, Medusa is not a leap in efficiency - but a conscious investment in control and flexibility.
Cost distribution: Where the TCO is really incurred with MedusaJS - hosting, development, third-party systems and ongoing maintenance.
Cloud or self-hosting?
This question divides the community. A few rules of thumb from practice:
Self-hosting is suitable if there is an internal DevOps team that is used to running Node.js services in productive operation - including monitoring, backups, scaling and security updates.
Medusa Cloud fits if time-to-value counts, there is no in-house DevOps setup or your team should focus on product development instead of infrastructure.
A hybrid form - cloud for staging, self-hosting for production or vice versa - is possible, but organisationally more fragile than it looks on the whiteboard.
Decision matrix: self-hosting vs. Medusa Cloud - depending on time-to-market and internal DevOps capacity.
What a realistic start looks like
In our experience, a Medusa evaluation runs through three phases:
Phase 1 - Technical proof of concept. Four to eight weeks, fixed scope: standard storefront, a payment provider, an ERP connection, a clearly defined use case.
Phase 2 - MVP with real traffic. Expansion of the PoC to a minimal but production-ready version. Duration: two to four months.
Phase 3 - Rollout and expansion. AI-supported search, personalisation, multi-region expansion, marketplace components or connection to agentic commerce endpoints.
The most common misjudgement: skipping phase 1 and starting directly with the MVP.
Conclusion: Where Medusa stands in 2026
Medusa made the leap from the "interesting but risky" state in 2024 with version 2.0 and in 2025 with the official cloud offering. Enterprise implementations such as Viessmann, Makro PRO and INSPIRED Pet Nutrition prove that the framework also works under real pressure.
Nevertheless, Medusa is not a mass solution. If you are looking for a flexible, permanently expandable commerce backend for complex requirements - and have the technical team to utilise this freedom - Medusa is one of the most mature open source frameworks on the market. If you want to sell quickly and don't want to design the front end yourself, you're better off with a classic suite.
The right question is rarely "Medusa or Shopware?", but rather "What problems do we want to solve and which tool has the fewest breaking points for precisely these problems?".