You operate several brands, regional shops, or business units that each need their own storefront. Maybe they share the same product catalog but have different designs. Maybe they are completely independent brands under one company umbrella. This page explains the two main architectural patterns in Laioutr and helps you decide which one fits your situation.
In this approach, you run one Laioutr project that serves multiple domains. Each domain maps to a different market, and the rule engine differentiates content, layout, and behaviour per market or domain.
This is the right choice when your storefronts share the same brand identity, the same set of apps, and largely the same page structure — but need regional variations in content, language, currency, or product availability.
Your project has multiple markets configured in Cockpit, each with its own domain:
| Market | Domain | Currency |
|---|---|---|
| Switzerland | www.shop.ch | CHF |
| Germany | www.shop.de | EUR |
| Austria | www.shop.at | EUR |
All three domains are served by the same Nuxt application. The rule engine lets you vary sections, banners, and navigation per market. For example, you can show a "Free shipping in Switzerland" banner only on www.shop.ch, or feature different product highlights per region.
In this approach, you create separate projects within your Laioutr organization. Each project is an independent Nuxt application with its own laioutrrc.json, its own Studio workspace, and its own deployment. The shared code lives in your apps — Nuxt modules installed as npm packages in both projects.
This is the right choice when your storefronts have fundamentally different designs, different page structures, or are managed by separate teams — but share underlying business logic or integrations.
You build your integration logic (commerce connector, checkout flow, tracking) as a reusable app (Nuxt module). Both projects install it:
// Project A: package.json
{
"dependencies": {
"@your-org/commerce-app": "^2.0.0",
"@your-org/brand-a-ui": "^1.0.0"
}
}
// Project B: package.json
{
"dependencies": {
"@your-org/commerce-app": "^2.0.0",
"@your-org/brand-b-ui": "^1.0.0"
}
}
Each project has its own UI app with brand-specific components, sections, and styling. The commerce app handles product data, cart, and checkout identically across both. Each project is managed independently in Cockpit and Studio.
For more on building reusable apps, see App Development.
| Criterion | Single project (Option A) | Multiple projects (Option B) |
|---|---|---|
| Brand identity | Same brand, regional variants | Different brands or sub-brands |
| Page structure | Shared across storefronts | Different per storefront |
| Design system | One design, minor variations | Distinct designs per brand |
| Team structure | One team manages everything | Separate teams per storefront |
| Deployment | Single build and deploy | Independent deployments |
| Content management | One Studio workspace with rules | Separate Studio workspaces |
| Code sharing | Implicit (same project) | Explicit (shared npm modules) |
| Complexity | Lower — one project to maintain | Higher — multiple projects, but cleaner separation |
In Option A, domain routing is handled by the multi-market system. Each market maps to one or more domains, and the platform resolves the correct market at request time based on the hostname.
In Option B, each project has its own domain configuration. Since projects are independent deployments, domain routing is handled at the hosting level — each project's domain points to its own deployment. There is no cross-project routing within Laioutr itself.
Regardless of which option you choose, the app architecture encourages code reuse. A Laioutr app is a standard Nuxt module distributed as an npm package. This means you can:
This pattern mirrors how the platform's own apps work. The Shopify app, for example, handles data and integration logic while the UI app handles presentation. You can follow the same separation for your own multi-brand setup.
For more on Laioutr's overall architecture and how apps fit together, see Architecture.