Multiple Magento Stores, One Server, One Admin

Magento 2 was built multi-store from the start, and the feature hangs off a four-level hierarchy: Global, then Website, then Store, then Store View. Everything in configuration belongs to one of those scopes, and choosing the right level for each storefront is most of the design work.

At the top, Global covers the whole installation: one catalogue of products, one admin panel, one set of admin users. Below that, a Website is the strongest separation Magento offers without a second installation: each website has its own customer accounts, its own prices, its own payment and shipping configuration and its own orders. That is the level you use for genuinely different businesses: a retail brand and a trade counter, or two brands owned by the same company. Beneath each website sit Stores, which mostly govern category structure, and beneath those, Store Views, which are the presentation layer: typically one view per language or currency, so a single website can serve an English view and a French view of the same shop.

The practical rule of thumb: different customers or different prices means separate websites; the same shop in another language or currency means another store view. B2B plus B2C splits and multi-brand retailers, the two classic multi-store cases, are both website-level jobs.

The payoff of the hierarchy is operational. One codebase means one set of extensions to licence and one upgrade to test, instead of repeating the work per store. One admin panel means your team manages every product, price list and order queue in one place, with each website mapped to its own domain, or to a path on a shared domain if you prefer. A product photographed and described once can be sold on three storefronts the same afternoon.

Each website sets its own base URLs in configuration, so brand-a.co.uk and brand-b.co.uk both point at the same server and the same installation, yet customers see two completely distinct shops with their own themes, prices and checkouts. Orders arrive tagged with the website they came from, so reporting per brand stays clean.

When a request arrives, something has to tell Magento which storefront to render. That job belongs to the web server, and it is done with two environment variables: MAGE_RUN_TYPE, which says whether the code refers to a website or a store, and MAGE_RUN_CODE, which names it. With nginx the standard approach is a map block keyed on the incoming hostname:

map $http_host $MAGE_RUN_CODE {
    brand-a.co.uk        brand_a;
    brand-b.co.uk        brand_b;
    trade.brand-a.co.uk  trade;
}

# inside the PHP location block:
fastcgi_param MAGE_RUN_TYPE website;
fastcgi_param MAGE_RUN_CODE $MAGE_RUN_CODE;

The map matches the Host header of each request to the website code you defined in the Magento admin, and the two fastcgi_param lines hand the result to PHP. Magento boots, sees the code, and serves that website's theme, catalogue rules and prices. Add a fourth brand later and the change is one line in the map, a new website in the admin, and its base URLs, no new server and no new installation.

The same mechanism works with a value of store instead of website when you want to route directly to a specific store view, for example a dedicated domain per language. Either way the routing lives in one readable block in the vhost, which is exactly where you want it when something needs debugging at 5pm on a Friday.

Older multi-store guides, including the one this article replaces, insisted that every SSL-secured store needed its own dedicated IP address, and priced multi-store hosting accordingly. That advice is out of date and has been for years. It dates from pre-SNI shared hosting, when a server could only present one SSL certificate per IP address, because the certificate had to be chosen before the browser said which site it wanted.

SNI, Server Name Indication, fixed that: the browser announces the hostname at the start of the TLS handshake, and the server picks the matching certificate. It has been standard across every mainstream browser, crawler and payment provider for years. One server on one IP address now serves a separate, dedicated certificate for each domain it hosts, and Let's Encrypt issues those certificates per domain at no cost, with automatic renewal. Three storefronts, three padlocks, one IP, zero certificate spend.

So if a host quotes you for extra dedicated IPs "because each SSL store needs one", you are reading a pricing sheet from a previous decade. There are still niche reasons to want an extra IP, a separate mail sending reputation for instance, but SSL for multiple stores is not one of them.

Dropping the fake constraint makes room to respect the real ones. The first is sizing. Every website on the installation shares one database, one set of indexers, one cache pool and one search engine, so the server must be specified for the combined catalogue and the combined traffic. Two stores of 20,000 products each behave like one store of 40,000 products at index and cache level, and a promotion that spikes one brand competes for the same CPU as the checkout on the other. Reindexing, cache warming and search all scale with the total, not the average.

The second is sessions. Separate checkouts per domain work perfectly, but a shared basket across different top-level domains is not possible with standard sessions, because cookies are bound to a domain and the browser will not present brand-a.co.uk's session cookie to brand-b.co.uk. Subdomains of one parent domain can share a session; distinct brands on distinct domains get distinct baskets, which in practice is what their customers expect.

Neither constraint argues against multi-store. They argue for treating it as one bigger store when you buy hardware: the classic B2B plus B2C split and the multi-brand retailer both thrive on a single installation when the box underneath is sized for the sum.

Multi-store multiplies load on the same hardware, which is exactly the situation where single-tenant hosting earns its keep. On a shared platform, your three storefronts compete with strangers for the same CPU; on dedicated Magento hosting the whole server answers to your installation alone, and the peaks of one brand only ever contend with the quiet hours of another brand you also own.

On EveryHost plans the stack is built to your store's required versions and specified against the combined catalogue and traffic across every storefront, not a per-site average. Multiple stores on one server is supported on every dedicated plan: separate vhosts per domain, per-store SSL certificates issued and renewed automatically, and one admin panel over the lot. If you are working out what the combined load needs, the Magento server calculator sizes a server from your total catalogue and traffic figures, and our Magento 2 hosting UK plans cover the routing setup, the certificates and the go-live. For the broader picture of what we host and how, see our Magento hosting overview, or talk the plan through with an engineer first.