"Production-ready" is doing a lot of work in that question. Ready for what, exactly, and ready compared to what? A fairer version of the question is: if you put Medusa into production today, what would actually go wrong, and is that risk yours to manage or the framework's to fix?
What's genuinely solid
Medusa v2's core commerce domain (products, variants, pricing rules, carts, orders, fulfilment, regions) is the most mature part of the project. It has been through multiple major versions, the data model has settled, and the module/workflow architecture that replaced the old plugin system in v2 is the current, supported way to extend it. The admin dashboard covers the operations a commerce team actually does day to day: managing inventory, processing orders, configuring shipping and tax, running promotions.
That bar is met. Teams are running real storefronts, B2C, B2B, subscription, and multi-region, on Medusa today, including several of the engagements we've shipped.
What still needs engineering judgment
Medusa is a framework, not a managed platform, and that distinction is where most "is it ready" anxiety actually comes from.
- Hosting is your job. Medusa doesn't run itself. You (or your agency) provision the Node service, Postgres, Redis, and the worker process for background jobs. Get this wrong (undersized database, no connection pooling, workers competing with the API for resources) and performance problems look like "Medusa is slow" when they're actually "the deployment wasn't sized for the load."
- Fewer pre-built integrations than Shopify's app store. Reviews, loyalty programs, subscription billing, and ERP sync all have a Shopify app built by a third party already. Medusa has a smaller but growing ecosystem, and a gap often means writing a module rather than installing a plugin.
- Upgrades require reading release notes. A self-hosted framework won't silently upgrade under you the way a SaaS platform does, which is good for stability and bad for anyone hoping to never think about versions again.
None of this makes Medusa not production-ready. It makes it a framework that assumes a competent engineering team on the other end, which is a different risk profile than "immature software," and the two get conflated constantly in agency marketing that's selling against it.
Who should actually wait
If your team has no backend engineering capacity and no plan to hire or contract one, a self-hosted framework of any kind, Medusa included, is the wrong call regardless of its maturity. That's not a Medusa-specific caveat; it's true of any open-source platform you run yourself. In that case a managed platform (Shopify, BigCommerce) genuinely is the better fit, and we'll tell you that directly rather than selling you an architecture your team can't operate. We cover that trade-off in more depth in Medusa vs. Shopify for headless commerce.
Deciding whether Medusa fits your team?
Tell us your current stack and who'd own it after launch. We'll give you a direct answer, including when the honest answer is 'not yet.'
Ask us →The rule
Medusa the framework is production-ready. Whether your production rollout is ready depends entirely on whether the operational side (hosting, monitoring, a team that owns deployments) got the same attention as the feature build. Agencies that skip that side and ship a demo-quality deployment are the actual source of most "Medusa broke in production" stories, not the framework itself. If you want the operational side built in from day one, that's what our Medusa development engagements are structured around.