sovereignty

It runs in your account. All of it.

Not a hosted control plane with an agent phoning home — the build plane, the workspaces, the registry reads, and the proxy all run on your own cluster, in your own AWS account, reading the Prometheus and ECR you already have. Keyless by default: the pod's IRSA role, not a static credential in a secret store.

The whole platform launches into your own AWS accountKeyless — reads via the pod's IRSA role, no static credentialReads the Prometheus and ECR you already operateOne contract over GitHub and self-hosted GitLabOne wildcard for the workspace fleet — no per-workspace Ingress
the constraint

Some estates can't rent their build plane.

Data residency, procurement, an existing account structure, or simply not wanting a second copy of the source.

The usual answer is a hosted control plane with an agent inside your network — which moves the boundary rather than respecting it. Metadata still leaves, the vendor still holds the state, and the interesting question becomes what exactly is in the telemetry.

The alternative is to make self-hosting the normal deployment rather than the enterprise exception. The platform is a set of Kubernetes resources and it runs where your cluster runs, reading the systems you already operate — your ECR, your Prometheus, your forge — through the pod's own IAM role.

your account
where everything runs
cluster, RBE, workspaces, proxy
IRSA
how it authenticates
no static credential to store
yours already
the systems it reads
ECR, Prometheus, your forge
one wildcard
the whole workspace fleet
no per-workspace Ingress
what self-hosted means here

Specifically, and without hedging.

Worth being precise, because the phrase is used loosely.

What runs in your account

  • Remote build execution: your Buildbarn cluster, your workers, your cache — the build plane is not shared with anyone.
  • Workspaces: DevWorkspace CRs and their persistent volumes on your cluster, reached through your own wildcard domain and session.
  • Registry reads: your ECR, read through the pod's IRSA role. There is no static registry credential anywhere in the deployment.
  • Metrics: read from the Prometheus your remote execution already exposes. Nothing is shipped out for a vendor dashboard, and with no Prometheus the panels are empty rather than fabricated.
  • Your forge: one contract covers GitHub and self-hosted GitLab, so keeping source in-house doesn't cost a second integration.
the honest boundary

Where the network edge actually is.

Two capabilities reach outside by design. Naming them is more useful than a blanket claim.

The chat plane runs its model turn on Amazon Bedrock, through your account and the pod's IRSA role rather than a static provider key — but it is a call to a managed model service, and it leaves your VPC. The grounding tool queries Wikidata, which is a public knowledge base, read-only and cached by query hash.

Everything else — build execution, workspaces, registry reads, metrics, the proxy — stays inside. If your constraint is strict egress control, those two are the surfaces to write policy about, and both are optional plugins rather than load-bearing platform components. We would rather name them than claim an air gap the deployment doesn't have.

vs a hosted control plane

Your account, your cluster, your forge.

The alternative runs in a vendor's cloud and reaches into yours.

fastverk
a hosted control plane
Where the build plane runs
Your cluster, your account
The vendor's
Registry access
Keyless via IRSA
A stored credential
Metrics
Read from your Prometheus in place
Shipped to the vendor
Self-hosted forge
First-class, same contract
Often an upgrade tier
Workspace networking
Your wildcard, one Ingress
Vendor-managed URLs
If you stop paying
The resources are already yours
An export process

Keyless by default: the pod's own IRSA role reads your ECR. There is no static registry credential in the deployment to leak or rotate.

plugin-registry · keyless reads
what this rests on

Backed by shipping plugins.

Each claim on this page is anchored to a plugin that provides it. The site build resolves these cross-references against the live feature catalog and fails if one of them doesn't exist — so this list can't quietly outlive what the platform ships.

related

Adjacent problems.

Prove it's safe to merge.

Hosted, or launched into your own AWS account. Start free — no card required.