Medusa Limitations: What Medusa Cannot Do in 2026

Medusa has earned real credibility among engineering teams evaluating open-source headless commerce. Its v2 architecture, released October 23, 2024, organizes commerce into composable modules, workflows, and a React admin dashboard, all in Node.js and TypeScript, with hosting either self-managed or on Medusa Cloud, which opened self-serve signup on October 2, 2025. The core framework carries a $0 license fee, and for teams that want to own every line of their commerce stack, that control is precisely the point.

The considerations emerge in what the framework leaves to the merchant. Capabilities that arrive turnkey on managed platforms — subscription billing, B2B account structures, multi-vendor marketplaces, sales reporting, storefronts — are delivered as code recipes and starter templates that a development team assembles and then maintains. As of 2026, the repository is open-core rather than fully MIT, with role-based access control and SSO carved out under a proprietary Enterprise license. And the release cadence is brisk: minor versions ship roughly monthly, and recent minors routinely include explicit breaking changes.

None of this makes Medusa a poor framework. It makes Medusa a framework — a starting point whose distance from a production commerce operation is measured in engineering time. Understanding that distance in specifics, rather than generalities, helps merchants decide whether the assembly model fits their team and their roadmap.

Key Takeaways

• Medusa's official recipes for subscriptions, B2B, and multi-vendor marketplaces all resolve to custom TypeScript development — custom modules, workflows, and daily scheduled renewal jobs — rather than turnkey features
• Production self-hosting requires PostgreSQL, Redis, at least 2GB of RAM, and a two-instance server-plus-worker deployment, with Redis-backed cache, event bus, workflow engine, and locking modules swapped in for the development defaults
• Medusa v2 shipped October 23, 2024 with no automated migration from v1, whose last release was January 20, 2025 with no published end-of-life policy; recent v2 minors (v2.16.0, v2.18.0, v2.19.0) each include explicit breaking changes
• The admin dashboard's layout, design, and existing pages cannot be customized beyond widget injection, and no built-in sales reporting exists — the Analytics Module only forwards events to providers like PostHog or Segment
• RBAC and SSO are proprietary Enterprise Edition features excluded from the MIT license, making the repository open-core as of 2026
• Medusa Cloud starts at $29/month without autoscaling, backups, or custom domains, and Medusa's own pricing examples show $359 to $599 per month on its $299 plan once usage overages are included

Recurring Revenue as a Development Project: Medusa's Subscription Recipe

Subscription commerce is the clearest illustration of Medusa's assembly model. The framework ships no subscription billing engine; its official Subscriptions Recipe is, in effect, a guide to building one.

What the Recipe Actually Asks Teams to Build

The recipe directs developers to create a custom subscription module with its own data models, module links tying subscriptions to orders and products, custom workflows and API routes, and 'scheduled jobs that check daily for subscriptions that need renewal.' Payment handling is custom too: the documentation notes that while Medusa provides a Stripe Payment Module Provider, 'it doesn't handle subscriptions,' so teams that want Stripe to manage renewals must write a dedicated Stripe subscription provider instead of the daily renewal jobs. Admin widgets for managing subscriptions and the storefront UI customers use to pause or cancel must also be built by hand. Every one of those components then lives in the merchant's codebase, maintained through each Medusa release.

When Billing Logic Comes Native

Swell treats recurring revenue as a platform feature rather than a project. Native subscriptions are included on all plans: physical or virtual products sold on flexible billing intervals, separate invoicing and fulfillment schedules, automatic payment retry with dunning, trials, and mixed carts that combine subscription and one-time items in a single order. Subscription plans are configured from the dashboard, and ongoing management happens in the same place merchants run the rest of the store. Payments flow through an encrypted card vault directly with the payment gateway — no custom renewal jobs to schedule or monitor.

Wholesale and Marketplace Complexity: Where Starters Stand In for Platform Features

B2B and multi-vendor commerce are both achievable on Medusa, and both arrive the same way: a recipe, a starter template, and a to-do list for the development team.

Company Accounts, Order Splitting, and Uncovered Payouts

Medusa's native primitives — customer groups, price lists per group, sales channels, and publishable API keys — cover wholesale pricing basics. Beyond that, the documentation states that 'B2B use cases often require more complex customer management' and recommends 'creating a custom module' for data models such as Company and Employee. Medusa's practical answer is a ready-to-use B2B starter on GitHub that teams install and then extend in code; quotes and approval workflows are not documented as native platform features. The Marketplace Recipe asks for more still: vendor data models, module links between vendors and products, and a custom workflow that 'splits the order into multiple orders, one for each vendor' by replicating the Complete Cart API route. Vendor payouts — the part marketplaces are ultimately judged on — are not covered by the recipe at all and must be designed independently.

B2B and Marketplace Structures in the Core

Swell builds these structures into the platform itself. Native B2B and wholesale features include customer group-based pricing, custom payment terms, quotes and draft orders via API, and custom fields across all data models for company-specific attributes. Multi-vendor marketplace capabilities — including split payment functionality — are part of the core platform rather than a recipe and a to-do list left for the development team.

Infrastructure Ownership: The Operational Bill Behind a Free Framework

Medusa's $0 license fee is real. So is everything the deployment documentation assigns to whoever runs it.

The Production Checklist for Self-Hosters

Official deployment docs require PostgreSQL for application data and Redis for sessions, caching, and events, specify hosting with at least 2GB of RAM, and prescribe a two-instance deployment: one process serving the API and admin, a second running in worker mode for scheduled jobs and subscribers. Development defaults are not production-safe — the checklist swaps in Redis-backed cache, event bus, workflow engine, and locking modules, S3-compatible file storage, and a third-party email provider such as SendGrid. The docs also assign database migrations, CORS and secret configuration, health-endpoint monitoring, and all scaling and maintenance to the operator — and pitch Medusa Cloud as the way to 'avoid the complexities and challenges of self-hosting.'

What Managed Hosting Does — and Does Not — Absorb

Medusa Cloud manages servers, databases, object storage, GitHub-triggered deployments, and backups, but none of the application layer: merchants still own, build, and maintain every backend customization and the storefront. The entry $29/month Develop plan excludes autoscaling, automatic backups, and custom domains; those arrive at Launch ($99/month), with background workers and priority support at Scale ($299/month). Usage overages apply on every tier — compute at $0.16/hour, database storage at $0.50/GB-month, long-lived environments at $60/month each — and Medusa's own published examples total $359 to $599 per month on the $299 base plan. Swell sits at a different point on this spectrum: as a managed platform, hosting, scaling, and security patching are Swell's responsibility, and the features merchants configure are operated for them rather than deployed by them.

The Upgrade Treadmill: Breaking Changes on a Monthly Cadence

A framework a business builds on is also a dependency the business inherits. Medusa's version history shows what that inheritance can cost.

From v1 to v2: A Re-Platform, Not an Upgrade

Medusa v2, released October 23, 2024, is by Medusa's own description a complete rewrite — 16 months and 3,500+ pull requests — with breaking changes across the platform. There is no automated migration path: the v1 database 'will not be compatible,' products move via admin export and import, and other data 'will probably need to be migrated manually through custom scripts.' Several v1 plugins, including Klarna, PayPal, and Shopify, were removed. Meanwhile, v1 is effectively dormant: its last stable npm release (1.20.11) shipped January 20, 2025, with none in the roughly 19 months since and no published end-of-life or security-patch policy for merchants still running it.

Release Velocity as a Recurring Line Item

v2 moves quickly — v2.16.0 on June 18, 2026, v2.17.0 six days later, v2.18.0 in July, and v2.19.0 on August 13, 2026 — and recent minors routinely carry explicit breaking-change sections; v2.19.0 alone breaks existing admin customizations through its Vite 7 and React Router 7 upgrades. Teams budget upgrade engineering as a standing cost. The managed alternative shifts that budget entirely: on Swell, platform updates and patching are the platform's job, and customization happens against the unified Backend API — the same API that powers Swell's own dashboard and checkout — rather than inside framework internals that each release is free to rearrange.

The Back Office Gap: A Locked Admin Layout and No Native Sales Reporting

Merchant teams spend their working day in the admin. On Medusa, that surface is both fixed and quiet.

Widget Injection Instead of Customization

Medusa's documentation is direct: 'You can't customize the admin dashboard's layout, design, or the content of the existing pages (aside from injecting widgets),' and the Medusa logo cannot be changed. Extension means injecting React widgets into predefined zones or adding new pages; for heavier needs, the documented answer is to 'build a custom admin dashboard using Medusa's Admin API routes' — rebuilding the back office outright. Reporting is thinner still: as of publication, Medusa ships no built-in merchant-facing sales analytics, and its Analytics Module exists to forward event data to third-party providers such as PostHog or Segment. Medusa Cloud's April 2026 monitoring dashboard covers infrastructure metrics — CPU, memory, HTTP traffic — not revenue or orders.

An Admin Built on the API Developers Already Use

Swell's dashboard runs on the same Backend API exposed to external developers, which means any native functionality can be replicated or customized rather than merely decorated around the edges. The model editor and custom fields extend every data model from the dashboard itself, and unlimited variants and options are managed through both dashboard and API — merchandising changes that require no developer involvement at all.

Storefronts From Scratch: No Themes, No Builder, No Hosted Option

On Medusa, the storefront is not a feature of the platform. It is a second software project.

Every Storefront Is a Frontend Engineering Project

The storefront documentation states it plainly: developers 'build your storefront from scratch, or build it on top of the Next.js Starter storefront,' with the storefront installed, built, and hosted separately from the backend. There is no hosted storefront, no theme marketplace, and no visual builder; design, UX, and frontend hosting belong entirely to the team (Medusa Cloud can host the storefront alongside the backend, but the code is still the merchant's to write). For a single brand, this is one project. For a business running several brands or regional stores, it multiplies.

Frontend Freedom Without the Obligation

An API-first managed platform separates the freedom from the obligation. Swell supports any frontend framework, and its Checkout API lets teams build fully custom checkout and payment flows using the same APIs behind Swell's hosted checkout — custom when wanted, ready-made when not. Native multi-store architecture runs multiple storefronts and brands from one account, and stores selling globally can price across 230 currencies with explicit per-currency price rules and localize content in 170 languages through multi-language support.

The Integration Ecosystem: npm Packages, Community Plugins, and Gateway Constraints

Medusa describes its integrations directory as curated from npm — an accurate description with real operational consequences.

A Directory Curated From npm

Integrations are npm packages installed and configured in code across roughly 11 categories, mixing a small set of official 'By Medusa' plugins — Stripe, at over 500K monthly npm downloads, is the flagship — with community-maintained packages, many showing under 1,000 monthly downloads, a signal worth reading as maintenance risk. Capabilities that are switch-on features elsewhere — tax calculation, email marketing, CMS content via Contentful or Sanity, search via Algolia or MeiliSearch — are integrations to wire up, and sometimes custom modules to write. Payments carry a subtler constraint: Medusa itself does not gate what merchants sell, but its default gateway is Stripe, whose policies prohibit or restrict several product categories. Merchants in those categories typically integrate a high-risk-friendly gateway through a custom Payment Module Provider — permitted by the architecture, but custom development.

Built-In Services and a Payment Abstraction Layer

Swell ships 40+ built-in service integrations, including Klaviyo, Omnisend, Mailchimp, ShipStation, Algolia, and Contentful, with tax handled natively through Avalara AvaTax and TaxJar alongside custom tax rule groups by location and product. The payment abstraction layer integrates Stripe, PayPal, Braintree, Authorize.Net, and Amazon Pay, with Swell handling PCI compliance — and that gateway breadth matters most to merchants in restricted or high-risk categories, who need alternatives rather than workarounds.

Open-Core Boundaries: Enterprise Licensing and the Support Ladder

In 2026, Medusa is no longer simply MIT-licensed software with a community around it. Two commercial boundary lines now run through the project.

RBAC, SSO, and Help Behind Commercial Agreements

The first line runs through the repository. Medusa's LICENSE file now applies MIT 'except for the Enterprise Edition materials,' and ENTERPRISE-LICENSE.md names role-based access control and SSO as Enterprise features whose code sits in the public repository but is excluded from the MIT license; enabling an Enterprise feature flag 'constitutes a representation' of a valid commercial agreement. Open-source deployments otherwise treat invited admin users as full administrators unless roles are custom-built. The boundary does move in both directions — the Gift Card and Store Credit modules, previously Cloud-only, were open-sourced in April 2026 — but the direction of RBAC and SSO matters for teams with compliance requirements.

The second line runs through support. Open-source users rely on a community Discord of 13,000+ developers handling roughly 2,000 conversations a month, moderated by a three-person volunteer team — no tickets, no response-time commitment. Priority support begins at the $299/month Scale plan; SLA-backed response times, a 99.99% uptime guarantee, and a dedicated support engineer are Enterprise-only, and the Cloud Terms of Service commit to 'commercially reasonable efforts' while noting Medusa 'does not warrant that all issues will be resolved.'

What a Managed Platform Relationship Covers

A managed platform draws the commercial line elsewhere: the fee covers operating the platform itself, so hosting, scaling, and security patching sit with Swell rather than the merchant, and capabilities like subscriptions are included on all plans instead of being license-gated. On pricing, precision matters in the other direction too: Swell's plans use revenue-based fee structures that apply only above each plan's revenue threshold, with per-order overage fees beyond it — a different shape from per-hour compute math, and one worth modeling against projected volume. Teams evaluating a move can start with the help center documentation or engage implementation partners through Swell's experts directory.

Frequently Asked Questions

Is Medusa really free, and what does it actually cost to run?

The framework's license fee is $0 (MIT, with RBAC and SSO carved out under a proprietary Enterprise license). The real costs sit elsewhere: either self-managed infrastructure — PostgreSQL, Redis, 2GB+ RAM instances in server-and-worker pairs, S3-compatible storage, an email provider — or Medusa Cloud at $29, $99, or $299 per month plus usage overages such as compute at $0.16/hour and database storage at $0.50/GB-month. On top of hosting comes TypeScript development for the initial build and for a monthly release cadence in which minor versions regularly include breaking changes. Medusa's own Cloud pricing examples land at $359 to $599 per month before any development costs. There are no GMV or transaction fees on any Cloud tier.

Does Medusa support subscription products out of the box?

No. The official Subscriptions Recipe requires building a custom subscription module, module links, workflows, and daily scheduled renewal jobs. Medusa's Stripe Payment Module Provider explicitly 'doesn't handle subscriptions,' so the recipe's alternative path is building a custom Stripe subscription provider (or using a community plugin) instead — plus custom admin widgets and storefront UI for subscription management. For businesses where recurring revenue is central, this is a meaningful build to scope before committing.

Can Medusa run B2B or a multi-vendor marketplace?

Both are possible, and both are assembled rather than turnkey. For B2B, native price lists, customer groups, and sales channels exist, but company and employee accounts require creating a custom module, and Medusa's practical answer is a B2B starter template on GitHub to install and extend; quotes and approval workflows are not documented as native features. For marketplaces, the recipe requires building vendor data models, module links, and a custom workflow that splits each order into per-vendor orders — and vendor payouts are not covered by the recipe at all.

What kind of support is available if something breaks?

Open-source users rely on a community Discord of 13,000+ developers and roughly 2,000 conversations a month, moderated by volunteers — no ticketing system and no response-time commitment. Priority support starts at the $299/month Scale plan, while SLA-backed response times, a 99.99% uptime guarantee, and a dedicated support engineer are Enterprise-only. The Cloud Terms of Service commit to 'commercially reasonable efforts,' state that Medusa 'does not warrant that all issues will be resolved,' and apply to Cloud services rather than the open-source framework.

Is Medusa v1 still maintained, and how hard is the migration to v2?

v1 is effectively dormant: its last stable npm release, 1.20.11, shipped January 20, 2025, with none since and no published end-of-life or security-patch policy. Migration to v2 has no automated tooling — the v1 database 'will not be compatible,' products can move via admin export and import, and other data 'will probably need to be migrated manually through custom scripts.' Several v1 plugins, including Klarna, PayPal, and Shopify, were removed in v2. Teams should plan the move as a re-platforming project rather than an upgrade — and, given comparable effort, weigh it against re-platforming options generally.