When Medusa Cloud fits and when self-hosted Medusa fits better
Choose Medusa Cloud when your team wants Medusa running quickly without building a platform function, and when the usage allowances and overage terms on a Cloud plan match your traffic. Choose self-hosted Medusa when data residency rules, internal platform skills or a need for specific infrastructure control make running the stack in your own cloud or data center the better fit. Neither answer is permanent, because Medusa's pricing FAQ says there is no lock-in with Medusa Cloud, customers keep ownership of their source code, and data can be exported at any time to run Medusa on their own infrastructure.
Managed hosting suits teams that have no one to own PostgreSQL, Redis, the server and worker instances, the predeploy migration step and the /health checks. Medusa Cloud plans start at 29 US dollars per month on Develop, with Launch and Scale above it, and usage allowances on edge requests and compute hours carry overage charges, so ask the vendor how those meters map to your expected peak traffic. Confirm in writing which data residency options each Cloud plan offers. If a regulator or internal policy requires a specific jurisdiction, a region not listed on the plan, or customer data kept inside your own accounts, treat that as a reason to self-host.
Self-hosting fits when your platform team can operate two Medusa instances in server and worker mode, a PostgreSQL database, a Redis database for caching, event bus, workflow engine and locking, and S3 for file storage. Each instance needs database credentials plus COOKIE_SECRET and JWT_SECRET values, so secret handling and rotation belong in your design from day one. Enterprise features such as RBAC, SSO, audit logs and bring-your-own-cloud sit in the Enterprise plan, which requires a commercial agreement with MedusaJS, Inc. If you need those controls, confirm whether they are delivered as Cloud Enterprise, as a licensed self-hosted edition, or both, because the answer changes your cost model.
How Medusa Cloud and self-hosted Medusa compare on the factors that matter
This table compares Medusa Cloud plans with running the MIT-licensed framework yourself across licensing, pricing, infrastructure, upgrades, support and exit terms. Read each row as a question to settle before you choose, and treat items marked for confirmation as points to raise with MedusaJS in writing. The main takeaway is that Cloud shifts hosting work to the vendor for a recurring fee, while self-hosting keeps infrastructure work and cost with your team.
| Factor | Medusa Cloud | Self-hosted Medusa |
|---|---|---|
| Licensing | Enterprise features are under a commercial agreement with MedusaJS, Inc. Ownership of your source code stays with you. | Core commerce framework is MIT licensed. Enterprise Edition RBAC features still require a commercial agreement with MedusaJS, Inc. |
| Plans and list prices | Develop from 29 USD per month, Launch from 99 USD, Scale from 299 USD, Enterprise custom, billed monthly in advance (Medusa pricing page). | No Medusa hosting fee. You pay for your own cloud resources, database, cache, storage and the engineers who run them. |
| Usage allowances | Edge requests of 1 million, 5 million and 10 million, and 600, 1,000 and 2,800 compute hours on Develop, Launch and Scale, with overage charges. Confirm overage rates. | No platform allowance. Capacity is set by the infrastructure you provision and the sizing you choose. |
| Database and cache | Managed by Medusa Cloud. Confirm the database engine versions and cache configuration offered on each plan. | PostgreSQL and Redis are required. Production replaces development modules with Redis-based caching, event bus, workflow engine and locking. |
| Instance layout | Server and worker roles are operated for you. Confirm how many instances each plan runs. | Two instances are required: one in server mode for the API and admin dashboard, one in worker mode for background tasks. |
| Upgrade path | Vendor-managed releases. Confirm the upgrade notice period and whether you can pin a version. | Migrations run through a predeploy script before each startup. Your team schedules upgrades, tests them and handles rollback. |
| Enterprise contents | Enterprise adds an enterprise license, 24/7 support, RBAC, SSO, audit logs, bring-your-own-cloud and SOC 2, with a 99.99% uptime SLA (Medusa pricing page). | Enterprise features are available only through a commercial agreement. Confirm which Enterprise items you could license without Cloud. |
| Support and uptime | Enterprise lists 24/7 support and a 99.99% uptime SLA. Standard plan support and SLA terms should be confirmed in writing. | No vendor SLA. Uptime depends on your on-call rota, monitoring and the /health checks you run. |
| Lock-in and data export | No lock-in, customers keep source code ownership, and data can be exported at any time to run Medusa on their own infrastructure (Medusa pricing FAQ). | No exit step needed for hosting, but you own the full stack and its operational knowledge from day one. |
How data location, access control and compliance change with the hosting model
Moving between Medusa Cloud and self-hosted Medusa changes who holds the database, the secrets and the source code, and which controls you inherit versus build. The cards below separate what Enterprise adds on Medusa Cloud from what your own team must configure, operate and evidence.
Where the data lives
On Medusa Cloud, the database, Redis and file storage run in Medusa's managed environment, so you need to confirm the hosting region, backup location and who can access production data. When self-hosted, customer records, orders and payment-adjacent data stay in the PostgreSQL database, Redis and S3 buckets you provision in your own cloud account or data center. Map every store that holds customer data before choosing a model.
Who holds source code and secrets
Medusa's pricing FAQ says customers keep ownership of their source code and can export data at any time to run Medusa on their own infrastructure. Ownership does not mean operational control. On either model, your team should confirm who holds COOKIE_SECRET, JWT_SECRET and database credentials, how they rotate, and whether the vendor can access them during support.
RBAC and SSO in the Enterprise tier
Medusa's pricing page lists RBAC and SSO as Enterprise features, and the open-core license note says Enterprise Edition RBAC features need a commercial agreement with MedusaJS, Inc. A self-hosted team on the MIT core must plan its own access model and identity integration, or confirm with Medusa what is available without the commercial agreement. Ask for the role matrix before assuming parity.
Audit logs and evidence
Enterprise lists audit logs among its features, which produces an admin activity record without your build effort. On self-hosted Medusa, you must decide where application and infrastructure logs go, how long they are retained and who reviews them. If your assessor asks for evidence of administrative changes, confirm the log source and retention period in writing before go-live.
Bring-your-own-cloud as a middle option
Enterprise includes bring-your-own-cloud, which lets Medusa operate the platform inside infrastructure you control. This changes the data location question without moving the operating burden entirely back to your team. Confirm which account owns the resources, who holds the keys, and how the shared responsibility split is documented before treating it as equivalent to a fully self-hosted deployment.
What SOC 2 and the 99.99% SLA prove
Medusa's pricing page lists SOC 2 and a 99.99% uptime SLA for Enterprise. Read these as vendor commitments, not as your compliance posture. A SOC 2 report covers Medusa's own controls for the scope the auditor examined, and an uptime SLA covers contracted availability and remedies, not your data handling, access reviews or incident response. Request the current report and SLA text, then check which systems they cover.
Who prepares evidence and who attests
DeployOpen plans, implements and hardens self-hosted platforms in your environment, and it prepares controls and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so your assessor must accept the evidence on its own terms before any engagement is scoped.
What Medusa Cloud costs compared with what self-hosting costs
Medusa Cloud is priced by plan and by usage, so the first cost line is the monthly plan fee. Medusa's pricing page lists Develop from 29 US dollars per month, Launch from 99 dollars and Scale from 299 dollars, billed monthly in advance, with Enterprise at custom pricing. Those are the only Cloud prices this section quotes. Each plan also includes usage allowances for edge requests and compute hours (the page lists 600, 1,000 and 2,800 compute hours on Develop, Launch and Scale), and traffic or compute above those allowances is billed as overage. Your cost therefore rises with request volume and background work, not only with the plan you pick. Ask the vendor to model your expected edge requests and compute hours against each allowance, and to state the overage rate in writing.
Self-hosting moves those charges to your own accounts and staff. You pay your cloud provider for the server and worker instances, a PostgreSQL database, a Redis instance and S3 storage for files, and you pay your engineers to deploy, patch, back up, monitor and upgrade the stack. Medusa's deployment docs require a predeploy migration step before each startup, so every version upgrade is a planned change with its own testing time. The framework itself is MIT licensed, so there is no license fee, but the Enterprise features (RBAC, SSO, audit logs) require a commercial agreement with MedusaJS, Inc. Confirm with the vendor whether those features are needed before you count them as zero cost. Engineering time is usually the largest recurring item, and it scales with how many environments and integrations you run.
Request a written quote that puts both models on the same basis. For Cloud, ask for the plan, the overage rates, the expected usage against each allowance, and the Enterprise terms if you need SSO, audit logs or bring-your-own-cloud. For self-hosting, ask the implementer for a fixed-scope quote covering the initial deployment, the handover, the upgrade approach and any retainer for ongoing support, and ask your own cloud team to price the database, cache, storage and worker capacity in your account. Then compare total annual cost, separating one-time setup from recurring spend. Medusa's pricing FAQ says data can be exported at any time to run on your own infrastructure, so ask what that export would require in practice before you commit.
What your team runs in each model
In Medusa Cloud, MedusaJS operates the hosting layer, so your team mainly configures the store, manages content and integrations, and reviews the operational terms. The exact division of duties is set by the plan and its terms, so confirm each item below before you commit.
- Server and worker instances: Confirm who patches the API and admin server and the background worker, how often this happens, and whether upgrades run migrations on your behalf.
- Database and Redis: Ask how PostgreSQL and Redis are backed up, how long backups are kept, and whether restores are tested. Ask who handles capacity changes when compute hours or edge requests approach their allowances.
- S3 and secrets: Ask how file storage is configured and who can view or rotate values such as
COOKIE_SECRETandJWT_SECRET, and how rotation affects active sessions. - Health checks and monitoring: Ask whether the
/healthendpoint is watched for you, which alerts reach your team, and where incident history is published. - On-call coverage: The supplied plan details tie 24/7 support and a 99.99% uptime SLA to Enterprise, so confirm what the lower plans include for out-of-hours incidents.
Before signing, ask for the data export procedure in writing and confirm that your team could run the same store on your own infrastructure if needed. Review the Medusa pricing page for current plan terms.
When your team self-hosts Medusa on its own cloud account, your engineers own every runtime component. A deployment needs PostgreSQL, Redis, S3-compatible file storage and two Medusa instances, one in server mode for the API and admin dashboard and one in worker mode for background tasks. Production replaces development modules with Redis-based caching, event bus, workflow engine and locking.
- Server and worker instances: Your team patches and upgrades both instances, and each upgrade runs the predeploy migration script before startup, so plan a maintenance window for schema changes.
- Database and Redis: Your team designs backup schedules, restore tests and Redis persistence and failover. Redis carries caching, events, workflows and locks, so an outage affects more than cache performance.
- S3 and secrets: Your team configures bucket policies, access keys and encryption. Each server and worker needs database credentials plus
COOKIE_SECRETandJWT_SECRET, and secret rotation must be applied to both instances together. - Health checks and monitoring: Your team wires the
/healthendpoint into load balancers and alerting, and decides which signals page someone. - On-call coverage: Your team staffs incident response, runbooks and escalation. No vendor support is included unless you buy it separately.
Before you start, document the upgrade order, the secret inventory and the restore procedure. The Medusa deployment guide lists the production setup in detail.
Self-hosting with an implementation partner keeps the platform in your own infrastructure while moving part of the operating work to a party under contract. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. Engagements are usually fixed-scope, and ongoing support is available as a retainer.
- Server and worker instances: Scope in writing who applies patches, runs predeploy migrations and performs upgrades for the server and worker instances, and how often that happens.
- Database and Redis: Agree backup frequency, retention, restore testing and Redis failover responsibilities in the written scope, so the restore process is tested before an incident.
- S3 and secrets: Define who provisions storage, who holds
COOKIE_SECRETandJWT_SECRET, and how rotation is recorded and handed over at the end of the engagement. - Health checks and monitoring: Agree which
/healthchecks, dashboards and alert thresholds are built, and who receives them during and after the engagement. - On-call coverage: Confirm in the scope whether out-of-hours response is included, what response windows apply, and whether it is a retainer or a separate agreement.
Your team stays accountable for business decisions and access approvals. Ask for a quote built from this written scope, and confirm which duties sit in the one-time implementation and which move to a recurring retainer.
How to move from Medusa Cloud to self-hosted Medusa and back
This sequence takes a team from a Medusa Cloud store to a self-hosted deployment in its own infrastructure, with a verified cutover and a rollback path, and it describes the reverse move if the team later returns to Cloud.
Confirm code ownership and export terms
Before any technical work, read Medusa's pricing FAQ, which states that customers keep ownership of their source code, that there is no lock-in with Medusa Cloud, and that data can be exported at any time to run Medusa on your own infrastructure. Ask your Medusa account contact to confirm these terms in writing and to confirm which export path applies to your plan. Your team or DeployOpen, under a written scope, owns the inventory of custom modules, storefront code, integrations and environment variables. This step is done when you hold a signed-off inventory and a written confirmation of export terms.
Export data and inventory the store
Export the store data from Medusa Cloud using the method confirmed in the previous step, then take a dated copy of the PostgreSQL data and the file assets that Cloud holds. Record counts for products, orders, customers and inventory levels so the target can be reconciled later. Confirm with Medusa exactly what the export contains, especially for uploaded files and any data held outside the database. This step is done when the export files are stored in a location you control and the reconciliation counts are recorded.
Provision PostgreSQL, Redis and S3
Provision the three services a self-hosted Medusa production setup depends on: a PostgreSQL database for commerce data, a Redis database for caching, the event bus, the workflow engine and locking, and S3 storage for files. Place them in the infrastructure you control, such as your cloud account or data center, and restrict network access to the Medusa server and worker. Your platform team or DeployOpen, under a written scope, owns backups, encryption and access policy for these services. This step is done when each service is reachable from the planned server and worker hosts and its backup policy is documented.
Deploy server and worker with secrets
Deploy two Medusa instances from the same codebase: one in server mode for the API and admin dashboard, and one in worker mode for background tasks. Each instance needs its database credentials plus COOKIE_SECRET and JWT_SECRET values, which should come from your secrets manager rather than plain configuration files. Store the secrets with the same rotation policy you apply to other production credentials. This step is done when both instances start, connect to PostgreSQL and Redis, and report their configuration without errors in your logs.
Run migrations and import the data
Run database migrations through the predeploy script that Medusa uses before each startup, then import the exported data into the new PostgreSQL database. Migrations must complete before the server instance accepts traffic, so run them against a staging copy first. Reconcile the imported record counts against the figures captured during export and resolve any mismatch before going further. This step is done when migrations finish cleanly on staging and production, and the reconciliation counts match.
Verify the deployment through the health endpoint
Check the server instance through the /health endpoint, then run functional tests on the storefront, admin dashboard, checkout, inventory and payment integrations that your business depends on. Confirm that the worker is processing background jobs, because a healthy server does not prove that the worker is running. Record the results with the test owner and date. This step is done when /health reports healthy and your functional test sign-off is complete for both instances.
Cut over DNS and plan rollback
Move production traffic by changing DNS records to the self-hosted endpoints during a window agreed with your operations team. Keep the Medusa Cloud environment running, unchanged, until the new environment has run real orders successfully, and document the exact DNS values to revert. Decide in advance who can authorize a rollback and what data written after cutover would need to be reconciled. This step is done when traffic serves from the new environment and the rollback runbook has been reviewed.
Reverse the path back to Cloud
To return to Medusa Cloud, repeat the export from your self-hosted database under the terms in your agreement, then import and verify the data in Cloud using the same reconciliation counts. Confirm with Medusa how Cloud accepts your code and data and which plan allowances apply to the return. Note that bring-your-own-cloud, listed as an Enterprise feature on Medusa's pricing page, governs deploying into your own cloud account rather than operating Cloud-hosted stores, so confirm whether it is part of your agreement before depending on it. This step is done when the reverse import is verified and the cutover is complete.
What Enterprise adds and whether you need it
Medusa's pricing page lists what Enterprise adds: an enterprise license, 24/7 support, a 99.99% uptime SLA, role-based access control (RBAC), single sign-on (SSO), audit logs, bring-your-own-cloud and SOC 2. Only the first item is a license question in the strict sense. The rest are operating commitments or controls you either need, or you do not. Before comparing Enterprise against Cloud plans, sort each item into one of three groups: contractual (support hours, the uptime SLA, the license), control (RBAC, SSO, audit logs), and assurance (SOC 2). Ask MedusaJS, Inc. for the current Enterprise terms in writing, including what the SLA measures and what remedies apply if it is missed.
The open-core split matters more than the plan label. The core commerce framework is MIT licensed, so you can run it yourself without a commercial agreement. Enterprise Edition features based on RBAC, however, require a commercial agreement with MedusaJS, Inc., and that rule applies whether Medusa runs on Cloud or on your own servers. Moving to self-hosting therefore does not remove the need for that agreement if you want RBAC. Confirm with the vendor which of the other Enterprise items (SSO, audit logs) fall under the same commercial terms, since the pricing page does not spell out that boundary for each one.
If you self-host, the controls you still need are yours to build or buy. Enterprise may supply RBAC, SSO and audit logs, but your team owns the PostgreSQL and Redis configuration, the COOKIE_SECRET and JWT_SECRET values, and the /health checks on both server and worker instances. A 99.99% uptime SLA on Cloud covers the hosting platform, not your own on-call rotation or upgrade work. For a regulated team, ask whether SOC 2 coverage applies to the hosted service only, and whether it can be cited in your own assessment. DeployOpen can help plan and document these controls, but it does not issue SOC 2 reports, which independent auditors produce.
Questions buyers ask before choosing Medusa Cloud or self-hosting
What does self-hosting Medusa cost compared with Medusa Cloud?
Self-hosting removes the Medusa Cloud subscription but moves the cost into infrastructure you pay for directly and into people who run it. Medusa Cloud plans start at 29 US dollars per month on Develop, 99 dollars on Launch and 299 dollars on Scale, billed monthly in advance, with usage allowances and overage charges on edge requests and compute hours, according to Medusa's pricing page. A self-hosted deployment still needs a PostgreSQL database, a Redis database, and two Medusa instances, so you pay your cloud provider or data center for those, plus engineering time for upgrades, backups, monitoring and security patching. Ask any partner for a quote built from your written scope, and compare it with the full Cloud plan cost at your expected traffic, not the entry price.
How long does a first self-hosted Medusa deployment take?
No duration is published for a first deployment, so confirm the timeline against your own scope before committing. The work that drives it is the number of environments, whether your infrastructure already provides PostgreSQL and Redis, how you handle file storage, the amount of custom modules and integrations you build, and how many approval gates your change process requires. Medusa's production setup swaps development modules for Redis-based caching, event bus, workflow engine and locking, and uses S3 for file storage, so each of those choices adds configuration to validate. Ask for a written plan that lists deliverables and the test evidence you will receive before go-live.
What Node.js, PostgreSQL and Redis skills does my team need?
Your team needs working knowledge of Node.js and TypeScript for the application, PostgreSQL for schema and migrations, and Redis for the caching, event bus, workflow and locking layers that production uses. Medusa is built with Node.js and TypeScript on PostgreSQL, and a production deployment depends on Redis, so an engineer who can only work on the storefront will not cover operations. Database migrations run through a predeploy script before each startup, so someone must own failed migrations and rollback decisions. Map these skills to named people on your team before you decide, and treat any gap as a scope item for an implementation partner or your own training.
Can our own team run a self-hosted Medusa store without outside help?
A team with the skills above can run Medusa in its own infrastructure, but the question is whether it can sustain that work through upgrades, incidents and staff turnover. Plan for two Medusa instances (one in server mode for the API and admin dashboard, one in worker mode for background tasks), each needing database credentials, COOKIE_SECRET and JWT_SECRET values, and a health check through the /health endpoint. Most teams underestimate the on-call load for background jobs and the upgrade cycle. Confirm internally who is on call, who reviews releases such as v2.21.2 released on September 28, 2026, and how much time that person can spend on Medusa each month. DeployOpen can plan, implement and support self-hosted platforms in your infrastructure under a fixed scope or a retainer, if that fits your team.
Do we need the Enterprise plan for SSO or audit logs?
Yes, if you want those features from Medusa's commercial offering, but the answer depends on how you deploy. Medusa's pricing page says Enterprise adds an enterprise license, 24/7 support, a 99.99% uptime SLA, RBAC, SSO, audit logs, bring-your-own-cloud and SOC 2. Medusa is open core, and Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Confirm with Medusa exactly which SSO and audit logging features sit under the commercial agreement and whether they apply to a self-hosted deployment. Verify the terms in writing before you assume any control depends on a particular tier.
How does lock-in work with Medusa Cloud, and can we export our data?
Medusa states there is no lock-in with Medusa Cloud, that customers keep ownership of their source code, and that data can be exported at any time to run Medusa on their own infrastructure, according to its pricing FAQ. Treat that as the vendor's commitment and test it before you rely on it. Ask for a documented export procedure, confirm which data (orders, customers, catalog, media in S3 or other storage) is included, and run a trial restore into a self-hosted environment. Also check custom modules and integrations, because they are the parts most likely to need rework during a move. Record the result so your exit plan is tested rather than assumed.
What should we check before deciding between Cloud and self-hosting?
Decide on four points: your traffic and whether usage allowances and overage charges fit your expected load, your data residency and network rules, whether you need bring-your-own-cloud or Enterprise terms, and the people you can commit to operating the stack. Get a written scope for either path and compare total cost of ownership over the period you plan to run the store. Medusa Cloud shifts hosting operations to the vendor, while self-hosting gives you control over infrastructure and deployment choices. Ask Medusa to confirm current plan terms, and ask any implementation partner to show deliverables, test evidence and support options in writing.
How to decide, and what to confirm before signing
This sequence turns the Cloud versus self-hosted question into a written decision backed by residency rules, a feature need list, an honest staffing picture, a scoped quote and a test run on both models.
Map data residency and certification requirements
Start by listing where customer and order data may be stored, which regions and sub-processors are acceptable, and which assurance evidence your auditors or customers will ask for. Compliance, legal and the commerce owner should sign off on this list together. Medusa Cloud's Enterprise tier lists SOC 2 among its features, so ask Medusa for the current report scope and the regions available for Cloud before assuming it meets your residency rule. The step is done when you have a one-page requirements document that both deployment models can be measured against.
Decide which Enterprise features you need
Compare your access control, single sign-on, audit logging and uptime expectations against what Medusa's pricing page says Enterprise adds: an enterprise license, 24/7 support, a 99.99% uptime SLA, RBAC, SSO, audit logs, bring-your-own-cloud and SOC 2. Note that Medusa's repository states that Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc., so the open-source core alone may not cover RBAC. The output is a yes or no per feature, with the owner who will test it.
Estimate internal operating capacity honestly
Self-hosting means your team runs PostgreSQL, Redis, S3-compatible file storage, two Medusa instances (one in server mode, one in worker mode) and the predeploy migration step on every release. Name who will carry on-call, patching, backups and upgrades, and whether that person already runs Node.js services in production. Cloud shifts much of that work to Medusa but still leaves your team with code, integrations and environment configuration. The output is a named ownership table covering each component, and a clear statement of which side of the line each one falls on.
Model usage against the Cloud allowances
Using your expected traffic and build patterns, estimate edge requests and compute hours against Medusa's published allowances for Develop, Launch and Scale, and note that overage charges apply. Model a second case with a peak sale period, since compute hours can climb quickly during campaigns. For self-hosting, price the infrastructure you would provision for the same load, plus the staff time above. The output is two cost curves over twelve months, labeled as your own estimates rather than vendor figures.
Request a written scope and quote
Ask Medusa for written terms covering the Cloud plan, usage overage rates, the Enterprise license terms, the SLA definition and remedies, data export procedures and the support response model. For self-hosting, ask DeployOpen for a fixed-scope written proposal covering architecture, environment hardening, backup and restore testing, upgrade procedure, documentation and any retainer for ongoing support. Compare both documents line by line. The step closes when every cost component has a named payer and a recurring or one-time label.
Confirm the exit and data export terms in writing
Medusa's pricing FAQ says there is no lock-in with Medusa Cloud, that customers keep source code ownership and that data can be exported at any time to run Medusa on their own infrastructure. Ask for that commitment in the contract, and ask what the export includes: database contents, uploaded files, configuration and secrets handling. Test the export on a staging database and confirm the restored instance passes the /health check. The output is a tested exit runbook, not a verbal assurance.
Run a proof of concept on both models
Deploy the same storefront configuration to a Medusa Cloud project and to a self-hosted environment in your own cloud account. Measure migration behavior, cold start, cache and event bus behavior under load, checkout reliability, and how long a rollback takes. Record who did each task and the hours it took. Conclude only when both environments pass the same acceptance tests and the team can explain the operating differences to the steering group.
How DeployOpen scopes, delivers and supports self-hosted Medusa
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For Medusa, that means working from a written scope that sets out how the team will run Medusa on its own infrastructure instead of, or alongside, Medusa Cloud.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope should name the Medusa version, the database, Redis, S3 and hosting targets in your environment.
- Ask us to list which Medusa Cloud features your team needs replicated, such as RBAC, SSO or audit logs.
How we build
- Builds cover the server and worker instances, PostgreSQL, Redis, S3 file storage and the predeploy migration step.
- Secrets handling for COOKIE_SECRET and JWT_SECRET is set up in your secrets store, not in source code.
- Deployments are verified through the /health endpoint, with the checks recorded as part of the build deliverables.
How we hand over
- Handover includes runbooks for upgrades, migrations, rollbacks and backup and restore of PostgreSQL and Redis.
- Documentation covers how to move data out of Medusa Cloud or between hosting environments, if that path applies to you.
- Confirm in the scope which configuration, source and operational records your team will own at handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope build.
- Retainer scope should state which Medusa releases are covered and who applies upgrades to server and worker instances.
- Ask for the response expectations and escalation path in writing, since these vary by agreement and are not published.
