Control planes in your own cloud

Early access. Node-based control planes are rolling out per organization. If the hosting-model choice does not appear when you create a cluster, ask us to enable it for yours.

A node-based control plane runs on real virtual machines in your cloud account: the API server, the scheduler, the controller manager, and stacked etcd, on machines you own and pay your provider for. Longbridge provisions them, upgrades them, replaces failed ones, and takes scheduled snapshots — all from our own infrastructure. Nothing of ours runs in your account.

The alternative is a hosted control plane, which runs on our machines and is sized by tier. Most clusters should be hosted; three things bring people here:

• The cluster’s state must live in your account. Data residency, a compliance position, or a procurement stance that will not accept “our Secrets sit in the vendor’s database.”
• The tiers are too small. We deliberately do not run very large hosted control planes.
• You want a heterogeneous cluster — mixed compute from several places under one control plane, with no per-node or per-vCPU tax.

What changes, in one table

	Hosted	In your own cloud
Where the control plane runs	Longbridge machines	Your cloud account
Who holds the cluster’s state, including Secrets	We do	You do
Sizing	A tier	The machine type you name
Datastore setting	Shared or dedicated	None — etcd runs on your machines
Load balancers for your Services	Our managed IPs	Your cloud’s own controller
What we can see	The whole control plane	Only what your cluster’s API tells us
Price	Per replica-hour	Per cluster-hour, flat
On exit	The cluster stops	You keep a running cluster

What you need first

A cloud credential stored on your organization — the same object a managed node pool uses. Hetzner Cloud is supported today; AWS is next.

A dedicated cloud project is recommended and not required. The reason is exit rather than security: deleting the project is a complete, verifiable teardown, where a shared project leaves us reciting a list of resources we promise to have removed.

Creating one

In the Console, create a cluster and choose On machines in your own cloud. You then name:

• the cloud credential whose account the machines are created in;
• the location and machine type, in your cloud’s own vocabulary;
• how many control-plane machines — 1, 3, or 5;
• optionally, your own API hostname;
• the snapshot policy.

There is no tier and no datastore setting, because neither has a meaning here: you named the machine, and the cluster’s state lives in etcd on it.

Machine count is 1, 3, or 5

etcd runs on the control-plane machines and needs a quorum, so the count is odd. Three is the shape to pick for anything you depend on.

One machine is offered and unsupported. It upgrades like any other cluster, but a failed machine is not replaced automatically and carries no incident response: there is no surviving etcd member to recover from, so the cluster’s API is down until it is rebuilt. Use one machine for development and throwaway clusters.

Minimum machine sizes

The published minimum per cloud, for the control-plane machines:

Cloud	Minimum
Hetzner Cloud	4 vCPU, 8 GiB

A smaller machine is permitted. You are buying the machines, so it is your call — we warn you at create time and build the cluster anyway. A control plane under the minimum may be unstable under load.

The API endpoint

Your cluster’s API is reachable over the public internet, through a load balancer in your own account. That is required on every cloud we support, at every machine count.

By default the endpoint answers on a Longbridge hostname, which works immediately with no DNS setup. You can supply your own hostname instead, and both go into the API certificate when the cluster is created — so moving to yours later is a DNS change rather than a cluster rebuild, and your kubeconfigs need not depend on our domain.

Source-address allowlists are available on request. They are off by default, and they are not available on Hetzner, whose load balancers have no access lists.

Snapshots and recovery

Longbridge takes scheduled snapshots of the control plane’s disk into your own cloud account. The state never leaves your account, which is the whole premise — an etcd snapshot is the entire cluster, every Secret included.

You set the schedule and how many are kept, and you can switch snapshots off entirely, because they cost money on your bill and that trade is yours.

What we can promise therefore depends on what you chose. Restoring is a support request plus documentation, and it depends on access we may not have. With snapshots off, there is nothing to restore from.

Two things worth knowing:

• A snapshot is taken while etcd is running, so it is crash-consistent — the same category as pulling the power on a database server. We have opened one and brought etcd up on it; that is evidence, not a guarantee.
• Snapshots outlive the cluster. Deleting a cluster leaves them in place: they are yours, they are the only restore points for a cluster that no longer exists, and deleting them would be the one step of a teardown with no undo. They keep billing in your account until you remove them.

For a portable copy you control end to end, run etcdctl snapshot save against your own cluster on your own schedule. That is also the exit path if you ever want the state somewhere else.

What Longbridge can see

We pull health from our side, over your cluster’s own Kubernetes API, and we run no agent in your account. That means we see less of a node-based cluster than a hosted one, and it is worth knowing which parts:

• We see whether the API answers, how many nodes are ready, and whether the etcd and API-server pods on each control-plane machine are ready.
• We do not see in-cluster metrics, logs, or your workloads.
• When your cluster is unreachable we report exactly that, rather than the last reading we happened to have.

The cluster’s page shows the last check and when we last reached it. A newly created cluster spends five to eight minutes unreachable before its first machine serves; that is normal, and the page says so rather than calling it a fault.

Faults that are yours to clear

Cloud-side problems reach you as a message that says whose side it is on and what clears it — an expired or revoked credential, an exhausted quota in your project, a machine type your provider cannot supply right now. Those appear on the cluster’s page and as a notification.

While a fault blocks us, our obligation suspends rather than fails: we notify you and stop, rather than retrying against a wall. Fixing the cause resumes the cluster by itself — there is nothing to un-pause.

What this costs

Longbridge charges €0.07 per cluster-hour — that is the rate on the invoice, and you are billed for the hours the cluster exists:

€0.07 / cluster-hour   ≈ €50.40 over a 30-day month (720 hours)

The rate does not move with machine count, machine size, node count, or vCPU. Running three control-plane machines instead of one costs you nothing extra with us; you already paid your provider for them. See Tiers & pricing.

Your own cloud bills you separately for the control-plane machines, their volumes, the load balancer in front of the API, and any snapshots. We never see or mark up that bill.

Changing the hosting model

The hosting model is fixed when the cluster is created. There is no migration between hosted and node-based, and the reason is not policy: the two store the cluster’s state in different places — a shared database on our side, etcd on your disks — and no tool moves it across.

Changing your mind means creating a new cluster and moving your workloads to it. The recipe:

1. Create the new cluster with the hosting model you want. Nothing about the old one changes, so you can take your time.
2. Point your delivery at it. If your workloads are declarative — Helm charts, Kustomize, or Longbridge GitOps — this is a re-point rather than a rebuild.
3. Move state that is not in your manifests. Persistent volumes, Secrets you did not commit, and anything a controller created for you. This is the step that takes real time; nothing about either control plane makes it harder or easier.
4. Cut over traffic, then verify from outside the cluster.
5. Delete the old cluster. Any snapshots it took stay in your account.

Everything else survives the move unchanged: your organization, your members and grants, your billing, and the audit trail.

Support, plainly

• No uptime SLA. We own neither the machines, the quota, nor the credential. What we commit to is a published response target, by email — response, not resolution.
• We hold standing administrative access to a node-based cluster: Cluster API cannot manage a control plane without it, and the cluster’s certificate authorities live on our side. Any wording that suggested otherwise would be marketing.
• You can revoke our access at any time. The cost is stated up front: upgrades, automated repair, and snapshots all stop, and a restore may become impossible. Nothing is destroyed, and restoring access resumes the cluster.
• If your cluster’s API is down and our credential is revoked, we cannot help. That is inherent to running in someone else’s account.

Leaving

On exit you keep a running Kubernetes cluster. It is yours: the machines, the state, the load balancer, the snapshots.

One thing to plan for. kubeadm issues one-year certificates and Longbridge is what rotates them, so an abandoned cluster runs and then stops within about a year. When you leave we hand over a pack covering certificate rotation, what we held, and what to do next.