What does the self-hosted runner actually run?

A single signed binary on a host you control — VM, bare metal, or container. No daemons in your control plane, no outbound network calls except to an LLM proxy you can choose to operate locally. The runner reads the host Git platform through the same scoped credentials a CI job would use.

How is our lockfile and source code handled — does it ever leave our network?

Source and lockfiles never leave your perimeter. The runner only writes to the audit row your team owns, and the LLM egress — if you allow one — is routed through a proxy you operate so redaction and telemetry stay under your review. Air-gap mode is a documented install posture, not a hack.

What does the install look like — does it need our whole infra team?

A single binary, a config file, and a policy pack loaded from local storage. Drop it into Docker, Helm, or systemd — pick your existing ops story. We work with the first cohort on the specific install posture; you don’t have to plan a separate infra project to evaluate it.

Self-hosted runner

Bivouac, inside your network.

The same audit-logged agent runner that ships managed, deployed as a single binary on a host you control. Built for regulated repos, air-gapped environments, and data-residency requirements where SaaS isn’t on the table. Join the waitlist and we’ll work with the first cohort on the install posture that matches your perimeter.

What changes when the runner is yours

Air-gapped by design

Single binary, no outbound network calls except the LLM egress proxy you operate. Policy packs loaded from a local file.

Regulated repos, accepted

For buyers under FINMA, BaFin, APRA / CPS 234, DORA, and similar — the same audit-logged chain of patch decisions, reproduced inside your perimeter.

Data residency, owned

Tenant rows pinned to the region you choose. Backups encrypted at rest, pulled only by your team. No third-country replication.

Same evidence, same model

The minutes-not-weeks MTTR and the audit-logged chain of patch decisions ship identical to managed — the runner just lives with you.

Targets we’re shipping first

The runner reads the host platform through the same scoped credentials a CI job would use — the difference is where the policy pack and the audit log live.

GitHub Enterprise
Self-hosted runners, GitHub Apps API.
GitLab Self-Managed
CE / EE on-prem, instance-level tokens.
Bitbucket Data Center
Clustered DC, smart-mirror / DC licenses.

First-cohort waitlist

Be in the first cohort.

We’re piloting the self-hosted runner with a small group of buyers who need it today. Drop your work email and we’ll reach out within a week with the install posture (Docker / Helm) and a private channel for the first deployment.

We use this only for the self-hosted rollout. No newsletter, no third-party sharing.

Buyer questions

What changes when the runner is yours

Targets we’re shipping first

What compliance teams ask before we install

What does the self-hosted runner actually run?

How is our lockfile and source code handled — does it ever leave our network?

What does the install look like — does it need our whole infra team?