One backend for every brand, region, and tenant
Run catalogue, pricing, currency, language, tax, shipping, and admin roles scoped per channel. One Vendure backend models every brand, region, dealer network, marketplace tenant, and B2B segment you operate, with a per-tenant deployment path when a tenant needs full isolation.
One platform per brand multiplies your platform tax
The default enterprise move for a second brand, a new region, or a marketplace tenancy is another platform. A second admin to operate. A second database to keep in sync. A second integration footprint into the ERP, the warehouse, and the identity provider. Customer data splits across instances. Catalogue drifts. Pricing logic lives in three different places. Every new market doubles the maintenance bill.
Vendure refuses that trade-off. Channels are a first-class primitive in the core, not a fork and not a plugin. One Vendure backend models every storefront, region, dealer, marketplace tenant, and B2B segment, and each channel scopes its own catalogue, pricing, currency, language, tax, shipping, and roles. You run one codebase and one canonical data model instead of a separate platform per brand.
Every lever channels expose
A new channel is a configuration step, not a parallel build. Channel awareness is wired through Vendure end to end, so core primitives like catalogue, pricing, and customers and the layers around them all inherit the same channel context.
Channel-scoped catalogue
Product availability is set per channel. Canonical products live in a shared catalogue model; each channel selects which products it sells and overrides what it needs to override. One catalogue model, many channel views.
Channel-scoped pricing
Per-channel price lists, promotions, and tax-inclusive vs exclusive behaviour. Override a price on the channel without forking the product. The pricing engine respects channel context at the lookup, the cart, and the order.
Currencies per channel
Each channel has a default currency and can support multiple currencies inside that channel. EUR for the European storefront, USD for the US one, NOK for the Nordics, all on one deployment.
Languages per channel
Channel-scoped translations for products, collections, and content. The same canonical product carries a Swedish translation in the Hemglass channel and an English one in the export channel, with channel-level fallbacks you control.
Tax and shipping per channel
Channel-scoped tax zones, tax categories, shipping methods, and fulfillment rules. Sell into a new region by configuring the channel, not by standing up another commerce stack to handle its tax engine.
Channel-scoped roles and permissions
Admin operators are scoped to one or more channels. A brand team logs in and sees only its brand. A regional manager sees only their region. A cross-channel super-admin keeps the full view. One admin app, channel-aware access.
Channel-scoped inventory and stock locations
StockLocation is a channel-aware entity. Inventory pools and fulfilment routing attach to the channel, so the same SKU can ship from a UK warehouse on the UK channel and a German warehouse on the DE channel. The routing is configuration you update once, not application code to maintain across releases.
Channel-aware plugins and integrations
The plugin system resolves channel context at runtime. Payment providers, shipping calculators, search indexes, and any custom plugin can fire with different settings on different channels. Wire Stripe on the D2C channel and a B2B invoicing provider on the wholesale channel by configuration.
Channel-aware events and webhooks
Domain events and outgoing webhooks carry the channel on the payload. Downstream systems like ERP, OMS, search, analytics, and marketing automation can route or filter by channel directly, instead of inferring it from order metadata or maintaining a separate lookup table.
How channels work in code and data
Because the channel is a core entity, queries are scoped to the active channel automatically: there is no per-query channel filter to maintain and no row leakage between brands. The items below show how the channel entity is modelled to make that scoping automatic.
Five commerce models channels make possible
The channels primitive supports five commerce models, all on one deployment.
When channels are not enough, run a tenant per deployment
Most multi-brand and multi-tenant programmes end up using both patterns, so this is not an either-or choice. Channels carry brands that share a feature set on a single deployment; a separate deployment per tenant fits tenants that need different feature sets entirely, hard data isolation, or independent spin-up and teardown. For that case, Vendure runs as one codebase with one instance and one database per tenant. Every tenant stays on the same plugin ecosystem and the same upgrade path, with complete isolation between them.
Trusted by complex B2B commerce and enterprise retail.
What engineering leads say about Vendure
Engineering leads on building commerce on Vendure.
What convinced me about Vendure is its fundamentally well-architected codebase. It's clear, intuitive, and easy to extend, making it adaptable to virtually any use case.
Our peer-to-peer sharing marketplace builds on proven e-commerce components, but only Vendure offered the flexibility to seamlessly integrate our complex business logic. Its modern tech stack and use of established frameworks enable us to work efficiently and build a maintainable long-term solution.
What teams ask about multi-channel on Vendure
Common questions from engineering teams sizing a multi-channel or multi-tenant rollout on Vendure.
