Core concepts

A handful of ideas explain almost everything about how Longbridge Control Plane works and what you pay for.

The span and the piers

Think of a bridge. The control plane is the span — the engineered part that has to stay up. Your nodes are the piers — they hold the real load, and they’re yours.

Longbridge runs the span: API server, scheduler, controller manager, the datastore, certificates, and version upgrades. You provide the piers: any machines you like, anywhere, joined over an outbound-only tunnel so they work behind NAT without a public IP.

Tiers

A control plane comes in tiers — small, medium, large — and each tier is exactly double the one before it (control-plane CPU, memory, and datastore capacity). Pick a tier the way you’d pick an instance type. If you outgrow one, move up; we prompt you before you hit a wall, never bill you by surprise.

Node count is guidance, not a hard cap. A small is comfortable for around five nodes; you’re free to run more, bounded by the control plane’s resources rather than a license check. See Tiers & pricing for the envelopes.

Replicas and redundancy

A cluster runs one control-plane replica by default. Add replicas — at the same per-replica price — and the control plane scales out and can shrug off a lost replica or a lost management node.

We call that control-plane redundancy. We deliberately don’t call it “high availability” until your datastore is redundant too; the same clusters graduate to HA later with no price change. We don’t use the word until it’s true. More in Scaling & redundancy.

Regions

Each control plane lives in a region (for example eu-hel, Helsinki). Your nodes can be anywhere — the region is where the managed control plane runs, not where your compute has to be. EU regions keep the control plane and its state in EU jurisdiction.

Networking

Your nodes connect one of two ways, chosen when you create the cluster:

• Direct — nodes reach each other over their own network. Fine when they’re all in one cloud or all have public addresses.
• Mesh — nodes form a private, encrypted network and can join from behind NAT, so a homelab machine works with no port-forwarding. Traffic that can’t connect directly is relayed for you.

A mesh cluster runs on a network. By default that’s a dedicated network named after the cluster — its own, created and torn down with it. Or you can name an existing network at create, so several clusters run on one network and reach each other directly. Everything already on a shared network can reach the cluster’s nodes, so joining one asks for your consent.

Each mesh cluster gets its own pod and service ranges, carved to be unique across the region so two clusters on one network never overlap. We suggest a free pair; you can set your own at create. They’re fixed for the life of the cluster.

Running on a network is one relationship; attaching to one is the other. Any cluster — direct or mesh — can be attached to a network through a managed connector, which makes its pods and services reachable there without a public load balancer. You can attach to another network, or to a Tailscale or Headscale tailnet you operate yourself. “Runs on” is the underlay your nodes live on; “attached to” is a bridge to somewhere else. Those are the only two words for it.

The datastore

Cluster state lives in a managed datastore that we run, back up, and (for the redundancy tier) replicate. You never operate etcd, take snapshots by hand, or get paged at 3 a.m. for a full disk — that’s the part we’re here to carry.

Where to next

• Join a node — attach machines across homelab, Hetzner, and AWS.
• Reach a cluster over the mesh — attach a cluster to a network and reach its pods by name.
• Tiers & pricing — the numbers behind tiers and replicas.