One policy, multiple places to run.
The hosted coordinator would make placement decisions. A customer-side agent would request work through outbound connections and create an ephemeral job environment. GitHub would remain the workflow engine; the official runner would execute inside that environment.
Company hardware · warm build cache
Resource limits · eligible workloads only
Overflow capacity · approved budget
Choose workers by eligibility, not availability alone.
The initial focus is company-owned, always-on Linux servers. Personal workstations are an optional later tier, never an automatic destination just because their owner opened a pull request.
- Authorize by organization, repository, workflow, ref, and job trust level.
- Reserve CPU, RAM, disk, and network headroom. Stop accepting new work when the host is busy.
- Match operating system, architecture, virtualization support, and toolchain requirements.
- Prefer the triggering developer’s approved machine only when policy and capacity permit it.
- Keep deployment and signing credentials off personal machines.
Scheduling should minimize expected completion cost while respecting a time-to-result objective. Waiting indefinitely for “free” compute is not a saving.
Disposable jobs. Deliberately persistent caches.
Dependency stores, compiler caches, and BuildKit state can survive between jobs. Workspaces and credentials should not. The design separates these lifecycles so a clean job does not require a completely cold build.
- Namespace caches by organization, repository, environment, and trust policy.
- Allow trusted jobs to publish cache state; give low-trust jobs disposable writes.
- Use content-addressed inputs where the build tool supports them.
- Compare transfer time with rebuild time before moving a large cache between sites.
Cloud overflow needs a budget and a deadline.
A queued job can cause a matching cloud runner to be provisioned when eligible local capacity is insufficient. A job already executing on a failed machine generally has to restart; it cannot simply continue from the same instruction on another host.
Retries need leases and duplicate-execution protection. Deployment, publication, and other side-effecting jobs must have explicit retry policies. Cache failure should be distinguishable from worker failure, with a controlled cold-build path when appropriate.
What is available—and what comes next.
| Layer | Status |
|---|---|
| Research, cost calculator, comparison register | Available on this site |
| Client login and account applications | Connected to Tbench identity; approval required |
| Managed Linux worker execution | Planned; not self-service |
| Persistent managed caches and cloud overflow | Planned; validation required |
| Harbor evaluation adapter | Proposed extension |
| Windows, macOS, GPU, personal workstations | Further compatibility and security work required |