Skip to content

Roadmap

This page is about what GAG does not do yet. For what it does today, see Features — every shipped capability, with a link to the doc that explains it — and Why GAG? for the capability-by-capability comparison against Actions Runner Controller (ARC).

GitHub Actions Gateway (GAG) is 1.0, generally available, and installable from the GitHub Container Registry (GHCR). It is Apache-2.0, vendor-neutral, and built for one outcome: real operators running multi-tenant self-hosted runners in real clusters. There is no paid tier and no commercial roadmap — the plan below is about capability and adoption, not revenue.

It is a direction-of-travel snapshot, not a dated commitment. Priorities move with what adopters actually hit first, so the surest way to influence what comes next is to open an issue describing your setup. Every open item, in priority order, is in the working backlog.

In progress / near-term

Work that is scoped and actively being built — adoption-enabling polish and the last gaps an outside operator hits.

  • CI for untrusted pull requests on Kata workers Kata workers are validated for trusted CI only: the micro-VM bounds the guest kernel, the runner's egress stays permissive. Untrusted PRs need an in-cluster pull-through registry mirror plus egress scoped to it, GitHub, and DNS. Scheduled on an operator's ask; measurement first.

  • A curated runner template library Every tenant writes its own worker pod template today, including the fiddly parts: the Docker-in-Docker sidecar, the Kata runtimeClassName, the volume and security-context wiring. The templates our own end-to-end CI exercises become a shipped kustomize base you patch. No new API surface.

  • Opt-in auto-retry for flaky jobs A job the cluster disrupts already re-runs itself; a flaky failure does not. Same machinery, opted in per runner set with its own budget so a broken test cannot loop. Detection comes first.

The next four are all opt-in additions to the per-tenant proxy, tracked and shipping separately.

  • Proxy-side audit logging A structured line per accepted CONNECT — tenant, host and port, bytes each way, duration. The proxy emits counters only today, so per-tenant egress is reconstructable just from cluster flow logs. Off by default.

  • Per-tenant proxy rate limiting A token bucket at the proxy, so one looping tenant is slowed before it reaches GitHub's ceiling; today the only feedback is a 429 and AGC backoff. Per-pod state — global limits would need a shared backend.

  • TLS on the in-cluster proxy hop The CONNECT target is cleartext between the AGC or workers and the proxy, readable by an eBPF tap, though the tunnelled payload stays TLS to GitHub. Mount a cert-manager certificate and move to an https:// proxy URL.

  • A dedicated proxy pool per runner group One pool per gateway today, so a bandwidth-heavy group can saturate a co-tenant's. Give an opted-in group its own Deployment, Service, and autoscaler. Largest of the four; needs a plan doc before code.

  • Cross-namespace proxy sharing Share an egress proxy pool across namespaces with explicit consent: sharing.allowedNamespaces is served API today but not yet enforced, so the consent check lands before the beta contract hardens.

Exploring / longer-term

Directions we expect to pursue as demand and validated evidence accumulate. These are intentionally unscheduled — each waits on a real operator need, a measured limit, or a gating release before it becomes scheduled work. The first entry is the exception that proves the rule: it is a firm commitment, waiting only on the release that carries it.

  • Retiring v1alpha1, v2alpha1, and the classic acquisition protocol Committed, but not yet started. v1.3.0 is the one-release-ahead announcement; v2.0.0 is the named release that removes all three together, since v2beta1 is already ScaleSet-only. Gated on the v2 GA API being validated, not on a date.

  • Controller horizontal scaling / high availability. The per-tenant controller runs one replica by design — the session registry is in-memory, and HA comes from GitHub redelivering an unacquired job. Distributed session state would enable multi-replica HA if a single controller becomes a measured bottleneck.

  • Bring-your-own proxy TLS certificate Supply the proxy's certificate from your managed PKI or Vault instead of the GMC's self-signed default. (The autoscaler half has shipped: managedAutoscaling: false hands the pool to KEDA, VPA, or a custom HorizontalPodAutoscaler.)
  • First-class GPU runner support Priority tiers and the NodeShare sizing profile already carry the GPU cases, but GPU Operator / Node Feature Discovery awareness, and nodeSelector / toleration / RuntimeClass conventions that make a GPU runner set feel native, wait on a concrete GPU workload to design against.
  • A worker cache backend Workers are storage-less by design, so actions/cache and Docker layer caching have no home. Adding an optional PVC or object-store cache needs a security review of cross-job cache isolation first: a shared cache between tenants' jobs is an obvious exfiltration path.
  • A warm worker pool An opt-in pool of idle pods per runner set, for teams that still hit pod-schedule latency after image pre-pull and caching.
  • gVisor validation The runtimeClassName path is validated end-to-end with Kata; gVisor is documented but unproven on a real cluster. It waits on an operator who wants lightweight syscall filtering for compute-only, non-Docker-in-Docker jobs, since Kata already covers the DinD case.
  • SPIFFE / SPIRE workload identity A keyless, SPIRE-backed signer slots behind the existing signer interface alongside the deferred cloud-KMS providers, for operators who want no GitHub App private key anywhere.
  • An Operator Lifecycle Manager bundle. Helm-only is the deliberate install stance; an OperatorHub catalog entry waits on OpenShift demand.
  • A published benchmark and case study. Real GitHub-at-scale numbers behind the cost model, which needs a funded scale run rather than a local cluster.

How priorities are set

GAG's success metric is external operators running it and telling us what breaks — not stars or downloads. That feedback drives the ordering above far more than any internal plan. If something here is in your way, or missing entirely, open an issue — it's the fastest way to move it up.

The page above is the adopter-facing summary. The day-to-day ordering behind it is the working backlog — every open item, filterable by label, status, and size. It tracks the unreleased main branch, so it is published only on the dev version of this site and carries no commitment: rows are added, reordered, and deleted as work lands.