When commercetools or Medusa is the better fit for your commerce stack
Choose Medusa when your organization is ready to run a commerce backend itself and wants the code, data and deployment under its own control, and choose commercetools when you want a managed, API-first SaaS that a vendor operates for you. A renewal, a licensing change, a residency requirement or lock-in concern usually triggers the review, but the answer depends on who will operate the platform after launch. Medusa fits teams with engineers who can own a Node.js and TypeScript service, a PostgreSQL database and a Redis instance, and who accept that uptime, upgrades, backups and security patching move to their side of the line. commercetools fits teams that prefer to buy that operating burden and rely on the vendor's regional hosting and service commitments, which you should confirm in writing against your own requirements.
Three factors should drive the decision. First, measure how much custom logic must live in the backend. Medusa customizes through its module system, so pricing rules, workflows and integrations you write become code you maintain, while commercetools customization often runs through extensions and integrations that the vendor hosts and that you also maintain. Second, check which Medusa features your roles and access model need, because role-based access control features sit in the Enterprise Edition under a commercial agreement with MedusaJS, Inc., and that cost belongs in your comparison. Third, define your data control requirement precisely: a region choice in a managed service differs from running the platform in infrastructure you select. Ask each vendor for its written answer on hosting location, operator access and data export before you score the options.
Which option fits which scenario
This table matches common scenarios to the better fit between commercetools Composable Commerce and self-hosted Medusa. Read each row against your own staffing, hosting rules and feature list, because several answers depend on details only your environment can settle. The main takeaway is that Medusa rewards teams with Node.js and operations capacity, while a managed SLA or strict residency rule may point elsewhere.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| No in-house platform engineers | commercetools | Running Medusa means owning PostgreSQL, Redis, two Medusa instances, upgrades and backups. Confirm whether a partner or retainer would cover that work. |
| Node.js engineering group in place | Medusa | Medusa is built with Node.js and TypeScript, so existing engineers can extend modules and workflows directly. Confirm the team has capacity for ongoing operations. |
| Strict residency or sovereign hosting | Depends on environment | Self-hosting puts data in infrastructure you choose, but commercetools also offers regional options. Confirm which legal and sovereign requirements apply to your data. |
| Managed SLA required | commercetools | Medusa Cloud is a managed option, but a self-hosted deployment carries uptime responsibility inside your own operations. Ask commercetools and Medusa for their written availability terms. |
| B2B or marketplace build | Depends on requirements | Medusa supports B2B stores and marketplaces through its modules. Check whether the specific B2B pricing, approval or vendor features you need are in the core or in Enterprise Edition. |
| Role-based access control in the admin | Depends on licensing | Some RBAC features in Medusa require Enterprise Edition under a commercial agreement with MedusaJS, Inc. Ask for the exact feature list before deciding. |
How hosting and data location change between the two
commercetools runs Composable Commerce as a SaaS service in isolated regions on Google Cloud and AWS. Your organization chooses a region and commercetools operates the platform, including the infrastructure, patching and availability of the service. Your responsibility focuses on how your storefronts, integrations and internal users connect to that service and on what data you choose to send into it.
- Vendor-operated infrastructure: commercetools manages the hosting environment, so your team does not provision databases, caches or application servers for the commerce backend.
- Region selection: the region choice determines where customer and order data is stored under the vendor's model, so confirm the exact data categories covered by your chosen region.
- Contractual scope: data processing terms, subprocessors and support locations sit in your agreement with the vendor, not in your own network controls.
- Shared service boundaries: access to the platform is limited to what the vendor exposes, so custom network placement is not part of the standard service model.
- Exit dependency: your data leaves through the export paths the vendor provides, which shapes how you plan a move.
Confirm with commercetools which regions, data categories and subprocessors apply to your contract before you finalize any data residency decision.
Medusa can run in the client's cloud account, in a private data center or in an air-gapped network, because the framework is self-hosted software. Medusa also offers Medusa Cloud as a managed option. Each choice changes who controls the database location, backups, network paths and the place where payment and customer records physically sit. A self-hosted deployment needs PostgreSQL, Redis and object storage for files, so each of those services must sit inside the boundary you have approved.
- Client cloud account: you choose the region, account structure and network boundaries, and you provision PostgreSQL, Redis and S3-compatible storage yourself.
- Data center or air-gapped network: the same components run on your own hardware, and you control every outbound connection, including package and image sources.
- Medusa Cloud: the managed option moves hosting operations to the vendor, so review where it stores data before treating it as equivalent to your own boundary.
- Component locations: the database, cache, event and workflow services, and file storage must all match your residency rules, not only the application servers.
- Backups and replicas: copies of the database and object storage fall inside your residency scope and need the same controls as the primary data.
Confirm with MedusaJS, Inc. where Medusa Cloud stores and processes data, and map every component of your chosen deployment to a documented location.
On a hosted platform, the vendor operates the administrative plane and you configure roles for your staff. When you self-host Medusa, you also own the administrative accounts, the secret handling and the way staff sign in to the admin dashboard. Medusa requires a COOKIE_SECRET and a JWT_SECRET for the server and worker, so those values, along with database credentials, become part of your secrets process. Role-based access control features in Medusa's Enterprise Edition require a commercial agreement, so the access model you need should be checked against the edition you license.
- Admin authentication: you decide how staff sign in, whether through an external identity provider or local accounts, and you enforce multi-factor authentication where your policy requires it.
- Role model: confirm whether the features you need, such as granular roles for finance, merchandising or support staff, are in the community core or the Enterprise Edition.
- Secret management: store COOKIE_SECRET, JWT_SECRET and database credentials in a controlled secrets store and rotate them on a schedule you define.
- Service accounts: API keys and integration credentials for storefronts and back-office systems need owners, scopes and revocation procedures.
- Privileged operations: database access, migration runs and server access are administrative actions that need named accountability.
Confirm Medusa's RBAC, SSO and audit features, and which edition each requires, against the current Medusa documentation before you design your access model.
A hosted provider usually supplies some operational records and attestations for its service, but your own compliance program still needs evidence about your configuration, access and change history. When you self-host, you must collect and retain logs from the database, the Medusa server and worker, the reverse proxy, the cloud account and your identity provider. Auditors will ask for proof of who changed prices, who accessed customer records and how deployments were approved, and that proof has to come from systems you operate.
- Log sources: collect application, database, infrastructure and identity logs into a store with retention and access controls that you define.
- Change records: database migrations run through a predeploy step before startup, so keep records of each migration, the approver and the deployment that applied it.
- Access reviews: schedule periodic reviews of admin accounts, service accounts and privileged infrastructure access.
- Control mapping: map each control in your framework to the system, owner and evidence that supports it, without assuming the vendor covers it.
- Independent assessment: DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any audit reports or certifications.
Confirm with your auditor which evidence they accept from self-hosted systems and which records, if any, Medusa or commercetools can provide for the scope you need.
Where customization lives in each platform
commercetools keeps most commerce logic on its side and lets you attach your own code at defined points. Extensions are called when an API request is made, so they can validate or change a cart or order before it is saved, and subscriptions send your service a message after a change has happened. Your service receives and responds to those calls, but the platform controls the request lifecycle. In Medusa, custom logic sits inside your codebase. Modules own the data and logic for a domain such as carts, pricing or inventory, workflows chain steps together with rollback logic, and API routes expose new endpoints. The advantage is full control over behavior, with no vendor-imposed limits on what your logic can do. The cost is that every rule you add is code your team reads, tests, upgrades and debugs.
Custom code in Medusa has to respect the components that its production setup depends on. The deployment guide describes Redis-based caching, an event bus, a workflow engine and locking, plus S3 for file storage. A step that keeps state in process memory will fail as soon as a second server instance handles the next request, so workflow data belongs in the workflow engine and shared state belongs in Redis or PostgreSQL. Subscribers and scheduled jobs run in the worker instance, not the API server, so a handler written for one may not run where you expect. Any code that writes product images or exports to disk must use the S3 file module. Before go-live, run your custom workflows against two instances with Redis and S3 enabled in a staging environment, and confirm the behavior under concurrent inventory updates. Medusa deployment docs lists the production components to check.
Moving logic out of a SaaS platform changes who is on call for it. A commercetools extension that times out is an incident on the vendor's platform, with its own support path. In a self-hosted Medusa store, that incident is yours, so plan for monitoring of custom workflows, a rollback path for failed migrations and a testing routine for each framework upgrade. Before you start, inventory every extension and subscription, mark which ones are pure business rules and which depend on commercetools features, and decide which can become modules. Confirm with commercetools the current timeout and retry behavior of its extensions and subscriptions, since those determine how much of your logic must be idempotent. Your team should estimate maintenance work per custom rule before committing to the migration.
Which Medusa features may need the Enterprise Edition
Medusa's core commerce framework is MIT licensed, but some features sit behind a commercial agreement. The cards below cover where that boundary falls, what to settle with MedusaJS, Inc. before design starts, and how the managed option changes the picture for a team comparing it with commercetools.
The MIT core and the Enterprise line
The core commerce framework is MIT licensed, so carts, orders, product catalogs, pricing and inventory modules can be used, modified and self-hosted without a license fee from MedusaJS, Inc. Enterprise Edition features based on role-based access control are the part that requires a commercial agreement. Teams comparing this with commercetools should map each requirement in their backlog to either the open core or the Enterprise scope before they estimate the build.
Role-based access control needs a contract
Role-based access control is the only Enterprise Edition feature category confirmed for this comparison. If your merchandising, finance and operations teams need separate permissions in the admin dashboard, treat that as a commercial dependency rather than a configuration task. Ask whether the permissions you need are available in the open core, in Enterprise Edition, or only through custom code you would maintain yourselves.
Agreement terms with MedusaJS, Inc.
An Enterprise Edition license is a separate commercial agreement with MedusaJS, Inc., and its terms are not part of the MIT license. Confirm the license scope, how many environments it covers, whether it covers staging and disaster recovery copies, and what support obligations apply. Compare those terms with the commercetools subscription and add-ons, which are also negotiated and not published as a price list.
Review licensing before the design phase
Read the license files and Enterprise terms before you choose data models, admin workflows or permission schemes. Changing a permission model after storefront and back-office integrations are built is costly, because each integration assumes certain roles exist. A short written license review at the start of the project prevents rework that would otherwise surface during user acceptance testing.
Medusa Cloud versus self-hosting
Medusa is available as Medusa Cloud managed hosting or self-hosted, and the two options carry different operating responsibilities. Self-hosting puts the PostgreSQL and Redis databases, the server and worker instances, secrets and upgrades on your team or on a services partner. Managed hosting shifts much of that operation to the vendor, but you should confirm where data is stored, which regions are available and how it compares with your residency requirements.
Questions to put in writing
Before committing, request written answers on which features in your backlog are Enterprise only, the price basis and renewal terms, the upgrade path between Medusa versions, and what happens to your deployment if the agreement ends. Also ask how security patches are delivered to self-hosted customers. Keep the answers in the project file so that architecture decisions can be traced back to a written source.
What a self-hosted Medusa deployment needs to run
A self-hosted Medusa deployment needs two stateful services and two application processes before any storefront can call it. The stateful services are PostgreSQL, which holds commerce data, and Redis, which Medusa uses for caching, the event bus, the workflow engine and locking in production. The application side runs as two instances of the same Medusa application: one in server mode, which serves the API and admin dashboard, and one in worker mode, which handles background tasks. Medusa's deployment documentation, linked below, describes this split. Plan both instances, their configuration and their scaling from the start, because a single process that tries to do both is a common cause of stalled jobs under load.
Each instance needs its own database credentials, plus COOKIE_SECRET and JWT_SECRET values. Treat these as secrets in your secrets manager, rotate them under a documented procedure, and confirm that the server and worker receive the same database settings where they must share state. Medusa runs database migrations through a predeploy script before each startup, so your deployment pipeline must run that step once per release and must have a rollback plan for schema changes. Confirm who approves a migration, how you take a database snapshot before it runs, and whether your release tooling can stop a rollout if the migration fails.
Before you send traffic, check the deployment through the /health endpoint on the server, and wire the same check into your load balancer and monitoring. Then confirm the operational basics in your own environment: where PostgreSQL backups go and how often you restore-test them, how Redis persistence and failover are configured, where uploaded files are stored (Medusa's production setup uses S3), and what alerts fire when workers fall behind. Ask your platform team who owns on-call for these components. None of these items is optional in a production store, and each one moves to your staff once you leave a hosted commerce service.
Cost components on each side, one-time and recurring
The commercetools side is a subscription with add-ons that the vendor quotes, so the work is in knowing which components to ask about. The Medusa side is open source at the core, but the bill moves to database and cache hosting, instances, storage, integration and the people who run it. Each card below names one component, whether it is one-time or recurring, and what moves its cost.
commercetools subscription and add-ons
This is a recurring vendor fee for the Composable Commerce platform and any add-ons you select, and commercetools does not publish these prices in the sources used for this page. Ask for a written quote that lists each module, API usage tier, region and support level as separate lines, and confirm whether the price changes with order volume, API calls or the number of storefronts. Ask how renewal uplifts are capped, because those drive the multi-year total more than the first year does.
Medusa core and Enterprise Edition
The core commerce framework is MIT licensed, so there is no license fee for the framework itself. Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc., and that agreement is a recurring cost if your team needs those features. Check early which admin permissions, staff roles and audit needs depend on Enterprise Edition, and get that agreement's terms in writing before you design around it.
PostgreSQL and Redis hosting
A self-hosted Medusa deployment needs a PostgreSQL database and a Redis database, and both are recurring infrastructure costs whether you run them yourself or buy them as managed services. Managed hosting costs more per unit but removes patching and backup work from your team. Size these by data volume, traffic peaks and backup retention, and confirm with your cloud or data center provider how replicas and failover are priced.
Object storage for files
Medusa's production setup uses S3 for file storage, such as product images and uploads, so this is a recurring storage and request charge that grows with catalog size and media volume. Estimate it from the number of images per product and how often assets are served. Ask whether your provider charges separately for egress, because that cost can exceed storage on image-heavy stores.
Server and worker instances
A self-hosted Medusa deployment runs two instances: one in server mode for the API and admin dashboard and one in worker mode for background tasks. Both are recurring compute costs, and the worker can be sized separately from the API. Costs rise with traffic peaks, the number of environments (staging, production, preview) and the redundancy you require. Confirm the instance count and sizing with your platform team before you request a quote from any host.
Integration and migration work
Rebuilding extensions, payment and tax connectors, ERP and warehouse links, and the data migration from commercetools is mostly one-time work, billed as a fixed scope or as time and materials. Cost rises with the number of integrations, the complexity of product types and custom fields, and how many storefronts call the API. Ask for each integration to be listed separately in a scope so you can compare them against commercetools add-on prices.
Engineers who run the platform
The largest recurring cost is usually the people who run the platform: upgrades, database migrations at each deploy, security patches, monitoring and incident response. This cost depends on your in-house skills, on-call expectations and release frequency, and it does not appear on any vendor invoice. Estimate it by the roles you need (platform, backend, security) and whether you will buy ongoing support or retainer coverage, and compare that total with the commercetools bill.
What a move from commercetools to Medusa involves
The sequence moves catalog, customer, price and order data, along with extensions and integrations, from commercetools into a self-hosted Medusa stack that you run and verify before commercetools is switched off. Each step ends with a check that shows whether the next step can start.
Inventory extensions, integrations and data
Your commerce owner and developers list every commercetools API client, extension, subscription, custom type, payment, tax, search, ERP and fulfillment integration, and record which business process each one supports. Confirm which of these you will rebuild, replace or retire, and note which commercetools features your storefront calls directly. The step is complete when the inventory is signed off and every item has a target owner and a decision.
Export catalog, customers, prices and orders
Extract products, categories, customers, prices and orders from the Merchant Center or through the HTTP API, depending on what each export supports and its size limits. Keep the export scripts and their settings in version control so the extraction can be repeated before cutover. Compare record counts and sample records against the source to confirm nothing was dropped or truncated. Ask commercetools to confirm current export limits before you design the process.
Map product types and custom fields
Translate commercetools product types, attributes, variants, channels and price definitions into Medusa's product, variant, pricing, inventory and region concepts. Decide for each custom field whether it becomes structured data in a module, metadata on an existing record, or a field added to your own data model. Write the mapping as a specification with example records, and test it by importing a small sample into a staging database. The step closes when the sample shows the same sellable products, prices and stock as the source.
Rebuild extensions and integrations
Developers rewrite each commercetools extension and integration as Medusa modules, workflows, subscribers or scheduled jobs, and replace connectors that have no equivalent. Background work runs on the worker instance in a Medusa deployment, so confirm which logic must run there. Test each integration against sandbox versions of payment, tax, ERP and shipping systems. The step is complete when every integration passes its tests and the failure handling for each one is documented.
Deploy Medusa and switch storefront API calls
Platform engineers provision PostgreSQL, Redis and S3 storage, then start a server instance for the API and admin dashboard and a worker instance for background tasks. Set the database credentials, COOKIE_SECRET and JWT_SECRET values, and confirm that the predeploy migration runs before each startup. Point the storefront from commercetools calls to Medusa's store API in staging. The step is complete when the /health endpoint reports healthy on both instances and the storefront completes browse, cart and checkout flows.
Run both backends until orders reconcile
Keep commercetools live while Medusa handles test orders and then a controlled share of real traffic. Compare orders, payments, inventory movements, taxes, promotions, refunds and returns between the two systems for each scenario your business uses. Assign an owner to every discrepancy, fix the root cause in the mapping or the integration, and rerun the affected scenarios. The step is complete when an agreed scenario list reconciles without open defects.
Cut over and retire commercetools
Freeze catalog and pricing changes, run a final delta export and import, and switch production traffic and integration endpoints to Medusa. Monitor error rates, order volume and webhook delivery closely during the first live period, with a documented rollback path to commercetools. Keep commercetools in read-only mode until your records retention and audit obligations are met, and confirm your contract terms with commercetools before cancelling. The step is complete when no production traffic reaches commercetools and the retention plan is recorded.
Questions buyers ask before choosing Medusa over commercetools
How much more effort is self-hosting Medusa than using commercetools?
Self-hosting moves the work of running the platform from the vendor to your team, so the effort is larger and it recurs. commercetools operates the SaaS backend, its regions and its uptime. A self-hosted Medusa deployment needs a PostgreSQL database, a Redis database, a server instance for the API and admin dashboard, and a worker instance for background tasks. Your team then owns patching, backups, scaling, monitoring, incident response and version upgrades. Each of these grows with traffic, the number of stores and the number of integrations. Ask your team to list which of these duties it already performs for other services, since that list shows how much new capacity Medusa requires.
Can our team run Medusa without an outside implementation partner?
A team with Node.js and TypeScript experience and some PostgreSQL operations skill can run Medusa, but the first deployment is where most teams need help. The deployment docs describe a predeploy script that runs database migrations before each startup, environment secrets such as COOKIE_SECRET and JWT_SECRET, and a /health endpoint to confirm the deployment is working. The harder work is usually the surrounding design: data migration, custom modules that replace commercetools extensions, payment and tax integrations, and a secure production topology. Decide which of these your staff will own, which they will buy, and which they will hire back for later upgrades.
What skills and on-call coverage does a self-hosted Medusa store require?
The team needs four capabilities: Node.js and TypeScript for the application and custom modules, PostgreSQL for the commerce data, Redis for caching, the event bus, the workflow engine and locking, and an on-call rota that covers storefront and checkout incidents. The production setup also uses S3 for file storage, so cloud or storage administration is part of the skill set. Ask who is paged when checkout fails at night, who restores a database backup, and who approves a Medusa version upgrade. If those answers are unclear, the operating model is not ready, regardless of the software choice.
Do we need Medusa Enterprise Edition for role-based access control?
Only if you need the features that Medusa keeps under its Enterprise Edition. The core commerce framework is MIT licensed. Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Before you assume you need it, list the access rules you must enforce, such as separating merchandising staff from finance staff in the admin dashboard, and check them against the features in the repository and the agreement terms. Any commercial agreement is a recurring cost to add to the self-hosted total, and its terms should be confirmed directly with MedusaJS, Inc.
How long does a migration from commercetools to Medusa take?
The timeline depends on the work you scope, not on a single fixed number, and no duration is set by the supplied sources. The main drivers are the size and cleanliness of the product catalog, how many product types and custom fields must map to Medusa modules, how many commercetools extensions and integrations must be rebuilt, the number of markets and currencies, and whether you run both backends in parallel until order flows are verified. Customers and orders are often the most sensitive exports, so check their completeness early. Ask any implementation firm for a timeline built from a written scope with named deliverables.
Can customer and order data stay in a region we choose with Medusa?
Yes, in principle, because a self-hosted Medusa deployment runs in infrastructure you select, including cloud accounts you control or your own data center. Residency then depends on where the PostgreSQL database, Redis, S3 file storage, backups and logs are placed, and on every third-party service that receives customer data, such as payment providers, tax engines, email and analytics. Map each of those flows before deciding. Compare this with commercetools, where a region choice covers its own hosted environment and should be confirmed against its documentation and your legal requirements.
What should a fixed-scope quote for a Medusa implementation include?
A fixed-scope quote should list the deliverables in writing before work starts: the target architecture, the deployment topology with the server and worker instances, PostgreSQL, Redis and S3, the data migration plan and its validation steps, the custom modules that replace extensions, the integrations to rebuild, the cutover and rollback plan, and documentation handed to your team. It should also state what is excluded, such as storefront redesign or ongoing support. Ask how upgrades, backups and security testing are handled after launch, and whether those are separate retainers. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and provides its quotes from a written scope rather than a published price list.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a move off commercetools, that work usually starts with a scoping exercise: which product types, custom fields and API integrations must survive, which commercetools extensions need a Medusa module or a service outside the framework, and which Medusa features your team needs from the open-source core and which, such as role-based access control, would sit behind the Enterprise Edition and a commercial agreement with MedusaJS, Inc. Those decisions shape everything after them, so settle them in writing first.
Most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope rather than from a published price list, because DeployOpen does not publish one. When you request a quote, ask for each component to be listed separately: the Medusa deployment and its PostgreSQL and Redis databases, the server and worker instances, S3 file storage, the migration and reconciliation of products, prices, customers and orders, storefront API changes, and handover documentation. Ask which items recur after go-live, such as upgrades, backups and monitoring, and whether those are covered by a retainer for ongoing support, which is also available for continuous security testing.
Security testing and compliance readiness are separate services that can run alongside the build. DeployOpen tests applications, APIs and infrastructure, and prepares systems, controls and evidence for a compliance assessment. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work, so confirm early which assessor your organization will use and what evidence they expect from the Medusa environment, including secret handling for the cookie and JWT values and access controls on the admin dashboard. DeployOpen is not an official partner, reseller or certified provider of Medusa or commercetools.
