GitHub Is Drowning in Agent Commits. Tangled Just Shipped a Federated Forge (2026)

GitHub's own engineers published a public apology for an outage ten weeks ago, and the commit number they blamed it on has more than doubled since.

Quick answer: On October 30, 2026, Tangled, a Finnish company building Git on the AT Protocol (the open protocol behind Bluesky), shipped what it calls the first federated code forge: self-hosted knots, issues and pull requests stored as Git objects inside the repo, and host-proof attestations. It landed the same week GitHub's own numbers showed why a centralized forge strains under AI-agent workloads.

You're reading this on a directory's blog, so here's the disclosure up front: SaaSCity runs a gamified startup directory, not a code forge, and we have no product stake in whether you use GitHub or Tangled. What we do have an opinion on is distribution dependency, because it's the exact same math whether the thing you're renting is your git history or your discoverability. Keep reading for the receipts, then decide for yourself.

What Tangled actually shipped on October 30

Tangled's October 30, 2026 post, "The federated code forge", announces a rebuilt architecture, not a new feature. Written by a contributor named Anirudh, it hit the Hacker News front page the same day with 298 points and 87 comments (HN item 50305573).

The old setup was a Go monolith called the "appview," doing AT Protocol indexing, caching and UI rendering with html/template plus htmx, all on one SQLite database, on one medium server in Sweden. Fine if your users sat 50-100ms away. Rough for everyone else. The new frontend is Svelte, deployed at the edge, fed by "bobbin": a diskless, fully in-memory Rust indexer now running in 11+ regions.

The release bundles several pieces at once. "knot2" is a from-scratch Rust rewrite of the self-hosted server, folding a custom Git server and an SSH server into a single binary. Issues, pull requests, comments, reactions and labels now live as "COBs" (collaborative objects): chains of Git objects stored right next to the code on the knot, under new org.tangled.* lexicons replacing the old sh.tangled.* ones. Every edit also writes an attestation record to your own personal data server, pointing at the exact version being changed, so a host can't quietly rewrite your words after the fact. Tangled calls it "two-way verification."

Organizations got a real identity too: a dedicated AT Protocol account with its own DID and handle, hosted on a Tranquil personal data server, passwordless by default, reachable at <name>.tngl.sh or a domain you already own. And the release adds stacked pull requests for both Git and Jujutsu users, with interdiff support between revisions. Private repositories, a CLI, SDKs and agent-specific tooling are explicitly listed as "up next." This is a staggered launch, not a finished product.

What a knot and spindle actually are

A "knot" is where your code and its conversations physically live, and that's the part that makes Tangled a federation instead of just another hosted forge. Per tangled.org, knots host repositories, "spindles" run CI inside NixOS microVMs with Docker, Postgres and Redis available and build inputs cached, and a vouching web-of-trust system handles reputation across knots instead of one company deciding who's trustworthy. The whole stack is open source, in the @tangled.org/core monorepo.

The line that matters most for the AI-agent framing sits right on that homepage: "agents work on Tangled the same way people do: from their own accounts, over plain Git. Every issue, pull request and comment is a simple JSON record, signed by whoever made it." That's a direct answer to the problem GitHub is currently living through: agents generating a majority of activity on a platform built, structurally, for one company to own every record of what happened. We've looked at a similar git-for-agents angle before in our piece on Oak, a git alternative built around AI agents.

This isn't Tangled's first attempt at the argument, either. Its April 2026 post, "We need a federation of forges", got 599 points and 406 comments on Hacker News, a bigger reaction than the actual release got. The idea landed before the code did.

GitHub's number problem: from 65 million to 7.4 billion

GitHub's monthly commit volume hit 7.4 billion in September 2026, up from 65 million a month in 2024, and that number is the real news story this month, not Tangled. According to The New Stack's October 28, 2026 report, monthly commits went from 1.4 billion in April 2026 to 2.9 billion in August and 7.4 billion in September, against 65 million monthly commits back in 2024. GitHub's own figures, reported by Tom's Hardware, put more than 40% of pull requests as agent-started by September 2026, up from 17% in March, with repos that start as AI-driven seeing roughly 8x the activity of human-only repos, and 17.9 billion code pushes across the prior 12 months, more than 2024 and 2025 combined.

This is GitHub absorbing a workload nobody designed the platform for a decade ago, when a "commit" meant one person typing rather than an agent looping through a task at machine speed. It's a sign of dominance under strain, not decline.

The August 17 outage, and the ongoing migration

GitHub's own account of its worst 2026 incident admits the infrastructure was already behind the growth curve months before the September spike hit. Vlad Fedorov's August 20, 2026 postmortem, "The August 17 outage, and the work ahead," describes a 7-hour-47-minute outage that took down github.com, authentication, Actions, APIs, pull requests, issues and Copilot. By that point commits had already climbed from 1.4 billion to 2.9 billion a month since April, GitHub had added 3 million CPU cores and 120PB of storage, and Azure was carrying roughly 58% of platform load, up from 12% in May 2026.

The migration behind that Azure shift is bigger than one outage. GitHub's engineering post on the bridge to agent-scale git infrastructure says 99.99999% of repositories now live in two places, data centers and Azure, most with five replicas, with the first repo copy landing in Azure Central US back in August 2025. The driver: a hard ceiling on data-center power capacity plus supply-chain constraints on new hardware, not a software choice.

It hasn't gone smoothly. GitHub's own September 2026 availability report admits it missed its own September 30 goal of moving every production service to Central US, with 120 of 160 services done and only 13 of 51 primary MySQL databases migrated. A planned failover disconnected Central US database copies mid-migration and disrupted customers. On the positive side: moving 24 auth tables off the oldest shared database cut roughly one million queries per second from replicas, deleting about 980 million unnecessary edit-history rows freed an estimated 1.8TB, and weekly deadlocks fell about 77% from their June peak. GitHub's stated order of operations: "availability, then capacity, then features." Then on October 27, 2026, a MySQL migration collided with a cleanup job that deleted roughly 59 million records, and authenticated git operations returned 404 errors for 1.24% of requests on average, 2.49% at peak, per the incident report at githubstatus.com.

Who's actually leaving, and who isn't

A handful of high-profile projects have moved off GitHub entirely, which matters more as a signal than as a trend. Zig announced its departure in November 2025, and Ghostty followed in April 2026, both cited in coverage of the broader shift toward alternative forges. That's two visible, deliberate exits by projects with the engineering muscle to run their own infrastructure. It is not evidence of an exodus; GitHub's commit growth alone makes that clear.

What this actually costs you, as a founder

GitHub isn't dying. A centralized forge did just become the single point of failure for a workload nobody designed it for, and that's worth pricing out for your own repo specifically.

Start with the outage math. If GitHub is down for eight hours, what in your business actually stops? CI, deploys, issue triage, maybe your status page linking to a GitHub-hosted doc. Now price the migration side: how long would it genuinely take to move your issues, pull requests, CI config, secrets, webhooks and badges somewhere else, if you had to? Most founders have never run that drill, and a forge outage is a bad time to find out the answer is "weeks."

Self-hosting isn't free just because the binary is cheap. Tangled's own self-hosting docs describe knot-server as a single Rust binary with no database: Git is the only store, plus a sealed key file. You need a Linux box that stays online, a DNS name that becomes the knot's did:web identity, your DID registered as first admin, and TLS, with SSH on port 2222. You can run it via a NixOS module or the container at atcr.io/tangled.org/knot:2. The signing keys sit in that sealed file, encrypted with a master key you supply through an environment variable, and the docs are blunt about the stakes: back that master key up somewhere away from the knot, because losing it means losing control of every repository's identity on that server. One binary, no database, and a single irreplaceable secret you now personally own. That's a genuinely good trade for some teams and a genuinely bad one for others. It's the same calculation we walked through for infrastructure generally in our self-hosting alternatives to Vercel and Supabase piece, and for agent-running infrastructure specifically in what an agent harness actually costs on AWS Strands versus DigitalOcean.

GitHub isn't standing still while this plays out, either. At Universe 2026, GitHub announced Copilot Fusion for multi-model orchestration, Copilot projects, Copilot code review Max, a multi-region Azure migration finishing early next year, and a new Git architecture GitHub says can hit up to 35x write throughput. That's real engineering money spent trying to stay the default.

The distribution parallel, and the actual close

Your repository is one asset your company can't easily replace. How people find your company is another, and it's just as easy to rent that from a single vendor too: a single search algorithm, a single app store, a single social platform's feed. We made a version of this argument about organic traffic depending entirely on one company's earnings priorities, and it holds here for the same reason: a dependency you haven't priced out is still a dependency, whether or not it's ever failed on you yet.

That's the honest pitch for diversifying discovery the same way you'd diversify infrastructure: owning a few small pieces of your own distribution costs less than finding out, mid-outage, that you own none of it. A free SaaSCity listing gets you a page and a building on the city map; add the badge and the backlink goes dofollow with a Monday launch slot. Quick Pass at $19.99 goes live within 24 hours. Premium at $49.99 adds a written launch post with three dofollow links. None of that replaces good SEO or a resilient git setup. It's one more brick that isn't rented from a company having the kind of year GitHub just had.

Fragmentation has its own cost, too: a knot you forget to back up, a federation with no private repos yet, a smaller community that can't answer a Stack Overflow-sized question in minutes. Whether federated forges stay a principled minority for teams who can afford the ops, or become the default once the tooling catches up, is a genuinely open question. Watch which way the next two years of commit volume moves, and watch who's still vouching for their knot when it does. If you're shipping something agents help you build, go build its distribution somewhere you don't have to ask an algorithm's permission first.