Self-hosted PaaS: the four things you are taking on

Self-hosting the platform layer is an appealing trade. Instead of paying per container and per build minute, you run the thing on hardware you already have and pay for the hardware.

The trade is real, and so is the other side of it. Four responsibilities move to you, and they are worth naming before rather than after.

1. Availability of the platform itself

Whatever runs the control plane is now yours to keep running. If it stores state, that state needs backing up and the restore needs testing, because a control plane that cannot be restored is one disk failure away from a rebuild.

The mitigating question to ask of any such system: what happens to my running applications while the control plane is down? If the answer is "they keep serving and you lose the dashboard", the risk is an inconvenience. If the answer is "traffic stops", you have put a new single point of failure in front of production.

2. Upgrades, forever

Someone has to apply platform upgrades, on a cadence set by security advisories rather than by your roadmap. Skipping them for a year turns a routine upgrade into a migration, which is how self-hosted installations end up pinned to a version nobody wants to move off.

3. The Kubernetes underneath

A platform on top of Kubernetes does not absolve you of the Kubernetes. Node upgrades, certificate rotation for the cluster's own components, storage drivers, and the CNI remain yours. Most of the time this is quiet. It is not zero, and it needs an owner with a name.

4. The problems that are now unshared

On a managed platform, an infrastructure bug is someone else's incident and often fixed before you notice. Self-hosted, you are the first to see it and there is no status page to check. This is the cost that is hardest to put in a spreadsheet and the one most often felt.

Two shapes, and which we are

These responsibilities do not all arrive together, because "self-hosted" covers two different arrangements.

Fully self-hosted means you run the control plane too. Maximum control, and all four responsibilities are yours.

Your infrastructure, our control plane means the workloads run on your hardware while the coordinating layer is operated by the vendor. Responsibilities one and two stay with the vendor. Three remains yours, because it is your cluster. Four is shared.

Anyport is the second shape by default. You bring the clusters and we run the control plane, which is why the pricing is for the dashboard and the gateway rather than for your compute. The failure mode is the good one: everything Anyport creates is a standard Kubernetes object in your cluster, so if our control plane is unavailable your applications keep serving and what you lose is the console.

We are an independent vendor asking for privileges inside your cluster, so the security page sets out what the agent holds, what crosses the boundary, and where we stand on certification today.