Marketplace Hosting: What to check before you choose
Marketplace Hosting: What to check before you choose
- Arnaud
- 7-minute read
If you’re looking for where to host a marketplace, the short answer fits in one sentence: a multi-vendor platform is not sized like an e-commerce site, because almost all of its traffic is authenticated and has to be computed on every request. Everything else follows from that, including the budget.
This article covers what that means in practice, the three hosting models available and their limits, and how we handle the question at Origami Marketplace.
Contents:
- Why marketplace hosting is not e-commerce hosting
- The most common marketplace sizing mistakes
- Three marketplace hosting models and their trade-offs
- Why data residency comes up in every B2B project
- How the architecture model changes your hosting costs
- How Origami Marketplace hosts its clients’ marketplaces
- Marketplace hosting FAQ
Why marketplace hosting is not e-commerce hosting
- On a classic e-commerce site, most visitors are anonymous. Product pages are the same for everyone, so they can be cached and served by a CDN, and the application server only sees a fraction of real traffic. Most e-commerce hosting offers are designed for this model.
- A marketplace can work the other way round, especially in B2B. Each buyer logs in and gets their own negotiated prices, approved catalogue and approval flows. Every page has to be computed for that buyer, which makes caching largely ineffective. Meanwhile, sellers work in their own back offices: updating stock, adding SKUs, processing orders. Where an online shop runs one admin interface, a marketplace runs as many as it has active sellers, all writing to the database at the same time.
« On top of that come background jobs, invisible in traffic statistics but very visible in resource consumption. A supplier pushing 60,000 SKUs at the end of the day triggers data normalisation, search reindexing and sometimes a price recalculation across its whole range. None of this shows up in monthly visits, but it ties up the database while buyers are placing orders. »
Vincent Pichon, co-founder and CTO of Origami Marketplace
The most common marketplace sizing mistakes
Thinking in monthly visitors
The figure that really sizes a marketplace is the number of concurrent authenticated sessions at peak time, combined with catalogue volume. Two platforms with the same monthly traffic can need very different infrastructure, depending on whether their users browse or work.
Treating the database as a secondary component
A marketplace whose database is down is not degraded, it is stopped. No catalogue, no basket, no orders. So the right question for a hosting provider is not about server power but about failure behaviour: is there a replica? Is failover automatic? How fast, and with how much acceptable data loss? Backups call for the same precision. A backup that has never been test-restored is an intention, not a guarantee.
Discovering isolation during the security audit
Isolation works at two levels, and both get examined sooner or later. Between sellers first, since each one must see only its own products, orders and margins. Then between client organisations, as soon as infrastructure is shared. It is almost always where a project stalls at security review. It has to be prepared upfront with a documented architecture, not with an improvised answer to a 200-line questionnaire.
Skipping the staging environment
A marketplace changes constantly: a new connector, a new commission rule, a new approval workflow. Without a pre-production environment comparable to production, every release becomes a bet on a system that carries transactions.
Monitoring the servers but not the business
A server can show every indicator in green while payments are failing for one seller, or while a catalogue import has been running for six hours without finishing. Useful monitoring also tracks functional signals: checkout error rate, duration of asynchronous jobs, age of the last successful import per supplier.
Need a marketplace specification template?
Download our ready-to-use template to scope your multi-vendor platform project quickly, compare the solutions on the market and de-risk your project.
Complete template • Used on B2B, B2C and C2C projects • Ready to adapt
Three marketplace hosting models and their trade-offs
The “plugin” marketplace on managed hosting
This is the approach of multi-vendor extensions for WordPress and WooCommerce. You start from an e-commerce site, add a seller layer and host it with a WordPress specialist.
The benefits are real: low entry cost, fast set-up, a very rich extension ecosystem and a community that documents almost every use case. To validate an idea, or to run a modest consumer marketplace, it is a defensible choice.
The limits show up with volume. The architecture is still that of a single site with multi-vendor bolted on, which weighs on queries as SKUs and sellers pile up. Every update tests the compatibility of a stack of extensions that nobody maintains together. And the only growth lever on offer is the next pricing tier. Typical B2B requirements, such as single sign-on, purchase approval workflows, ERP integration and contractual uptime commitments, quickly fall outside its scope.
Dedicated infrastructure per client
Each marketplace runs on its own environment. Isolation is clean, sizing is tailored, and reversibility is easy to explain to an IT department.
This is the model Origami Marketplace started with, on OVHcloud public cloud, with one environment per client. It works well while the number of platforms stays small, then turns into a scaling problem almost mechanically: each new contract adds a full infrastructure to deploy, then to maintain. Certificates, updates, incidents, monitoring, backups. Cost tracks the number of environments, and so does team time.
« Every new client meant one more environment to maintain. For a growing company like ours, with clients whose usage was becoming more and more business-critical, we could tell the model needed optimising. Our teams were spending more and more time on operations instead of focusing on the product. »
Vincent Pichon, co-founder and CTO of Origami Marketplace
A shared, isolated platform
The third model refuses the choice between shared and dedicated. It is the one Origami Marketplace adopted for its clients. One industrialised infrastructure, on which each client environment is logically partitioned: separate namespaces, network policies, resource quotas, distinct access. Pooling lets you consolidate workloads and absorb a peak at one client with capacity available across the platform. Partitioning preserves each client’s data governance.
This model has requirements worth stating plainly. Poorly configured, it exposes you to the noisy neighbour problem, where one environment consumes resources at the expense of the others. The fix is quotas and limits set seriously from day one.
It also requires real Kubernetes expertise, in-house or through a partner, and that is not a skill you improvise during a production incident. Finally, it only pays off once you have several environments to run. For a single platform, the added complexity does not pay for itself.
| Criterion | Plugin on managed hosting | Dedicated infrastructure per client | Shared, isolated platform |
|---|---|---|---|
| Model | E-commerce site plus seller layer | One client, one platform | One platform, N partitioned environments |
| Cost as activity grows | By pricing tier | Linear growth | Decoupled from the number of environments |
| Handling peaks | Weak | Planned environment by environment | Pooled capacity |
| Isolation | Application-level | Physical | Strict, documented logical isolation |
| Opening a new environment | New site to build | Infrastructure project | Automated deployment |
| Skills required | WordPress | Systems and cloud | Kubernetes, in-house or outsourced |
| Best for | Small consumer marketplaces | A single, highly constrained project | B2B, vertical and e-procurement marketplaces |
Why data residency comes up in every B2B project
On an enterprise project, hosting always ends up leaving the technical scope and landing in front of IT, security and sometimes procurement. The request is almost always phrased the same way: we want our data to stay in the country, or at least in the EU.
The expectation is legitimate, especially when the platform handles negotiated commercial terms, supplier data or member information. It still needs to be made precise, because the vocabulary has become very elastic. GDPR does not require data to be hosted in any particular country. It governs processing and transfers outside the European Union, and UK GDPR follows the same logic for transfers out of the UK.
A national residency requirement therefore usually comes from internal policy, a contract clause or a strategic choice. That is perfectly valid, but it is not the same as a regulatory obligation. Knowing the difference avoids paying for a sales argument rather than a guarantee. Three questions are usually enough to separate offers built on facts from offers built on vocabulary:
- In which country are the servers physically located, and is that commitment written into the contract?
- Is the isolation architecture documented in a form you can rely on in an audit?
- Who has administrative access to the infrastructure, and which legal entity do those people work for?
How the architecture model changes your hosting costs
Comparing hosting offers on the monthly fee alone gives a false picture, for two reasons.
- The first is operations time. It appears on no hosting invoice, but you pay for it in salaries: updates, certificate renewals, backup management, on-call, incident handling. On a transactional platform, this cost is not marginal.
- The second is over-provisioning. Infrastructure is sized for its peak, so you pay all year for spare capacity used a few hours a month. In a dedicated-per-client model, each environment carries its own reserve, and the sum of those reserves far exceeds the real need of the whole. A shared platform pools that reserve, which improves resource allocation and decouples the cost curve from the number of environments.
That does not make hosting free, and a dedicated environment is sometimes still the better fit: for example when a platform grows so large that it consumes the equivalent of a full infrastructure, or when a contract explicitly requires it. The decision is made during scoping, not on principle.
How Origami Marketplace hosts its clients' marketplaces
Origami Marketplace is a French solution that lets companies build and run their own marketplaces: B2B, e-procurement, service platforms, digitalised reseller networks. Our clients include national sports federations, mutual insurers and industrial groups, for whom the platform is a production tool.
So we went through the transition described above ourselves. In summer 2022, with support from the Enix team, we moved from a dedicated-per-client model to a shared Kubernetes platform.
The infrastructure now runs on OVHcloud bare metal servers, virtualised with Proxmox, hosting two Kubernetes clusters: one for development, one for production. All client environments are hosted in the production cluster, with shared resources and strict data isolation. Deploying a new environment is automated through Kubernetes operators, and databases run in high availability directly inside the cluster.
« Moving to a platform that is both shared and isolated was a real turning point. Shared, to decouple our growth from the number of environments to manage. Isolated, to keep strict governance over each client’s data. We won on both fronts: scale and security. Onboarding a new client has become a smooth process, not an infrastructure project. »
Vincent Pichon, co-founder and CTO of Origami Marketplace
The migration was done client by client, with no service interruption, and that is still how we take over an existing platform. Since then, the infrastructure has kept evolving: the virtualisation cluster was extended and modernised three years later through live operations, an immutable operating system was adopted on the Kubernetes nodes to reduce the attack surface, and monitoring and observability have been strengthened continuously.
For a client, this comes down to one simple thing: hosting is not part of their project. No servers to size, no database to replicate, no on-call rota to organise, and a documented architecture to present to their own security teams. Their developers, if they have any, work on integrations and the buying experience.
« Today we have a solid platform that evolves with us and with our clients. Enix’s support lets us stay focused on what really matters, product innovation, while knowing the infrastructure keeps pace. It’s exactly the partnership we were looking for. »
Vincent Pichon, co-founder and CTO of Origami Marketplace
The full story of this transformation is documented in the use case published by Enix (in French).
If you’re researching hosting for your future marketplace, the most useful conversation is rarely about servers. It is about your catalogue volume, your integrations, your security constraints and where you want to be in two years. Let’s talk.
Have a question about your project?
Let’s spend 15 minutes discussing your catalog volume, integrations, and security requirements.
Marketplace hosting FAQ
An e-commerce host is optimised for anonymous, cacheable traffic. A marketplace mostly generates authenticated traffic, computed on every request, with a much busier database. Generic offers hold up at launch, then degrade at exactly the moment activity takes off. Before signing, check the headroom in concurrent logged-in users and the database high-availability strategy.
With WordPress, you assemble a site, a multi-vendor extension, a host and add-on plugins yourself, and you stay responsible for keeping the whole stack consistent at every update. With a SaaS solution built for multi-vendor, the data model is natively multi-store, the infrastructure is run for you and B2B requirements are part of the product. The first option suits testing a market. The second suits a platform your business depends on.
Sharing applies to infrastructure resources (compute, memory, storage), not to data. Each client environment is partitioned within the cluster, with its own access, network policies and quotas. That is exactly what this architecture is for: share for efficiency, partition for governance.
On OVHcloud bare metal infrastructure that we virtualise ourselves, operated with our French managed services partner Enix. We provide architecture documentation and details of the isolation mechanisms to our clients’ security and compliance teams on request.
Yes, and we have done it on our own client base, step by step, with no service interruption. The scoping phase assesses the volume of data to migrate, existing integrations and the cutover plan, usually environment by environment.
There is no reference price, because the variables differ from a standard website: number of sellers, catalogue size and update frequency, concurrent authenticated sessions, connections to existing systems, availability requirements. At Origami Marketplace, hosting and operations are included in the subscription, so you don’t stack a hosting bill, internal operations time and one-off infrastructure services.
