Self-hosted commercetools alternative for data residency

Why a self-hosted commercetools alternative for data residency deserves a close look

A regulator, a customer contract or a sovereign-cloud rule may limit where customer and order data can be processed. When that happens, the question is no longer which commerce platform has the best features but whether the platform's hosting can meet the limit at all. The short answer is that a region choice at commercetools may satisfy some of these requirements, and a self-hosted Medusa or Saleor deployment is the option to evaluate when it does not. This page covers that constraint specifically, not a general replacement case, so the cost, feature and migration questions it raises belong to the sibling pages.

Start by writing down the exact obligation. Is it a rule that personal data stays inside the EU or EEA, a contract that names specific countries, a public-sector cloud standard, or a concern about third-country authority access? Each one is tested differently. Under GDPR, the EDPB Guidelines 05/2021 treat storage in a cloud outside the EEA, and remote access from a third country even for support, as transfers, so a region that does not match your data flows can still leave you exposed. Confirm with commercetools, in writing, which region hosts each data type, where support staff access it from, and which subprocessors touch it. Ask the same questions of any vendor you consider, and confirm the answers against the contract rather than the marketing page.

If the answers do not fit, self-hosting shifts these decisions to you. You choose the cloud account, data center or air-gapped network, and you control where PostgreSQL, Redis and S3-compatible file storage run for Medusa, or PostgreSQL, Valkey or Redis and Celery workers for Saleor. The trade-off is that you also carry the operations, backups, patching and evidence for those controls. Confirm with your legal and compliance team which requirements a self-hosted stack must meet, and with your architects which data flows can stay in your environment, before you compare platforms in detail.

What data residency rules require for commerce data

Residency decisions for order and customer data turn on where data is stored, who can reach it remotely, and which foreign authorities can compel access. The cards below take each rule in turn and say what it means for an order record that leaves the EEA or sits with a provider under foreign law.

Transfer conditions under Article 44

GDPR Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. Customer names, addresses, order histories and payment references all count as personal data. Before choosing a commercetools region or a self-hosted location, map every place order data is stored, processed or backed up, and confirm which of those places sit outside the EEA. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).

Remote access counts as a transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration. Cloud storage outside the EEA is also a transfer. For order data, this covers vendor support engineers, offshore operations teams and integrators who open order records from outside the EEA. Ask each provider where its administrators sit and which support tooling can display customer records.

Schrems II and the Data Privacy Framework

The Court of Justice invalidated the EU-US Privacy Shield in Case C-311/18 (Schrems II) but held that standard contractual clauses remained valid. The Commission's 2023 adequacy decision covers only US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Check whether each US-linked vendor is on that list today, and plan for the transfer tool to change if the appeal succeeds.

CLOUD Act reach over stored data

The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether the data sits inside or outside the United States. A US-parented vendor can therefore be compelled to produce EU-hosted order data. Ask vendors how they respond to such requests, and record that exposure in your transfer impact assessment before engaging them.

Foreign court orders under Article 48

GDPR Article 48 allows a third-country court judgment or administrative decision demanding personal data to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. A foreign order that lacks such a basis does not become enforceable in the EU on its own. Your contracts should require the processor to notify you of such requests and to challenge orders where the law allows.

Non-personal data under Data Act Article 32

Article 32 of the EU Data Act (Regulation (EU) 2023/2854) requires data processing service providers to take technical, organisational and legal measures against third-country governmental access to non-personal data held in the Union where that access would conflict with Union or national law. Product catalogs, pricing and inventory counts often fall under this duty rather than the GDPR. Ask providers which measures they apply and how they document them.

What a commercetools region choice covers and what it leaves open

A region choice fixes where commercetools hosts the platform, but on its own it does not answer which data sits there. The topic describes five isolated regions on Google Cloud and AWS, so start from the region you select and work outward. Ask commercetools in writing which customer records, order data, carts, backups, replicas and logs are stored in that region, which sub-processors touch them, and which of those sub-processors operate outside it. Get the answers tied to the commercetools data processing terms, then have your legal team test them against your own transfer assessment under the GDPR. Treat the region name as a fact to verify, not as a compliance position you can record.

Access from outside the region is the gap most teams miss. The EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when the person only views data on a screen for support or administration. Ask commercetools for the support and engineering roles that can reach production data, the countries those staff work from, whether access requires case-level approval, and how that access is logged. Then ask about legal process. Under 18 U.S.C. 2713, providers of remote computing services must preserve or disclose data in their possession, custody or control, whether it sits inside or outside the United States. Ask how commercetools would respond to such a request and whether it would notify you first.

Self-hosting moves these questions into your own contracts and infrastructure, which is the main reason to consider it. Running Medusa or Saleor in a cloud account or data center you select means you choose the region, the storage and the operators, and you decide who sees production data. It also means your team operates the components commercetools runs for you. Medusa needs PostgreSQL, a Redis database, a server instance and a worker instance, with S3 for file storage. Saleor needs its API, its Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. Under the EU Data Act, customers have a right to switch to on-premises infrastructure with a 30-day transition, so ask what exit terms apply before you sign.

Which open-source platforms meet a residency constraint

This table compares Medusa and Saleor against common residency requirements: license terms, where data sits when you self-host, and the components you must run yourself. Read the rows as a checklist for which platform fits your hosting constraints, then confirm each open item with the vendor and your own assessor before committing.

Requirement or factor	Medusa	Saleor
License for the core platform	MIT for the core commerce framework	BSD-3-Clause for the platform
Licensed features beyond the core	Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc.	Confirm with Saleor which capabilities, if any, sit outside the open-source repository or Saleor Cloud
Where data sits when self-hosted	In the PostgreSQL, Redis and S3 resources you provision in the region you choose	In the PostgreSQL, Valkey or Redis and storage resources you provision in the region you choose
Stateful components you operate	PostgreSQL, Redis, S3 file storage, plus API and worker instances	PostgreSQL, Valkey or Redis, Celery workers, the API and the Dashboard
Background processing	A separate worker-mode instance handles background tasks	Celery workers handle background tasks alongside the API
Extension model	Modules and workflows inside the Medusa codebase	Webhooks, apps, metadata and API extensions, without in-process plugins
Release referenced in research	Medusa v2.21.2, released on September 28, 2026	Saleor 3.23.42, released on October 16, 2026
Confirm before choosing	Whether any residency-relevant feature you need sits in Enterprise Edition	Which hosting region your chosen infrastructure provider offers for each component

Medusa or Saleor by constraint type

When the requirement is that personal data stays in the EEA and no third-country party can access it, the question is less about the platform and more about where every component runs. Both Medusa and Saleor can be deployed in infrastructure you select in an EU region, so the residency work becomes one of verifying each service in the stack. Treat the storage, the database, the cache and any managed add-ons as separate items. The EDPB guidelines treat remote access from a third country, even display-only support access, as a transfer, so the operations model matters as much as the hosting location.

Saleor footprint: Running Saleor means the API, the Dashboard, PostgreSQL, Valkey or Redis and Celery workers, deployed with Docker. Each container and volume can be placed in an EU region you control.
Medusa footprint: Medusa needs PostgreSQL, Redis, and a server instance and a worker instance, all Node.js and TypeScript services. Locate the S3-compatible file storage in the same EU boundary.
Support access: Confirm which staff, vendors or contractors can open shells, dashboards or logs from outside the EEA, since that access can itself be a transfer.
Managed add-ons: Confirm that any managed database, email, monitoring or CDN service keeps logs and backups in the EEA.
Hosting provider: Confirm that your cloud provider is not subject to third-country access rules that could compel disclosure of data in the clear.

Before you commit, ask your DPO to confirm the data flow diagram matches what your operators can actually reach from outside the EEA.

How to deploy Medusa or Saleor inside your own residency boundary

This sequence takes a residency boundary you define and ends with a self-hosted Medusa or Saleor stack running inside it, with backups, access controls and a documented check that no data leaves the boundary.

Define the boundary and choose the hosting location
Your legal, privacy and security teams document which personal and order data must stay inside the boundary, and which entities may administer it. Then select the cloud account, data center or air-gapped network that will host the stack, confirming with the provider which regions, support access paths and backup locations it uses. Done means a signed-off boundary document that lists every location where data will be stored, processed or accessed for support.
Provision PostgreSQL and Redis or Valkey
Your platform engineers create the managed or self-run PostgreSQL database and the Redis or Valkey instance inside the chosen location, with private networking only and no public endpoints. Medusa needs both for its database and its production caching, event bus, workflow engine and locking, and Saleor needs PostgreSQL plus Valkey or Redis for its background work. Done means both services accept connections only from the application subnet, and the team can show that network rules block any other path.
Configure object storage and secrets
Create an S3-compatible bucket inside the boundary for product files and uploads, which Medusa's production setup expects, and scope its access keys to the application identity only. Generate the COOKIE_SECRET and JWT_SECRET values for Medusa and store all database credentials and secrets in your secrets manager, not in source control. Done means the application identity can read and write the bucket and no human account holds long-lived keys.
Deploy Medusa server and worker instances
Run the Medusa instance in server mode for the API and admin dashboard, and a second instance in worker mode for background tasks, both pointing at the same PostgreSQL and Redis. The predeploy script applies database migrations before each startup, so run it as a controlled release step rather than letting replicas race. Done means both instances start, the migration log shows a clean run, and the /health endpoint returns a healthy response on the server instance.
Deploy Saleor API, Dashboard and Celery workers
For Saleor, deploy the API, the Dashboard, the Celery workers and the database and cache services with the Docker Compose setup or your own container platform. Plan for at least 5 GB of memory for Docker, as the Saleor Docker Compose documentation states, and set every configuration value through environment variables so that the same image runs in each environment. Done means all services report running, the Dashboard reaches the API, and a test product can be created and read back.
Set backup and restore procedures
Schedule encrypted backups of PostgreSQL and the object storage bucket to a location inside the boundary, and keep their retention rules in the boundary document. Restore a backup into a separate environment at least once and confirm that orders, customers and product files come back intact. Done means a documented restore test with recorded results, and the team knows who may authorize a restore.
Apply access controls and administrator roles
Restrict administrator access to named individuals who connect through your identity provider and multi-factor authentication, and separate roles for catalog, order support and infrastructure. Keep production database access out of day-to-day support workflows and log every privileged session. Confirm whether the role-based access control features you need sit in the open-source core or in Medusa's Enterprise Edition, which requires a commercial agreement. Done means an access review lists every account, role and log destination.
Verify that no data leaves the boundary
Map every outbound connection from the application, including payment gateways, email, analytics, error reporting, package updates and vendor support tools, and block or approve each one explicitly. Confirm that remote support sessions do not display or copy personal data from outside the boundary, since the EDPB treats such viewing as a transfer. Done means a signed network flow inventory, egress rules that match it, and a test showing that unapproved destinations are blocked.

Evidence that shows where order data actually lives

A region choice only holds up if you can show where order and customer data is stored, processed, accessed and transferred. The six artifacts below connect the commercial position, the technical deployment and the exit plan, so each claim about location can be traced to a document and a configuration. DeployOpen prepares this evidence, but auditors and regulators decide whether it is sufficient.

Data flow and transfer map

A diagram and table listing each system that holds order, customer or payment-related data, where it runs, which personnel or processors can reach it, and every point where data leaves the originating region. For a self-hosted Medusa or Saleor stack, include PostgreSQL, Redis or Valkey, object storage for files, the API and worker instances, the storefront, the payment gateways and any email or analytics tools. Check that backups and logs are on the map too, since they often sit outside the primary database and region.

Processor contracts and sub-processor lists

The signed data processing terms with every hosting provider, managed database operator, email service and support vendor, plus the current list of sub-processors and their locations. Confirm which entity contracts with you, whether any sub-processor sits in a third country, and how you will be notified of changes. Under the GDPR, a processor relationship is only one part of the picture, so pair these contracts with the transfer analysis described in the next card.

Transfer impact assessments

A written assessment for each transfer or remote access path that leaves the EEA or the region you chose, following the logic of EDPB Recommendations 01/2020. It should record whether the importer needs access to data in the clear, what the destination's public authority powers allow, and which supplementary measures you considered. The guidance says that where those powers exceed what is necessary and proportionate, no effective technical measure may exist, so the assessment must state that conclusion rather than assume encryption solves it.

Access logs for remote support

Records of every session in which an engineer, vendor or support desk viewed or changed order data, including the location of the person connecting. The EDPB guidance treats remote access from a third country as a transfer even when data is only displayed on a screen, so support access is often the transfer that teams overlook. Ask whether logs cover database consoles, admin dashboards and bastion hosts, and how long they are kept.

Deployment configuration and region records

Infrastructure as code, environment configuration and a region register that show the exact cloud account, region or data center for every component. For Medusa, this includes the server and worker instances, database credentials, the COOKIE_SECRET and JWT_SECRET values stored outside source control, and the /health checks. For Saleor, record the environment variables and Docker Compose settings. Keep a dated copy so you can show the configuration that was live at any past point.

Data Act switching-rights plan

A documented procedure for leaving a data processing service, whether for another provider or for on-premises infrastructure. Under the Data Act, customers have the right to switch with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. The plan should list the data sets to export, the order of cutover, the test evidence and who signs off. It also documents whether the vendor's provider-side measures under the Data Act protect non-personal data from third-country government access.

What does a self-hosted residency migration cost and take?

What drives the total cost of a self-hosted Medusa or Saleor migration?

The total is driven by a few components, and each is paid to a different party. Engineering time for migration, integration and hardening is usually the largest one-time cost. The recurring costs are PostgreSQL, Redis, the Medusa server and worker instances (or Saleor's API, Dashboard and Celery workers), object storage for files, monitoring and backups, and the people who run the platform. Medusa's core is MIT licensed, so the software line is zero, but Enterprise Edition features need a commercial agreement with MedusaJS, Inc. Cloud or data center costs depend on the region and sizing you choose, which only your own infrastructure team can estimate. Ask each vendor and provider for its component price in writing before comparing totals.

Can our own team run a residency migration without outside help?

It depends on your team's experience with PostgreSQL, container platforms, Node.js or Python services, and commerce data models. A team that already operates production databases and CI/CD can often handle the deployment, but the work also includes mapping product types, prices, customers and orders, rebuilding discounts and checkout logic, and verifying that order flows match. Those tasks need commerce and integration knowledge that is easy to underestimate. Many organizations split the work: internal staff keep ownership of the infrastructure and data, while an implementation partner handles the parts that are new to them. Assess your skills gap against each workstream before deciding.

How long does a self-hosted residency migration take?

The duration depends on the scope you agree: how many storefronts, markets, integrations and custom extensions move, how clean the commercetools data is, and how long you run both backends in parallel. No general timeline is published here, so ask for one tied to a written scope. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Plan for the cutover period to take longer than the technical deployment, because order flow verification is where most of the risk sits.

What do the EU Data Act switching rights mean for our timing?

Under the EU Data Act, which has applied since 12 September 2025, customers can switch from a data processing service to another provider or to on-premises ICT infrastructure. The Act sets a maximum two-month notice period and a 30-day transition, and bans switching charges from 12 January 2027 (Articles 25, 29 and 50 of Regulation (EU) 2023/2854). Because the notice and transition periods are capped, you should plan your internal decision and parallel-run window well before you give notice. Check your contract terms with the provider and get legal advice on how the rules apply to your specific agreement.

Do we need Medusa Enterprise Edition features for a residency migration?

Only if your requirements include a feature that sits in the Enterprise Edition. The core commerce framework is MIT licensed, and Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Map your admin roles and access needs before choosing. If you need granular roles, you will need that agreement as a recurring cost. If a simpler access model covers your staff, the core may be enough. Confirm the current feature split with MedusaJS directly, since editions can change.

What should we ask for in a migration quote?

Ask for a written scope that lists the storefronts, markets, data types, integrations, custom extensions and environments included, along with the deliverables and acceptance criteria. Request a separate line for each cost component: engineering effort, hosting and sizing assumptions for PostgreSQL, Redis and instances, object storage, backup and recovery, monitoring, and any Enterprise Edition or hosting agreements. Ask what is one-time and what recurs, which items are excluded, and how changes to scope are priced. Also ask for the support or retainer options after go-live, including upgrade handling and continuous testing, and for the handover documentation you will receive.

Does a self-hosted deployment remove the need for compliance work on residency?

No. Hosting in infrastructure you choose gives you control over where data is stored and who administers it, but it does not by itself satisfy GDPR Chapter V or the rules on third-country access. Remote access from a third country counts as a transfer under EDPB Guidelines 05/2021, even when data is only displayed on a screen. Storage and access arrangements, subprocessors and any cloud provider's legal exposure all need review. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or certifications.

What to confirm with commercetools and your own legal team

Before you rely on a commercetools region choice for a transfer assessment, get written answers on four points. First, the exact locations where customer and order data are stored, including backups, logs, search indexes and any analytics copies, not only the name of the region. Second, whether commercetools staff or sub-processors can view data from outside that region for support, incident response or troubleshooting. The EDPB's guidelines treat remote access from a third country, even display-only access, as a transfer, so a region label alone does not answer this question. Ask for the current sub-processor list and the notice process for changes to it.

Third, confirm the legal basis commercetools relies on for any transfer that does occur. Ask which transfer tool applies, whether the standard contractual clauses under Commission Implementing Decision (EU) 2021/914 are incorporated into your contract, and what transfer impact assessment commercetools has documented. Ask how it responds to government access requests under U.S. law, including the CLOUD Act provision, and whether it commits to challenging overbroad requests. Request these in writing rather than from a sales or account contact.

Fourth, track the status of the EU-US Data Privacy Framework. Commission Implementing Decision (EU) 2023/1795 covers only U.S. organizations on the Data Privacy Framework List, and the appeal in Case C-703/25 P is pending. Ask commercetools whether it is on that list and what its plan is if the adequacy finding changed. Then take the answers to your data protection officer and external counsel, who can reach the legal conclusion. This page does not provide one. Record the answers and their dates, because they will shape the migration timeline if you decide to self-host Medusa or Saleor in infrastructure you choose.

How DeployOpen deploys Medusa or Saleor under a residency constraint

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a residency requirement, that means the platform, its database, file storage and background workers sit where your legal team says they must, and the evidence that proves it is produced alongside the build.

How we scope

Map each data flow for customers, orders and payments, including support access from outside the region.
Agree in writing which Medusa or Saleor components run in which location and under whose administrative control.
Confirm with your counsel and auditors which controls DeployOpen prepares, since we do not issue attestations or certifications.
Engagements are fixed-scope, so deliverables and timelines are settled in writing before work starts.

How we build

Deploy PostgreSQL, Redis or Valkey, object storage and the API, dashboard or worker processes in the infrastructure you select.
Configure secrets, environment variables and access controls so no component reaches data outside the agreed boundary.
Run security testing against the storefront, APIs and cloud configuration before cutover, and record the findings.
Set up backups, restore tests and upgrade procedures for the database and file store within your own environment.

How we hand over

Document architecture, data location, network paths and the access model so your team can audit them.
Provide runbooks for migrations, health checks and incident response tied to your own environment.
Deliver a cyber range or training session on the platform if your team needs hands-on practice before go-live.
Hand over credentials, infrastructure code and evidence packs with a clear record of what was delivered.

How we support

Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
Plan version upgrades of Medusa or Saleor against the release notes and your residency controls before applying them.
Ask any vendor or hosting provider in the quote to confirm where support staff and logs are accessed from.
Revisit the data location map whenever the storefront, payment provider or analytics tooling changes.