Skip to content

SYSTEM Cited by 5 sources

GitHub

GitHub is the dominant managed SaaS for hosting Git repositories (plus the surrounding ecosystem — issues, pull requests, Actions CI, Apps, etc.). The relevant deployment tier for enterprise monorepos is GitHub Enterprise Cloud (GHEC).

Server-side pack construction

The wiki's main load-bearing point about GitHub: GitHub constructs transfer packs dynamically on the server for each clone / fetch request, based on what each client is missing. The implication for repo-size engineering: a repack done locally, pushed to GitHub, does not persist. GitHub will rebuild the pack during transfer using its own packing configuration. A permanent pack-size fix has to run on GitHub's servers, using GitHub-supported flags and parameters.

This is why Dropbox's local git repack --path-walk experiment (84 GB → 20 GB) could confirm a root cause but could not ship — --path-walk is incompatible with GitHub's server-side optimizations (bitmaps, delta islands) that keep clone/fetch fast. The production fix was a GitHub-Support-assisted server-side repack with tuned --window=250 --depth=250 on GHEC's own replicas — see patterns/server-side-git-repack and sources/2026-03-25-dropbox-reducing-monorepo-size-developer-velocity.

Known limits

  • Repository size hard limit: 100 GB on GHEC. Approaching this ceiling is an operational-risk event, not just a velocity one — Dropbox's 87 GB + 20–60 MB/day growth was on track to hit the limit within months.
  • Bitmaps / delta islands are server-side optimizations used to accelerate clone/fetch on large repos; they constrain which repack strategies GitHub can apply (experimental flags that bypass the heuristic path — e.g. Git's --path-walk — are incompatible).

SSH endpoint: post-quantum KEX rollout

GitHub operates distinct transport surfaces for Git data access: Git-over-HTTPS (CDN-terminated) and Git-over-SSH (direct to GitHub's SSH endpoints). The two have independent cryptographic- agility timelines.

On 2025-09-17 GitHub added the hybrid post-quantum KEX sntrup761x25519-sha512 (formerly sntrup761x25519-sha512@openssh.com) to the supported-algorithm list on github.com's SSH endpoints and non-US-region GHEC. The primitive combines Streamlined NTRU Prime (PQ-secure KEM) with X25519 ECDH (classical) — see concepts/hybrid-key-encapsulation. GHES 3.19 ships the same change for self-hosted enterprise. HTTPS unaffected. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

Two load-bearing deployment properties:

  • Non-breaking rollout via algorithm negotiation. No client configuration needed. OpenSSH 9.0+ clients auto-select the PQ hybrid; older clients fall back to classical ECDH. The SSH protocol's KEX negotiation is doing the installed-base-heterogeneity accommodation.
  • US-region GHEC carved out for the FIPS boundary: "Only FIPS-approved cryptography may be used within the US region, and this post-quantum algorithm isn't approved by FIPS." US-region customers can enable PQ only after an ML-KEM-based hybrid lands in whatever SSH library GitHub uses.

Motivation is store-now-decrypt-later — see concepts/post-quantum-cryptography.

Supply-chain surface: immutable releases (GA 2025-10-28)

GitHub's Releases product is the tagged-artifact distribution surface on top of Git tags. On 2025-10-28 GitHub shipped immutable releases to GA: an opt-in repo/org setting that freezes new releases at publish time with three layered guarantees —

  • Asset immutability: once published, assets can't be added, modified, or deleted.
  • Tag protection: the Git tag for the release can't be deleted or re-pointed.
  • Release attestation: a signed Sigstore bundle travels with the release; verifiable via gh attestation verify or any Sigstore-compatible tool without re-contacting GitHub.

Scope is new releases only; disable is non-retroactive — both properties are definitional for publish-time immutability. The ecosystem-interop bundle-format choice (rather than a GitHub-proprietary envelope) is what makes the attestation half portable — see patterns/sigstore-bundle-attestation. (Source: sources/2025-10-31-github-immutable-releases-ga)

Rollout discipline for server-side repacks

GitHub rolls a production server-side repack gradually — typically one replica per day over a week, read-write replicas first, buffer time at the end in case of rollback. A repack changes the physical layout of billions of objects for every client interaction with the repo, so the ops discipline matches any other billions-of-objects-in-flight infrastructure change. See patterns/mirror-first-repack-validation for the mirror-first pre-production step.

Deployment-path self-protection: eBPF cGroup firewall

GitHub deploys GitHub on GitHub — the classic dogfooded SaaS circular dependency surface. Mirrors of source code + prebuilt rollback assets handle the "can't clone source during incident" baseline, but deploy scripts themselves can reintroduce dependencies on github.com (direct tool pulls, hidden auto-update checks, transient calls via internal services). The new host-based deploy system adds a structural enforcement primitive: a cGroup-scoped eBPF firewall that blocks github.com traffic from the deploy script's cGroup only, leaving customer-traffic-serving processes on the same host untouched.

Mechanism (see patterns/cgroup-scoped-egress-firewall + patterns/dns-proxy-for-hostname-filtering):

  • Deploy script runs in a dedicated Linux cGroup.
  • eBPF BPF_PROG_TYPE_CGROUP_SOCK_ADDR rewrites connect4 syscalls targeting UDP/53 to 127.0.0.1:<proxy_port>, funnelling all DNS queries from that cGroup to a userspace DNS proxy.
  • Proxy evaluates each requested hostname against a blocklist; blocked queries log a WARN DNS BLOCKED line with domain + PID + command line.
  • Per-query attribution comes from a DNS transaction-ID → PID eBPF map populated by a companion BPF_PROG_TYPE_CGROUP_SKB egress program using bpf_get_current_pid_tgid().

Outputs: (a) conditional blocking of dogfooding-circular dependencies at deploy time, (b) command-line-level attribution to the owning team, (c) audit list of every domain the deploy touched, (d) free-bonus CPU + memory cGroup limits preventing a runaway deploy script from starving customer workloads. Built in Go using the cilium/ebpf library; PoC published as lawrencegripper/ebpf-cgroup-firewall; six-month rollout, live in production. GitHub's post is the wiki's canonical source for cGroup-attached security-policy eBPF in a dogfooded-SaaS deployment context. (Source: sources/2026-04-16-github-ebpf-deployment-safety)

Stub page

Only covered here at the depth load-bearing for currently ingested sources (server-side pack construction, 100 GB repo limit, bitmaps / delta islands as packing constraints, replica-by-replica rollout). GitHub's broader API / PR model / Actions is out of scope; see systems/github-apps for the integration primitive.

Seen in

Last updated · 200 distilled / 1,178 read