Is commercetools cost vs self-hosted Medusa a fair comparison for your team?
A renewal notice arrives, the platform team asks what the alternative would cost, and finance wants one number. That number is hard to build from this side of the table, because commercetools does not publish its subscription or add-on prices. A fair comparison is only as good as the written quote you hold, so ask for the base subscription, every add-on you use, the API and usage terms that drive the bill, and the renewal uplift in writing before you model anything. Without those lines, any side-by-side figure is a guess dressed as a comparison.
Medusa's core is MIT licensed, so the framework itself carries no license fee. The cost moves elsewhere. Some features, role-based access control among them, require a commercial agreement with MedusaJS, Inc. under the Enterprise Edition, so check which of your admin, permission and governance needs fall in that group before you assume the open core covers them. On your own infrastructure you pay for a PostgreSQL database, a Redis database, storage for files (Medusa's production setup uses S3), and two Medusa instances: one in server mode for the API and admin dashboard and one in worker mode for background tasks. Each of those is recurring, and each has to be sized, patched and monitored.
The largest lines are often people and integration work rather than hosting. Someone must own migrations, which run through a predeploy script before each startup, manage the database credentials and the COOKIE_SECRET and JWT_SECRET values, and confirm health through the /health endpoint. Costs rise when your extensions are deep, when you need high availability across several environments, or when you move regulated data and must document controls yourself. They fall when your catalog and checkout logic are standard and when you reuse internal platform engineering staff. Ask your implementation partner for a written scope that lists each component, who operates it, and which rebuilt extensions are included.
Which cost components appear on each side, and which are one-time or recurring
This table lists the cost components on the commercetools side and the self-hosted Medusa side, and marks each as one-time or recurring. No commercetools prices are given because the vendor does not publish them, so use the Recurring or One-time column to build your own quote request. The main takeaway is that the Medusa software license is usually not the largest line; the people who build, run and upgrade the platform are.
| Cost component | Who is paid | One-time or recurring |
|---|---|---|
| commercetools subscription and add-ons | commercetools, under a negotiated contract with usage or tier terms that you must confirm in writing | Recurring; ask which add-ons, API usage bands and environments are included |
| Medusa core (MIT licensed) | No license fee for the core framework | Not applicable; confirm the license terms with your legal team |
| Medusa Enterprise Edition features | MedusaJS, Inc., under a commercial agreement, only if you need features based on role-based access control | Recurring if licensed; confirm which features you need before quoting |
| PostgreSQL database | Your cloud provider or data center team, or a managed database service | Recurring; sized by catalog, order volume and backup retention |
| Redis instance | Your cloud provider or platform team, used for caching, event bus, workflow engine and locking | Recurring; sized by traffic and background job volume |
| Server and worker instances | Your cloud provider; one server-mode and one worker-mode Medusa instance minimum | Recurring; scales with API traffic and background task load |
| S3-compatible file storage | Your object storage provider for product images and files | Recurring; grows with media volume and egress |
| Implementation, data migration and integrations | A systems integrator, DeployOpen or your in-house team, under a written fixed scope | One-time; drives most of the initial spend when integrations are numerous |
| Upgrades, support and internal skills | Your engineers, a retained partner, or both; Medusa releases and migrations need regular attention | Recurring; the largest ongoing line for most teams, so ask for an effort estimate in any quote |
What a self-hosted Medusa deployment needs to run in production
A self-hosted Medusa deployment needs four runtime pieces before any storefront traffic arrives: a PostgreSQL database, a Redis database, a server-mode Medusa instance that serves the API and admin dashboard, and a worker-mode Medusa instance that handles background tasks. Each one is a separate line you will pay for, operate and patch. The server and worker run the same application code with different modes, so a team that budgets for one application process has usually missed the second. Plan for both to be scaled, monitored and restarted independently.
Production also changes the module setup. Development defaults are replaced with Redis-based caching, an event bus, the workflow engine and locking, and S3 for file storage. Each of these adds a managed or self-run service, its own credentials and its own failure mode. Ask your platform team to confirm the Redis topology (single instance, replicated or clustered), the S3-compatible store you will use for product images and uploads, and how backups and restores cover PostgreSQL and object storage together. Those choices drive most of the recurring infrastructure cost and the on-call load.
Two routine steps belong in your runbook from day one. Medusa runs database migrations through a predeploy script before each startup, so a failed migration can block a release, and the rollback plan must cover schema changes as well as code. Each server and worker also needs database credentials plus COOKIE_SECRET and JWT_SECRET values, which must be generated, stored in your secrets manager and rotated on a schedule. Check each deployment through the /health endpoint before routing traffic to it. Confirm these steps against the Medusa deployment documentation for the version you intend to run.
What moves the commercetools and Medusa cost comparison
Neither side of this comparison has a flat price. commercetools pricing depends on the contract, and a self-hosted Medusa bill depends on the infrastructure and people you assign to it. The drivers below connect those two sides, and each one shows which direction it pushes the total.
Order and catalog volume
Order counts, catalog size and peak traffic drive compute, database storage and worker load on your side, and they also shape the commercetools contract tier, since usage is commonly part of the subscription. Ask commercetools how its subscription scales with orders, API calls and SKUs, and measure your own peak order rate in a load test before you size PostgreSQL, Redis and the server and worker instances. Higher volume pushes both sides up, but self-hosted costs rise in steps as you add capacity.
Storefronts and markets
Each additional storefront, country, currency or sales channel adds configuration, price lists, tax rules and testing. On commercetools, extra stores and regions can change the contract scope. On Medusa, the work lands on your team as module configuration, content and regression testing. Ask commercetools how it prices additional projects and regions, and list every market you need on day one so both estimates use the same count.
Medusa features that need Enterprise Edition
Medusa's core framework is MIT licensed, but Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. If your admin model depends on granular staff permissions, that license becomes a recurring line item that a pure open-source estimate would miss. Map each commercetools feature your operations use today to the Medusa core or to Enterprise Edition, and request written pricing for the modules you need before comparing totals.
Availability targets and redundancy
A commercetools subscription includes the hosting and vendor-run availability. A self-hosted Medusa deployment makes you responsible for redundant server and worker instances, database replicas, failover for Redis, backups and monitoring across regions. A higher uptime target pushes the self-hosted cost up quickly, because it multiplies infrastructure and on-call coverage. Ask commercetools for its written availability commitment and any service credits, then price a redundant topology against that same target.
Integration count
Payment gateways, tax engines, ERP, warehouse management, search, marketing tools and custom middleware each need a connector that someone builds, tests and maintains. Integrations you already run on commercetools's API may need rewriting for Medusa's module and API model, and every integration adds an upgrade path to test each time Medusa or a connected service changes. Inventory every integration with its owner and its data flow. A long integration list pushes the self-hosted side up mainly through engineering time, not infrastructure.
In-house platform skills
Running Medusa means staff who can operate Node.js and TypeScript services, PostgreSQL, Redis, S3-compatible storage, deployments and incident response. If that skill set already exists, the marginal cost is mainly time. If it does not, you will pay for hiring, training or an outside partner on a recurring basis. Ask whether your team can run the migration predeploy step, the server and worker split and the health checks, and price any gap as an ongoing support scope rather than a one-off project.
How to build the commercetools vs Medusa model with your own numbers
This sequence turns a commercetools quote and your own infrastructure and staffing figures into a three to five year cost model that separates one-time migration work from recurring run costs, with and without Medusa Enterprise Edition features.
Request a written commercetools quote
Ask commercetools for a written quote that itemizes the subscription tier, each add-on you would need, API and usage terms, the number of regions or environments, and any support level. commercetools does not publish its prices, so the quote is the only source for the SaaS side of the model. Confirm in writing how usage is measured and what happens when you exceed a limit, and whether the price holds for a multi-year term. The step is done when every line of the quote maps to a feature you use today or plan to use within the modeled period.
Inventory every integration and extension
Your engineering lead, with input from the teams that own ERP, payments, tax, search, OMS and the storefront, lists every system that calls the commercetools API, every extension or subscription that runs inside it, and every custom field or product type that carries business logic. Record the call volume, data direction and owner for each item. This list drives the rebuild estimate in later steps. The step is done when each integration has a named owner and a row in a shared sheet that also notes whether it depends on a commercetools-specific feature.
Price the infrastructure from your cloud rate sheet
Your platform team prices the self-hosted Medusa stack using your own cloud provider's current rate sheet, not a vendor estimate. The stack needs a PostgreSQL database, a Redis database, a Medusa instance in server mode for the API and admin dashboard, a Medusa instance in worker mode for background tasks, S3 storage for files, plus environments for staging and disaster recovery. Include backups, logging, monitoring and egress. The step is done when the monthly figure for each environment is traceable to a line on the rate sheet and a sizing assumption you can explain.
Estimate engineering effort by role
Engineering managers estimate hours by role for the work your team would own: platform engineering for deployment and upgrades, backend engineers for modules and integrations, a security engineer for secrets, access and patching, a site reliability engineer for on-call, and a product owner for ongoing merchandising changes. Use your own team's velocity and salary bands, and label any figure as your estimate. Ask implementers to quote the same roles separately so the two sets of numbers can be compared line by line. The step is done when each role has an hours figure, an hourly cost and a recurring or one-time tag.
Separate one-time costs from recurring run costs
Finance and the program lead split the model into two ledgers. One-time costs cover migration of products, categories, customers, prices and orders, rebuilding extensions, storefront API changes, security review and go-live testing. Recurring costs cover hosting, software licenses, the commercetools subscription, staff time for upgrades and on-call, and any Medusa Enterprise Edition agreement. Ask the implementation partner to confirm which items are fixed-scope and which are time-and-materials. The step is done when every cost sits in exactly one ledger and the migration ledger has a written scope behind it.
Run three to five year scenarios
Build at least two scenarios over three and then five years: one using Medusa's open-source core only, and one that adds the Enterprise Edition features your business needs, such as role-based access control, under a commercial agreement with MedusaJS, Inc. Run the commercetools subscription alongside each scenario with the quoted add-ons and an assumed annual change to usage. Show the crossover point, if any, where the self-hosted total falls below the SaaS total. Mark the figures you could not confirm. The step is done when both scenarios produce a cumulative total for each year and a list of assumptions that a reviewer can challenge.
Confirm open figures before the decision
Before the model goes to the steering group, send each open figure to the party that owns it. Ask commercetools to confirm the quote and usage terms, ask MedusaJS, Inc. to confirm the scope and pricing of any Enterprise Edition features you need, and ask your cloud provider to confirm the rate sheet version. Ask a qualified implementer to confirm the migration and rebuild hours. Record the date and source of each confirmation. The step is done when no figure in the model is marked as an assumption without a named owner and a confirmation request.
How migration work changes the first-year cost
The one-time migration spend is the part of the first-year cost that most often runs longer than planned, because it overlaps with the commercetools subscription you are still paying. During cutover you typically run both backends: commercetools keeps serving live traffic while Medusa is built, loaded with catalog and pricing data, and tested against real order flows. That parallel period is a recurring commercetools cost you should model separately from the Medusa build. Ask commercetools in writing what the contract term, notice period and any minimum commitment mean for a partial or extended overlap, since the company does not publish its subscription pricing and those terms decide how expensive a slow cutover becomes.
Export scope drives the migration work more than most teams expect. What you can extract depends on what the Merchant Center and the HTTP API expose for each resource type, including products, categories, customers, prices and orders, and on any limits that apply to files you plan to re-import. Confirm these details against the current commercetools documentation before you size the engagement, and budget for scripted queries against the HTTP API wherever the Merchant Center export falls short. Medusa then needs those records mapped to its own modules for products, pricing and orders, which is effort that sits in your integration budget rather than in the platform license. The sibling pages on exporting data from commercetools and migrating to Medusa cover the export mechanics, field mapping and storefront API changes step by step, so this section does not repeat them.
Plan the first-year budget around three one-time items: the parallel-run period, the export and mapping work, and the rebuild of extensions and integrations. Each can be quoted only after the written scope fixes which resources move, which custom fields need mapping and which order flows must be verified before cutover. Ask any implementation partner to price these items separately from the recurring Medusa hosting components, so you can see how much of year one is migration and how much is run cost. Treat the cutover sign-off criteria as a decision you make early, because they determine when the commercetools subscription can end.
Questions buyers ask before comparing commercetools cost and self-hosted Medusa
What drives the cost of running Medusa compared with a commercetools subscription?
The cost depends on which components you run and who operates them. A commercetools subscription bundles hosting, the API platform and vendor support into one recurring contract, and its add-ons are priced by commercetools, which does not publish those prices. A self-hosted Medusa deployment splits the bill into parts: the MIT-licensed core costs nothing to license, but you pay for PostgreSQL, Redis, S3-compatible file storage, two Medusa instances (one in server mode and one in worker mode), integration work and the engineers who run the platform. Ask commercetools for a written quote covering every add-on you need, and build your own model against those components.
Can our team run self-hosted Medusa without an outside partner?
Your team can run it alone if it already operates Node.js services, PostgreSQL and Redis in production and has someone who owns releases. A self-hosted Medusa deployment needs database credentials, the COOKIE_SECRET and JWT_SECRET values for both the server and worker, and checks through the /health endpoint. Medusa also runs database migrations through a predeploy script before each startup, so upgrades need a tested path. Teams without that operating experience usually bring in a partner for the first deployment, hardening and runbooks. DeployOpen works this way on fixed-scope engagements, with scope and deliverables agreed in writing before work starts, and offers retainers for ongoing upgrades and support.
How long does a migration from commercetools to Medusa take?
The timeline depends on the size of your catalog, how many custom product types and extensions you run, the number of integrations that call commercetools APIs, and how much order history you must carry over. No duration is set by a researched fact here, so ask any implementation partner for a timeline based on a written scope. Plan for a period where both backends run until order flows are verified, and expect the storefront API calls to change. Your own inventory of extensions and integrations will set most of the duration.
Which Medusa features need the Enterprise Edition license?
The Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc. The core commerce framework is MIT licensed, so modules for carts, orders, product catalogs, pricing and inventory are available without that agreement. Confirm the exact feature list and terms with MedusaJS, Inc. before you build a cost model around it, since role-based access may matter for staff permissions in the admin. Ask for the license terms in writing so the platform cost is clear before you commit.
What staff roles does a self-hosted Medusa platform need?
A self-hosted platform needs roles that commercetools currently covers for you. Typical roles include a platform engineer who manages PostgreSQL, Redis, S3 storage, container runtime and secrets, a backend developer who maintains modules and integrations, a storefront developer for API calls, and someone who owns security patching and access reviews. Smaller teams often combine these roles. Each role has a recurring cost in salary or contractor fees, and that cost usually outweighs the infrastructure bill, so include it in any comparison with a SaaS subscription.
What should we request in a quote for a Medusa implementation?
Ask for a written scope that lists each deliverable, each integration, each data migration and each environment. Request separate line items for the initial build, the migration, hardening, documentation and handover, and for any recurring retainer. Ask what is excluded, how changes to scope are priced, and who performs upgrades to new Medusa releases. For commercetools, request a full list of the add-ons and their renewal terms. DeployOpen does not publish a price list and provides a quote following from the written scope, so bring your component list and integration inventory to the first call.
How DeployOpen scopes a fixed-price Medusa implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a commercetools cost vs self-hosted Medusa decision, we turn your current subscription and component inventory into a written scope before any build work starts.
How we scope
- We inventory your commercetools subscription, add-ons, integrations and the internal staff who maintain them today.
- We agree a written scope covering Medusa modules, PostgreSQL, Redis, S3 storage and the server and worker instances.
- We list which Medusa features your business needs and confirm with Medusa whether any require the Enterprise Edition.
How we build
- We deploy Medusa in server and worker modes in your environment, with the predeploy migration step and secrets configured.
- We rebuild required integrations, pricing and promotion logic against Medusa modules and test order flows end to end.
- We run security testing on the storefront API and admin surfaces before go-live, and report findings in writing.
How we hand over
- We document the architecture, environment variables, backup routines and the
/healthchecks your team uses to verify deployments. - We train the engineers who will operate the platform on upgrades, migrations and incident steps.
- We deliver the runbooks and evidence that your internal or external auditors may ask for, without issuing any attestation ourselves.
How we support
- Engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any provider, including us, to quote each cost component separately: setup, integrations, hosting, and staff time to run it.
