Skip to main content

Our four deployment flavors

Our four deployment flavors

Henry Ford famously wrote that Model T customers could pick any color car as long as it was black.

As a self-described “open network cloud” we take choice quite seriously, but too much choice is often a recipe for confusion or dissatisfaction (or simply a clunky, no good very bad cloud experience). Balancing Henry Ford’s severe efficiency with the reality of our target “alt cloud” customers is an opportunity to lean in to what I’ve seen work in scaled digital infrastructure over the last twenty years.

We’re building Datum with four distinct deployment models in mind. Or as we like to say: four flavors of ice cream, three of which we will sell and one we don’t (because it’s free).

Public Cloud

This is the most familiar flavor, the vanilla (or in our case, the hand-crafted, organic, Madagascar vanilla) that everyone knows and generally loves. In our public cloud, Datum runs the infrastructure, picks the hardware, selects the locations, manages the network paths and chooses the core software stack (for instance Tetrate's Enterprise Gateway to power our AI Edge, Unikraft's unikernel technology for our upcoming UFOs, and Iroh-based QUIC tunnels as part of our connectivity suite).

By pre-selecting the core ingredients, we can better deliver a scalable, multi-tenant, on-demand experience that “just works.” But, of course, not everyone can survive on even the best vanilla ice cream alone.

Dedicated Cloud

As customers grow in both size and ambition, I’ve generally observed that they want to inject more opinion into their infrastructure - they want chocolate and raspberry in a cup, with a sugar cone and sprinkles on top (but definitely no nuts).

This is especially true around location and tenancy, but we anticipate folks will have opinion “up the stack” in the software stack as well.

Our Dedicated Cloud flavor is fully managed by Datum, but is designed for customers who need more control and isolation. It’s a cloud experience, but dedicated in ways that matter for compliance, performance, cost, and technology preferences.

This is for teams that need an edge cloud that works on their terms. Datum is just there to help you build and operate it, using a bunch of our purpose built open source software.

Bring Your Own Cloud (BYOC)

There are lots of reasons why customers will lean in with Datum infrastructure, but we’ve been around the block enough to know the reality of the world we live in. From public cloud commitments to sovereign or regulated infrastructure and CFO driven capex depreciation priorities, complex businesses have complex infrastructure requirements. This is exponentially more true as a result of AI.

With BYOC, Datum provides the control plane, while customers bring their own infrastructure to run the data plane and control the core bits. To take the ice cream analogy too far, this is like getting a couple of pints to take home.

Open Source

Alas, this one's not for sale. Which means you can use it but you can’t buy it. :) Just about everything that makes Datum work (from a software perspective) is open source under AGPLv3. You can run it yourself, contribute changes, build on it, study it, break it, fix it. In fact, we’re super excited to help you do that.

The AGPLv3 license is permissive, but it’s not fully permissive. The main catch? You can’t use it to create a competing service without permission and we hope this keeps users of open source committed to the community and improving things for all.

We don't currently plan to sell support contracts for OSS deployments, mainly because we believe our value is intimately tied to aggregating and operating infrastructure. We’re not planning a "community edition" with an upsell path, because we think the best way to get started is with our public cloud free tier.

While it’s possible that some people will run Datum software themselves and never pay us a dollar, we’re not counting on that to build a durable business. But if this flavor is the one you like best, it’s all yours!

Why Four Flavors?

We see hundreds (or even thousands) of new clouds being born today, and we believe it’s unlikely that they will all be shaped the same way. A startup that wants to ship an AI agent next week has different needs than a telco with sovereignty requirements in six countries. A platform team that's already running Kubernetes across three clouds doesn't need us to run more clouds for them — they need the network layer to stop being the hard part.

Three flavors to buy and one that you can’t. Pick the one that fits your flavor profile best.