Magento Open Source multi-store setup

Magento Open Source multi-store setup for several brands, countries or languages

A team that needs several storefronts on one Magento Open Source installation should decide the shape of the hierarchy before anyone builds a theme or loads a catalog. Magento Open Source organizes sites, stores and store views in a three-level hierarchy: a website sits at the top, one or more stores (store groups) sit under each website, and one or more store views sit under each store. The design of that hierarchy decides which catalogs are shared, which customer accounts are shared, which currencies apply and where translations live. Changing the structure later is possible, but it touches data that has already been scoped, so it is worth settling first.

The usual question is whether separate brands, countries or languages belong in separate websites or in separate store views under one store. A separate website gives each market its own domain or base URL and its own scope for customer accounts and, depending on configuration, prices and promotions. Store views under one store share the root category and therefore the catalog tree, which suits a single brand offering the same products in several languages. Several stores under one website share customer accounts and can share prices. Ask your team to write down, for each brand or market, which of the following must differ: catalog, customer accounts, prices, currency, tax configuration, and content. Each difference points to a level in the hierarchy.

Several configuration settings are scoped to the website, store or store view, and the Stores > Configuration pages show a scope switcher for each. Currency settings, the base currency and allowed currencies in particular, have their own scope rules, and the catalog price scope setting determines whether product prices are global or per website. Customer account sharing is a separate setting with its own scope. Changing the account-sharing or price scope after launch can require reindexing and can affect how existing customer records are matched, so the team should test these settings on a staging copy with realistic data before go-live. Plan a short review of every scope setting, with one owner signing off on each.

Translations and locale data are handled per store view through locale settings, theme selection and language packages. Magento Open Source uses language packages, which are a component type alongside modules and themes, so each target language needs a package that matches the installed version. Confirm which language packs and locales are available for your installed release and whether your theme covers the strings your content needs. Store view content such as CMS pages and product text is entered separately for each view, so the project plan should include who translates and approves that content.

Confirm the multi-store behavior against the exact version you plan to run. The magento/magento2 repository and Adobe's developer documentation describe the hierarchy and scope model, but the admin screens, default settings and available options can change between 2.4.x releases, and Magento Open Source is a different edition from Adobe Commerce. Check the release notes for your target line, run a test with two websites and at least one store view per language on a staging environment, and verify domain routing, cart and checkout, and tax and currency output for each market before you commit to a structure.

Which structure fits which business model

This table compares the common ways to lay out websites, store views, catalogs, customers, currencies and tax on one Magento Open Source installation. Read each row by asking when the option fits your business, what it makes harder later, and which settings to verify in the release you plan to install. The main takeaway is that scope decisions are costly to reverse, so confirm them before catalog and customer data are loaded.

Structure	When it fits	What it complicates	Confirm in the installed version
One website, several store views	One brand selling in one country, with content in several languages.	Shared catalog, prices and tax. Translation workload. Store view admin roles need careful setup.	Which settings support store view scope, and that the locale packages you need are installed.
Separate websites per brand or country	Brands or countries with different domains, pricing, legal entities or tax rules.	Each website needs its own domain, base URLs and checkout setup. Reporting spans websites.	Website-level scope for prices, customer accounts, promotions and base URL configuration.
Shared catalog and customers	One product range and one customer login valid across all sites.	A customer account works on every site, so country-specific data and consent need extra handling.	Customer account sharing scope (global or per website) and how it handles duplicate email addresses.
Separate catalogs and customers	Brands with different ranges, or regulators requiring separated customer data.	Two sets of catalog and customer data to maintain. Product sharing and cross-site reporting become manual work.	Whether catalog and customer scope can be set per website, and how imports target each scope.
Per-scope currency	Storefronts selling in local currencies at different price levels.	Exchange rate updates, rounding and displayed prices must be checked for each currency.	Allowed currencies per scope, the exchange rate source, and whether your payment provider settles in that currency.
Per-scope tax settings	Sites selling into different tax jurisdictions or showing prices with different tax treatment.	Tax rules, classes and rates must be configured per scope and tested for each destination.	Tax rule scope, price display including tax, and tax calculation options in the installed release.
Promotions and cart rules	Campaigns that should run on one site only or across several sites.	Rules must be assigned to the right websites, and coupon behavior across scopes needs testing.	Website assignment for cart and catalog price rules, and coupon usage limits per site.
Admin permissions by scope	Local teams who manage one brand, country or language.	Role scopes limit what admins see, while orders and reports may still need a central view.	Which resources can be restricted by store view or website in the installed role editor.

Which settings are global and which change per scope

Magento Open Source stores configuration at four levels: global, website, store and store view. Each setting takes effect at the level where it is saved and at the levels beneath it, so the same installation can behave differently for each brand, country or language. The cards below cover the settings that most often surprise teams after launch.

Configuration scope and inheritance

Global settings apply to the whole installation, websites narrow the scope to a set of store views, stores group store views under one root category, and store views carry the storefront language and presentation. A value saved at a higher level is inherited unless it is overridden lower down. Before the build, confirm which level each setting lives at, because a change made at the wrong level is easy to miss in testing and hard to trace later.

Base URLs and domains

Base URLs are set per website or store view, and they drive generated links, redirects, cookie domains and asset paths. Mixing domains, subdirectories and store codes on one installation changes how sessions and cookies are scoped. Record every hostname, its certificate, its DNS record and its store view before configuring, and check that each one resolves to the intended store view after launch.

Customer account sharing

The customer account sharing option decides whether customers are shared across websites or kept separate for each website. This setting is global in scope and is difficult to change once customers exist, because accounts and their addresses must be migrated or merged. Decide it with the business owners of each brand and country, and confirm how shared accounts will handle different tax, currency and pricing rules.

Catalog price scope

Catalog price scope is a global setting that controls whether product prices are shared across all websites or stored separately for each website. When prices differ by market, the choice determines how advanced pricing, imports and ERP updates write data. Confirm the scope with the pricing owner before importing any price file, since a later change can require reloading prices and re-checking every affected product.

Currency and display currency

Base currency is a global setting, while default display currency and allowed currencies can be set per website. Exchange rates must be maintained for every displayed currency, and the base currency should match the accounting currency used for orders and reporting. Before launch, test checkout, invoices and refunds in each store view, and confirm with finance how conversions and rounding will be recorded.

Locale and translations

Locale is set per store view and controls date, number and address formats, along with the language pack used by the storefront and emails. Translation files, CMS pages and product content are maintained per store view, so every language needs its own content plan and owner. Confirm which locales are installed, which strings are translated by the team and which are left to the default, and test emails and checkout in each one.

How to build the store hierarchy in the right order

This sequence turns a business split into a tested Magento Open Source hierarchy of websites, stores and store views, where each domain, currency, language and customer rule is set on purpose and confirmed before the store opens to shoppers.

Document the business split first
Before anything is created in the admin, the merchandising, legal, finance and marketing owners agree on the list of brands, countries, currencies, languages and tax regimes that the installation must serve. Each proposed website, store and store view gets a named owner and a one-line purpose. The output is a signed-off map that the build team works from. The step is done when every owner has approved the map in writing and no scope is described as "to be decided" later.
Decide shared or separate catalog and customer data
For each website, the team decides whether products, categories, prices and customer accounts are shared across websites or kept separate. Magento's catalog price scope and customer account sharing settings control this, and they are difficult to reverse once customers and orders exist. Confirm the current options and their effects against the Magento Open Source documentation for your release, and record the decision with the reason behind it. The step is done when the decision log names each scope setting and the team has walked through one sample customer and one sample product across two websites.
Define the domain and base URL plan
The infrastructure and web teams map every hostname, path or subdomain to a store view, then record the base URL for each one, including the secure version and any country or language paths. They also confirm DNS, TLS certificate coverage, redirects and how the web server or load balancer passes the host header to the application. The output is a URL table that the build uses as its single source. The step is done when the table is reviewed against DNS records and certificates, and no hostname is left pointing at a default store view by accident.
Create websites, stores and store views
In the admin, the team creates the websites, then the store groups under each website, then the store views under each group, following the approved map exactly. Each website has one default store group and each group has one default store view, so the defaults are chosen deliberately. Names are kept consistent with the URL table so that later reports and support tickets are easy to read. The step is done when the store tree matches the map line for line and a screenshot or export of the tree is saved in the project record.
Set scope-level configuration
The team sets configuration at the correct scope: default, website, store and store view. Currency, locale, tax, shipping origin, customer group and email sender settings are the usual items that differ by scope. Settings are entered once at the highest scope that applies, then overridden only where the business split requires it, so later changes do not need to be repeated in many places. The step is done when a configuration inventory lists each overridden value with its scope and owner, and a second person has checked it.
Install and assign language packages
The team installs the language packages for each locale the business has approved, then assigns each one to the correct store view and checks that the translated storefront, checkout and transactional emails use it. Product and category content is translated separately, and this is a content task that must be scheduled with the merchandising owners. Any translation gaps are logged with a named owner. The step is done when each store view renders the intended language on the storefront, in checkout and in a test order confirmation email.
Test each scope with a checklist
The QA lead runs a written checklist for every website, store and store view. For each scope, the checklist confirms that the URL resolves to the intended store view, that the currency and language are correct, that a customer account behaves as designed (created, logged in and shared or isolated as decided in step two), that tax and shipping apply correctly and that a test order is placed and routed to the right sender and email. Failures are logged and retested. The step is done when every checklist line is signed off for every scope, and the signed checklist is stored with the release record.
Record the hierarchy and hand it over
Before go-live, the team exports the final store tree, URL table, configuration inventory and signed checklist into the operations runbook. They name the owner for each scope and document how a new store view or domain is added later, including which steps in this sequence must be repeated. The handover is complete when the operations team has walked through one addition in a non-production environment and confirmed the runbook is accurate.

How translations and language packages work per store view

Adobe's developer documentation describes modules, themes and language packages as the component types used to extend Magento Open Source, so a language package is one of several extension mechanisms rather than a separate product you install once. Before you promise a multi-language storefront, confirm which translation layer covers each piece of text the shopper sees. Interface strings, such as checkout labels and system messages, are handled differently from product names and descriptions, and CMS pages are a third category. Coverage is not uniform across these four areas: product content, CMS pages, system strings and custom module text each need their own check.

Start by asking your theme vendor and your development team which strings are exposed for translation. A theme may wrap its own labels in translation calls while hard-coded text in a custom module, a checkout block or a third-party extension stays in one language. List every template, block and module that renders visible text, then record whether each one passes its strings through the translation system. This inventory becomes your scope baseline and shows where developers must add translation hooks before the store launches in a second language.

Content translation is a separate workload from interface translation. Translating the interface through language packages covers what the platform and theme display, but it does not translate product catalogs, category descriptions, CMS pages, email templates or promotional copy. Each store view needs its own content records, so a Spanish store view can show a Spanish product name only if someone enters or imports that value for the store view scope. Plan who writes, reviews and approves each content type, how changes are versioned, and how translators receive source text. Those are staffing and process decisions, and they often take longer than the technical configuration.

Verify language package behavior in a staging copy that mirrors your production store views, theme and custom modules. Load the package for each target locale, switch between store views, and check that fallback text appears where you expect it. Confirm the version of Magento Open Source you run against Adobe's system requirements and release notes, because language packages and theme code must match the platform release. Ask your partner for a written list of exposed strings, untranslated gaps and the test cases used, so that the translation scope is visible before go-live rather than discovered by shoppers.

Security and operational considerations for multi-store installations

Multi-store installations share one codebase, one database and one set of server settings, so a decision made for one domain often affects the others. The cards below cover the controls that tend to surface after launch: who can administer each store, how shared customers are handled, how pages are protected and cached, and how the platform is patched and retested. Check each one per domain, not once for the whole installation.

Admin role scoping across stores

Admin users can be limited by role, so a regional editor does not see or change every website, store and store view. Check each role against the scopes it should reach, then test with a non-administrator account on every store. Include translation and content editors, since their roles often end up broader than planned. Review roles whenever you add a store, because a new scope may need its own access decisions.

Shared customer accounts and privacy

When stores share a customer base, one customer record can serve several storefronts, which makes account sharing a privacy and access decision as well as a catalog one. Confirm with your legal and privacy team which customer data each store may read, and whether your privacy notice describes that sharing. Test that a customer signed in on one domain cannot reach another brand's data, and check which admin roles can view or edit shared accounts.

Content Security Policy and HTTPS on every domain

Each domain serves its own pages, so each needs valid HTTPS and its own Content Security Policy testing. Adobe's developer documentation says Magento Open Source supports CSP headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Test payment and third-party scripts on every domain in staging before enforcing, because a policy that works for one brand may block a script another brand depends on.

Varnish caching with several domains

Adobe documents Varnish as the full-page cache accelerator for self-managed installations. With several domains, the cache must keep pages for each host separate, so a currency, language or customer-specific page is never served to another store. Confirm the Varnish configuration for each base URL, the purge behavior after content changes in each store view, and how logged-in customers bypass the cache. Test with the hostname of every store, using the same hostnames your visitors use.

Patching on a supported release line

Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. Regular support for 2.4.7 ends May 31, 2027, and for 2.4.9 it ends May 31, 2029. Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant, and its release schedule says security patches ship at least annually for all supported lines. Record the patch cadence and an owner in your operations runbook.

Retesting each domain after upgrades

A patch or upgrade can change behavior on every domain at once, so a clean test on the main store does not prove the others work. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as drivers of upgrade effort, and it references the Upgrade Compatibility Tool. Keep a test matrix per domain covering login, checkout, payments, search, translated pages and CSP, and confirm it before each change window.

What to confirm before you commit to a layout

Before you choose between websites, store groups and store views, confirm the exact Magento Open Source 2.4.x release you run today and when its regular support ends. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. The published end-of-regular-support dates are August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. If your planned rollout overlaps the end date of your current line, the multi-store build and a version upgrade will land in the same window. Ask your partner whether the layout work can be sequenced after the upgrade, and confirm the target release against Adobe's system requirements, since only the listed combinations of PHP, database, OpenSearch, Redis or Valkey and RabbitMQ are supported.

Next, check every extension, theme and custom module against the layout you have in mind. Ask each vendor in writing whether the product supports multiple websites and store views, which configuration scope its settings save to (default, website or store view), and whether its data such as prices, tax rules, customer records or feeds respects website boundaries. Many extensions were written for a single storefront, and their settings can quietly write to the default scope. Ask for test evidence from a multi-store installation, not a general statement of compatibility. Custom modules need the same review. Your team or partner should inspect the scope attributes declared in each module's system configuration and confirm how each setting behaves across store views. Record the results in a matrix of component by scope, and treat any unknown as blocking until it is answered.

ERP and payment integrations must know which website or store view owns each order, price, stock figure and payment. Confirm what store identifiers the ERP receives on each order, such as store code, website code and store ID, and how those map to legal entities, warehouses and price lists. Ask which inventory sources serve which websites and whether your planned API calls for catalog, price and stock updates carry the store scope in their payloads. On the payment side, confirm which methods are enabled per website, which merchant account settles each store, how each currency is handled, and how refunds and gateway notifications are routed back to the correct store. Agree on a test plan that places orders in every store view and reconciles them through to the ERP and the settlement report before go-live.

Analytics and search each scope differently, so both need an explicit decision. Confirm whether your analytics tags and consent settings are configured at the default, website or store view level, and whether revenue and currency values are reported separately for each store. For search, ask your hosting team how OpenSearch indexes are created for each store view and language, how many indexes the layout produces, and how reindexing time changes as store views are added. Adobe's 2.4.9 requirements list OpenSearch 3, so confirm that version and its supported configuration with your team before you size the cluster. Write the answers to all of these questions into a decision record and get sign-off from the business owner, the ERP lead and the security team before design work begins.

Limits and what to confirm in your environment

A multi-store Magento Open Source design is bounded by the distribution and version you run, the hosting stack beneath it, and how each scope adds indexing, cache and reporting work. The cards below list the limits to confirm before the architecture is fixed, so that the design is tested against your own environment rather than assumptions.

Websites, stores and store views

Confirm how many websites, store groups and store views your planned architecture must support, and whether the chosen hosting, database and application servers have been sized for that count. Each added scope multiplies configuration, theme assignments and translation work, so the count should come from the business plan, not from what the platform allows. Ask for a load test that reflects the planned scope count before go-live.

Indexing load per scope

Indexers run per scope, so catalog, price and search indexing work grows as store views and catalogs are added. Check how long full reindexes take on your hardware with realistic product counts, and whether scheduled and on-save indexing will finish within your update windows. Ask the implementer which indexers run in update-by-schedule mode for each scope and how queue consumers are sized to match.

Cache and full-page cache pressure

Each website, store and store view adds cache entries and full-page cache variations, which raises memory use and the hit rate you need to protect storefront performance. For self-managed installations, Adobe documents Varnish as the full-page cache accelerator, so confirm the Varnish version, memory allocation and purge behavior your chosen release combination supports. Test cache invalidation after price and content changes for every scope.

Reporting across separate catalogs

When brands or countries use separate catalogs or customer sets, cross-scope reports in the admin will not reflect a single view of sales, customers or products without extra work. Decide early which reports must combine scopes and whether they will come from the admin, a data warehouse or an export pipeline. Confirm with the reporting team which fields are scoped and how currency conversion and store view attribution are handled.

Distribution and version verification

Mage-OS and other community distributions are built on Magento Open Source but may differ in module behavior, patch timing and compatibility with extensions, so the same multi-store configuration may not behave identically. Record the exact distribution, release and patch level in use, then compare it with the matching Adobe requirements and lifecycle dates for that line. Test scope-specific behavior on that exact stack, not on a generic Magento 2 assumption.

Hosting requirements to verify

Adobe publishes system requirements per release, listing supported PHP, database, search, cache, queue and web server versions, and states that only the listed combinations are supported. Confirm that your hosting platform, managed services and operating system support the exact combination for the release you choose, and check the end-of-support date for that line. Ask the hosting provider to document how it handles upgrades to each listed component.

What does a multi-store Magento Open Source build cost and take?

What makes a multi-store Magento Open Source build cost more or less?

The biggest cost drivers are the number of scopes you create and how much you share between them. Each website, store and store view adds configuration, testing and content work, and every decision about shared or separate catalogs and customer accounts changes how much logic must be built and verified. The main drivers are:

Number of websites, stores and store views
Whether catalogs, prices, customer accounts and orders are shared or separated
Number of integrations, such as ERP, payment, shipping and tax services, and whether each one is per scope
Translation volume and who produces the translations
Theme work per brand or locale, and the testing matrix that follows

Ask any partner to show how each driver maps to line items in a written scope.

Which parts of a multi-store Magento build are one-time and which recur?

The initial build, theme work for launch and first-time translations are one-time costs. Ongoing costs recur because Magento Open Source releases and security patches arrive on a schedule, and each new language, brand or market adds content and testing that continues after launch. Expect recurring costs for:

Patching and upgrades across the 2.4.x line, which Adobe recommends applying every patch cycle to stay secure
Translation updates when product content or promotions change
Testing of each scope after upgrades and extension updates
Hosting, search, cache and queue services that run in your infrastructure

Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the drivers of upgrade effort, so a heavily customized multi-store setup will cost more to maintain.

What does the client need to provide before a multi-store build starts?

The build needs decisions that only your business can make, and delays usually come from missing decisions rather than from technical work. Before design starts, you should have answers to the following:

Business structure: which brands, countries and currencies need their own store or view, and which must share a catalog
Domains and base URLs for each website, plus the certificates and DNS control to publish them
Named content owners for each language and market who approve copy and product data
Test users for each scope, with the roles and permissions they need to check their own pages
Tax, shipping and payment rules for each market, as stated by your finance and legal teams

Write these answers into the scope so they become acceptance criteria.

Can an internal team build a multi-store Magento Open Source store on its own?

An internal team can build it if it already has experienced Magento developers, a clear understanding of scope settings and the capacity to test every store view after each change. Many teams underestimate the work because scope settings interact in ways that surface only later, such as price scope, customer account sharing and URL rewrites. Check these before deciding:

Does the team have hands-on experience with Magento scope inheritance and configuration?
Can it test each website, store and store view, including checkout in each currency?
Does it have a plan for patching the 2.4.x release line on Adobe's published schedule?
Can it support the platform's infrastructure, including search, cache and queue services, for the life of the store?

If the answer to any of these is no, a partner can cover the gap, or the team can use a fixed-scope engagement for the build and keep the upgrades in-house.

How is a fixed-scope quote built for a multi-store Magento project?

A fixed-scope quote starts from a written scope that lists every website, store, store view, integration, translation set, theme and test cycle. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that document. Ask any provider to show:

A list of scopes with the sharing decisions for catalog, prices, customers and orders
Each integration, with the systems it connects and the data it moves
Translation scope, including who supplies the text and how many languages apply
Theme and custom module work, with the acceptance tests for each
The testing plan, the deliverables, and what is excluded from the build
Which tasks are one-time and which are ongoing support or upgrades

DeployOpen does not publish a price list, so a quote is the only way to see the cost for your scope.

What should be checked on the platform before the build is scoped?

Check the Magento Open Source release line, the required stack versions and the supported combinations before you size the build. Adobe lists the supported PHP, database, search, cache, queue and web server versions for each release, and it supports only the listed combinations. Confirm these with the vendor and your environment:

Which 2.4.x release you will launch on, and its end of regular support date in Adobe's lifecycle policy
Supported PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx versions for that release
Whether your cache layer will be Varnish, which Adobe documents for self-managed installations
How Content Security Policy settings will apply to each storefront and payment page

These checks affect hosting and testing effort, so put them in the scope before quoting.

How DeployOpen scopes and delivers a multi-store Magento Open Source build

DeployOpen plans, builds and hands over Magento Open Source multi-store and multi-language setups inside infrastructure you control. The work starts with a written map of websites, stores and store views, then moves through configuration, testing and documentation so your team can run the scope settings after handover.

How we scope

Map every website, store and store view with its domain, base URL, locale and currency before any configuration starts.
Record which catalogs, customer accounts, prices and promotions are shared across scopes and which are kept separate.
Engagements are fixed-scope, with the store structure, deliverables and timelines agreed in writing before work begins.

How we build

Configure scope settings, translation packs and custom themes or modules against the agreed scope map, not ad hoc per store.
Test each store view for URL routing, currency display, checkout and cache behavior, including the shared full-page cache setup.
Check Content Security Policy headers and payment pages in each scope, and confirm the components match the documented system requirements.

How we hand over

Deliver a scope register listing each setting that differs by store, website or language, with the reason it was set that way.
Document the steps for adding a store view, a language or a currency so your team can repeat them without a partner present.
Walk your administrators through the settings that most often cause surprises later, such as shared customer accounts and catalog scope.

How we support

Ongoing support, patch application and upgrade work are available as a retainer after handover.
Plan each patch cycle against the scope register so a change to one store view is checked across every affected scope.
Confirm with Adobe's upgrade guide and your own environment which customizations and integrations will need retesting before a release line change.