The Case for a Micro Private Cloud Instead of Renting Everything

Every one of the businesses in our portfolio — the consulting practice, a specialty foods brand, a hospitality operator, a handful of client sites — needs somewhere to run. Web hosting, data storage, and increasingly AI workloads that need to run continuously rather than on demand. The default answer to “where does this run” is a major cloud provider, billed by usage. We built our own micro private cloud instead, and the reasoning behind that is more specific than “cloud is expensive.”

What renting actually costs at small scale

Major cloud providers are excellent at what they’re built for: workloads that spike unpredictably, teams that need to provision and deprovision constantly, and businesses that genuinely don’t know what their compute needs will look like in a year. The pricing model — pay for what you use, scale instantly — is built around that uncertainty, and the premium you pay for that flexibility is worth it when the uncertainty is real.

Our workloads are not that shape. A handful of static and low-traffic sites, a CRM system with predictable load, and AI workloads that run continuously rather than in bursts, have a usage pattern that’s known in advance and stable month to month. Paying a usage-based premium for flexibility we don’t need is paying for a risk we don’t have. At that point, the economics invert: the cost of owning modest hardware outright, amortised over a few years, becomes cheaper than the recurring bill for renting equivalent capacity, and the cost doesn’t scale up just because a workload runs for more hours in a month.

What we built

The setup is a small number of physical hosts running Proxmox for virtualization, with each site or workload getting its own isolated environment: a dedicated virtual machine, its own network segment, and a defined storage allocation. Each tenant carries its own metadata — hostname, environment, role, monitoring status — so the operational picture of “what is running where, and how is it doing” is consistent across every site on the platform, whether that site is a client’s static Hugo build or an internal service.

Dedicated data storage per tenant. Each site or workload gets storage that’s provisioned and isolated to it, rather than a shared pool with logical separation enforced only at the application layer. This matters most for client data: a client’s information doesn’t sit in the same storage volume as another client’s by convenience, it sits in a separately provisioned allocation by design.

Self-hosted VPC-equivalent network permissions. Network segmentation that would come from a cloud provider’s VPC and security group configuration is built the same way on our own hardware: each environment is on its own network segment, with access rules defined explicitly rather than left to default-open configurations. The pattern is the same one a cloud provider sells as a managed feature. Building it ourselves means we understand every rule in it, because we wrote every rule in it.

Custom hosts for AI and steady workloads. Rather than routing every AI-driven feature — including the real-time CRM insight layer we built for one of our brands — through a per-call managed API, workloads that run continuously sit on dedicated compute we control. This is not a rejection of managed AI services; it’s a workload-by-workload decision. Spiky or experimental AI work still goes to managed platforms, where paying per call is the right model. Steady, continuous inference workloads run on hardware we already own, where the marginal cost of another hour of compute is close to zero.

Web hosting for the whole portfolio on the same platform. Every site we maintain, including this one, runs on the same infrastructure, with the same monitoring and the same tenant isolation pattern. That consistency is itself a benefit independent of cost: one set of operational practices, one place to look when something needs attention, rather than a different hosting relationship and support process per site.

Where the trade-off doesn’t hold

This approach is wrong for a business whose workloads are genuinely unpredictable, or whose scale is likely to change dramatically and quickly. Owning hardware is a bet on knowing your own usage pattern. If that pattern is going to shift by an order of magnitude in either direction, renting remains the better answer, because the flexibility you’re paying for is exactly the thing you need.

It’s also a bet that requires someone who can actually run the hardware: patch it, monitor it, replace it when it fails, and configure the network and access controls correctly. That capability has a cost too, even if it doesn’t show up as a monthly invoice. For a business without in-house systems engineering capability, the “cheaper” self-hosted option can end up being the more expensive one once the hidden labour cost is accounted for.

Why it made sense here

For a small portfolio of businesses with known, steady workloads and in-house engineering capability already available, the calculation came out clearly in favour of owning the platform. The monthly cost is lower, the data control is tighter, and the operational consistency across every site we run is higher than it would be spread across several vendor relationships.

That’s not a universal argument for self-hosting. It’s an argument for doing the same cost-and-capability calculation before defaulting to the cloud provider’s meter, rather than assuming that renting is automatically the safer or cheaper choice just because it requires less upfront commitment.