Forge Adapter Matrix

Snapshot date: 2026-05-01

This document describes the adapter surface for each supported forge: what registration protocol it uses, how cache integrates, how much CI parity exists, and what maturity level the adapter has reached.

Summary

GitHub Adapter (Primary)

Registration uses a GitHub App with org-wide scope. The ARC controller manages scale sets that register runners on demand.

Scale sets on honey:

• tinyland-nix — standard Nix workloads
• tinyland-docker — container-based workloads
• tinyland-dind — Docker-in-Docker for image builds
• tinyland-nix-heavy — elevated memory/CPU for heavy Rust and Nix builds

Scope model: org-wide by default, per-repo targeting available via workflow runs-on labels.

Cache: Attic binary cache for Nix store paths, Bazel remote cache for Bazel build artifacts, and runner-injected environment variables for the cache-first job contract.

Status: production. This is the only forge adapter with queue-driven scale-to-zero as a primary product path on honey.

GitLab Adapter (Compatibility)

Registration uses the gitlab-runner Helm chart with a registration token scoped to instance, group, or project level.

Scope model: instance, group, or project. Token scope determines which jobs the runner picks up.

Cache: the Tofu module now wires the same Attic NIX_CONFIG trust path and Bazel cache environment that ARC jobs receive. This is configuration parity, not an end-to-end live proof of the GitLab adapter.

CI parity: compatibility. The OpenTofu module validates, supports pinned images, bounded job/service/helper resource envelopes, HPA manager scaling, and namespace quota/LimitRange policy. It does not provide ARC’s queue-driven scale-to-zero semantics.

Caveat: do not assume GitLab runner capacity or cache-hit behavior is equivalent to the GitHub ARC proof surface until a live GitLab proof exercises the same cache-first contract end to end.

Forgejo/Codeberg Adapter (Proof Path)

Registration uses act_runner with an instance token. Scope can be set to account, org, or repo level.

Cache: no reusable Attic or Bazel cache integration exists for this adapter in the repo today.

CI parity: one honest disposable proof path is now exercised. On 2026-04-20 a repo-scoped runner on honey executed a push-triggered workflow against an in-cluster disposable Forgejo instance. Forgejo Actions uses GitHub Actions syntax for workflow files, but the runner registration protocol is different from both GitHub ARC and GitLab Runner. See GloriousFlywheel Forgejo Honey Proof 2026-04-20.

Status: proof-of-concept exercised on honey. This is not a production adapter: no shared fleet, no durable state, no tested cache path, and no operator automation surface yet.

Woodpecker/Codeberg belongs in the same future-adapter bucket until there is a real module, registration story, scale contract, and cache attachment proof.

What Is Shared Across Forges

These components are forge-agnostic and reused by every adapter:

• Attic: binary cache backend, store signing, tenant isolation
• Runner images: docker, nix, nix-heavy base images built by Nix
• Cluster substrate: Kubernetes, OpenTofu modules, Tailscale overlay
• Operator tooling: Just recipes, dashboard, MCP server, health checks
• Policy model: pool placement, resource limits, scheduling constraints

What Is Forge-Specific

Each forge adapter owns these concerns independently:

• Registration protocol and tokens: GitHub App, GitLab registration token, Forgejo instance token
• Scope model: how runner visibility maps to org/repo/project hierarchy
• Event routing: how CI events reach the runner controller
• CI syntax: workflow file format and location (.github/, .gitlab-ci.yml, .forgejo/)

Related

• Enrollment Model — how runner enrollment works across forge scope, operator tenant, execution pool, and cache/state plane
• Platform Layers — where forge adapters sit in the 4-layer architecture