Cloud & self-hosted

What you get

The same container images and manifests running wherever you need them: a single VPS to start, a Kubernetes cluster when the load justifies it.

How it works

One build, several targets. Configuration is environment, not code. Object storage speaks the S3 API whether it is MinIO on your hardware or a managed bucket.

What we measure

Cost per environment, egress after edge caching, and the time it takes to bring a fresh environment up from an empty machine.

Choosing where to run

Three things decide this, and none of them is which platform is fashionable.

Where the data has to live. Some contracts and some regulators name a country. That rules out a managed region elsewhere no matter what it costs, and it is the one constraint that is not negotiable later.

What the bill looks like at your actual load. Managed services are excellent value while usage is small and unpredictable, and they stop being excellent value at steady, heavy load — particularly egress, which is where a cloud bill usually surprises people. A content-heavy product serving large files is the clearest case for owning the hardware.

Who is on call. This is the one teams underestimate. Running your own cluster means patching hosts, rotating certificates, watching disks and answering the pager. If nobody is funded to do that, managed is cheaper than self-hosted even when the invoice says otherwise.

What self-hosting actually costs

The server is the small number. The real cost is the work around it: operating system updates, certificate renewal, backup verification, monitoring that someone reads, and a plan for the day the disk fills at two in the morning.

We are direct about this because the failure mode is predictable. A cluster set up well and then left alone for a year is not a cost saving; it is an unpatched machine with your customers' data on it.

Where self-hosting does make sense, we make the machine reproducible. The build that produced it is in the repository, so rebuilding it on new hardware is running a pipeline rather than remembering what was done.

Moving between them

The reason to keep both options open is negotiating room, and it is only real if you never depend on anything you cannot replace.

In practice that means the application talks to interfaces rather than vendors: the S3 API rather than one provider's SDK, Postgres rather than a proprietary dialect, OCI images rather than a platform's own build format. Configuration is environment, not code, so the same artefact runs in both places.

That discipline costs a little upfront and it is what makes a move a project of weeks rather than a rewrite.