Photo: free stock photography (Unsplash licence) — see imprint
The honest minimum
Two application servers behind a load balancer, a managed MySQL, a managed Redis, and object storage for media. That is it. It handles the traffic of most mid-sized B2B shops with room to spare and costs a fraction of a 'cloud-native' redesign.
Where the cloud actually helps B2B
B2B traffic is spiky in a predictable way: Monday morning, month-end, catalogue launch. Being able to double capacity for four hours and pay for four hours is a real advantage — but only if you set it up before the spike, not during it.
Where it burns money
Kubernetes for one shop. A CDN in front of a page that is not cacheable anyway. Multi-region for a company that sells in one country. Every one of these adds a system to operate; none of them adds an order.
Boring beats clever, in production
The best hosting setup is the one your team can debug at 7 a.m. on a Monday when orders are stuck. Simplicity is an availability feature — write the runbook, and prefer the architecture that needs the shortest one.
- Two app servers, managed DB, Redis, object storage.
- Autoscale for known spikes, not for prestige.
- Prefer the architecture with the shortest runbook.
Frequently asked questions
We will not quote you a number, because the honest answer is that it depends entirely on what you build. A minimal setup and a good managed host land in a similar region; the bill explodes when the architecture does — Kubernetes, multi-region, a service mesh nobody asked for. Compare the total including the hours someone spends operating it, not a server list price.
Two application servers behind a load balancer, a managed MySQL, a managed Redis, and object storage for media. That is the whole list. It carries the traffic of most mid-sized B2B shops with room left over, and it costs a fraction of a cloud-native redesign. Add pieces when a measurement demands them, not when a slide deck does.
Almost certainly not. Kubernetes for a single shop adds an entire system to operate and does not add one order. It makes sense when you genuinely run many services across many teams. For one Shopware shop, two app servers behind a load balancer solve the same problem, and your team can still debug them at 7 a.m. on a Monday when orders are stuck.
Then do not move. A migration you cannot justify with a measurement spends money and buys risk. The real reasons are concrete: traffic that spikes in a planned way — Monday morning, month-end, catalogue launch — where paying for four hours of double capacity is genuinely useful, or a host that cannot give you what you need. Prestige is not a reason.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer