Open-source commerce on Node.js
Build modern, composable commerce withprofessional MedusaJS development services
Medusa gives you commerce modules, an admin and a framework for adding your own logic, in TypeScript on Node.js and PostgreSQL. It suits a business whose selling does not fit a standard store, and whose team is happy to own an application. We build on it and run it.
MedusaJS development work
Medusa projects have a clear shape: new domains go in modules, multi-step processes go in workflows, and the admin is extended rather than rewritten.
Custom modules
A module is a package for one domain or integration, with data models that become tables and a service to manage them. It is registered in medusa-config.ts, with migrations generated by the CLI. Warranties, quotes or a loyalty ledger would go here.
Workflows with rollback
Each workflow step can carry a compensation function that undoes its change if a later step fails. That matters when an order touches payment, stock and an ERP, because a partial failure can be unwound rather than cleaned up by hand.
Admin extensions, and their limits
Widgets add sections to existing pages, and UI routes add new pages. You cannot change the layout or design of existing pages, or the logo. If staff need something very different, Medusa points to building a separate admin on its Admin API.
Storefronts
The installer can add a Next.js starter storefront in a monorepo. We build from it, or against your existing front end through the store API routes. Medusa has no theme system to fall back on, so the front end is a real project.
Hosting Medusa
Medusa recommends its own Cloud, with autoscaling. If you self-host, you take on the items below, and we set them up.
Two instances, not one
Production means a server instance for API requests and the admin, and a worker instance for scheduled jobs and subscribers, set through MEDUSA_WORKER_MODE. Hosts need to run both, with a plan offering at least 2 GB of RAM.
PostgreSQL and Redis
PostgreSQL holds the data, and Redis holds sessions and backs production modules such as caching, the event bus, the workflow engine and locking. The default modules are for development only, and replacing them is easy to overlook.
Node.js version
The docs ask for Node.js 22.22 or later, on LTS releases only, and version 24 LTS or lower if you use the Next.js starter. We pin it in the deployment, so the host cannot change it unexpectedly.
Deployment order
Migrations and link syncing have to run before the application starts, and COOKIE_SECRET and JWT_SECRET must be set, or startup fails. The admin is built statically against the server's address, so that has to be right at build time.
When MedusaJS is the right choice, and when it is not
Medusa rewards teams who want to own their commerce code, and it penalises those who just want a store.
A good fit when
- Your selling logic does not fit a standard store: quotes, rentals, marketplaces or unusual order flows.
- You want your commerce code in TypeScript, under your own control.
- You can fund a front end and ongoing maintenance.
A poor fit when
- A theme and a few apps on a hosted platform would meet your needs.
- Staff expect to reshape the admin, or install plug-ins themselves.
- You have no developers, in-house or retained, after launch.
How MedusaJS projects run
We decide early what is a module, what is a workflow and what is left unbuilt.
Domain review
We map your order journey against Medusa's commerce modules, to find what they cover and what needs a custom module.
Architecture and scope
Modules, workflows, storefront, integrations and where it runs are written down, with a price or a phased budget.
Build in stages
Modules and workflows come first, with tests including failure paths. The storefront and admin widgets follow, with regular demos on a staging environment.
Deploy and keep current
We set up server and worker instances, or Medusa Cloud, along with production modules. Medusa releases often, so your plan needs regular upgrades.
Named projects and how we engage
No MedusaJS projects are named on this page. Most of our work is delivered under NDA, so many projects cannot be named.
Medusa projects tend to have parts that are hard to define up front, so we usually phase them, or add developers to your team. We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment. Medusa's core is MIT-licensed, while its Enterprise Edition materials need a commercial agreement with Medusa, so we check that any feature you want is on the side you expect.
MedusaJS questions
Should we self-host Medusa or use Medusa Cloud?
Medusa Cloud removes the infrastructure work and adds autoscaling, at a cost. Self-hosting gives you control and makes you responsible for scaling and maintenance. If you have no one to run it, we would suggest Cloud, or a maintenance arrangement.
Is Medusa free?
The core is open source under the MIT licence, on an open-core model. Enterprise Edition materials need a commercial agreement. Budget also for hosting, and for the development work, which is the larger cost on any Medusa project.
Can you upgrade us from Medusa v1?
We review the code first, because the current 2.x line is organised around its framework, modules and workflows, and older custom code has to fit that. Treat it as a project with its own scope and testing, not a package bump.
How does Medusa compare with Shopify?
Shopify runs the platform for you, and you customise within its rules. Medusa gives you the code and the responsibility. If Shopify's rules do not block anything you need, it is usually cheaper to run.
Related services
Tell us about your Medusa project
Describe how you sell and what a standard platform will not do. We will tell you whether Medusa is worth it, and what it would take to build and run.
We reply within one business day (IST).