East River details a post-Git storage engine that still speaks Git

East River Source Control, the Brooklyn source-control startup founded by Benjamin Brittain and David Barsky in 2025, published a September 11th technical manifesto describing a storage engine that keeps Git at the network edge while replacing the Git repository underneath as a bridge to Jujutsu. The company said on September 1st that ERSC Storage was expected to enter private beta later in September, and the product remains unavailable for general use. East River argues that AI coding agents, which multiply clones, branches and concurrent changes, will push repository-based Git hosting architectures past their limits, though the September post provides no production benchmarks or named early partners.

East River details a post-Git storage engine that still speaks Git The Brooklyn startup is using Git compatibility as the migration layer for Jujutsu and agent-heavy monorepos. By RuntimeWire Staff /author/runtimewire-staff · Published Primary source: East River Source Control https://ersc.io/blog/what-comes-after-git Why it matters AI coding agents multiply clones, branches and concurrent changes. East River is betting the durable opportunity sits beneath the agent interface, in the storage system every tool must trust. East River Source Control https://ersc.io/?ref=runtimewire , the Brooklyn source-control startup founded by Benjamin Brittain https://www.linkedin.com/in/benjamin-brittain?ref=runtimewire and David Barsky https://davidbarsky.com/?ref=runtimewire , published a technical manifesto on September 11th describing its architecture: keep Git at the network edge, replace the Git repository underneath, and use that storage layer as a bridge to Jujutsu. The founders are taking on one of software infrastructure's least forgiving migration problems. Brittain is a backend and systems engineer focused on Rust and open-source software. Barsky previously worked on rust-analyzer at Meta and has contributed across the Rust tooling stack. They started East River in 2025 around a thesis that coding agents would push source-control workloads beyond the assumptions embedded in Git and conventional Git hosting. Their answer is designed to look familiar from a developer's laptop. A regular Git client connects over the Git protocol, as it would with an existing host. Inside East River's service, a bridge translates those operations into a custom storage engine. The server does not keep a conventional Git repository as its source of truth. That distinction is the company. GitHub, GitLab and other forges have built large service layers around Git repositories. East River is replacing the layer beneath those services while preserving the interface that existing developer tools expect. Changing the engine without forcing a migration East River's September 11th post https://ersc.io/blog/what-comes-after-git?ref=runtimewire is a technical manifesto, not a product launch. A more detailed May 4th product update https://ersc.io/blog/ersc-availability?ref=runtimewire covered the storage engine's planned capabilities, Git and Jujutsu compatibility, early-partner trials and planned code review. The product remains unavailable for general use, and East River said on September 1st that ERSC Storage was expected to enter private beta later in September. The timing still matters. AI coding tools are making it cheap to create additional branches, clones, workspaces and proposed changes. Agent workloads can run concurrently in isolated cloud environments, repeatedly pulling repository context and pushing work back for review. The operational patterns once associated with the largest monorepos are beginning to appear inside smaller engineering organizations. East River argues that the repository-based architecture behind most Git hosting will become the constraint. Its custom engine is intended to scale horizontally, isolate customer deployments and support the access controls, large files and concurrent changes that enterprise development requires. A GraphQL interface also sits alongside the Git bridge, according to the company. ERSC has previously described its system as supporting horizontal scalability, instant checkouts, large repositories and arbitrarily large files. Those remain company claims. The September post does not provide production benchmarks or identify the early partners that Brittain said were trialing the product in May https://ersc.io/blog/ersc-availability?ref=runtimewire . The adoption strategy is clearer than the performance case. Developers can continue using Git, CI systems can continue speaking Git, and companies can keep the workflows built around Git. East River changes the storage layer first, leaving client migration as an individual or organizational choice. That is a practical concession to Git's network effects. Source control holds an organization's most valuable technical asset, and infrastructure teams tend to treat replacement proposals accordingly. A clean-sheet version-control system can improve the model and still fail because every surrounding tool assumes Git. Brittain and Barsky are trying to separate the technical replacement from the organizational migration. Jujutsu gives East River its second route in East River's architecture is also a bet on Jujutsu https://www.jj-vcs.dev/latest/?ref=runtimewire , the open-source version-control system created by Martin von Zweigbergk. Jujutsu can use Git as a backend today, allowing one engineer to adopt its change model while colleagues continue using Git clients. Von Zweigbergk joined East River as chief technology officer https://ersc.io/blog/martin-joins-ersc?ref=runtimewire on September 1st after 15 years at Google. He began Jujutsu as a side project in late 2019 and later worked on it full time. Before Jujutsu, he worked on Fig, a Mercurial client used with Google's Piper monorepo, and contributed to Git. The Jujutsu repository is linked from his GitHub profile https://github.com/martinvonz?ref=runtimewire . His appointment gives East River direct experience with both sides of its bridge: the incumbent protocol and a possible successor. Von Zweigbergk described the dividing line in the company's appointment announcement: Jujutsu improves local version control, while the remote server generally remains Git. East River eventually wants Git and Jujutsu clients to communicate with the same underlying storage engine through separate protocols. That native Jujutsu path is future work. Jujutsu does not currently have an official native network protocol, and East River says any client changes needed for one would be open source and developed with the project's maintainers. The distinction matters because East River is not claiming control over Jujutsu's roadmap. Von Zweigbergk will remain a core maintainer of the Apache 2.0-licensed project, while East River develops proprietary server infrastructure around the broader source-control problem. The source-control layer is getting crowded again East River is arriving as several well-funded companies reopen questions the industry largely stopped asking after Git became dominant. GitHub co-founder Scott Chacon's GitButler raised a $17 million Series A https://blog.gitbutler.com/series-a?ref=runtimewire led by Andreessen Horowitz to develop Git-compatible workflows for stacked and parallel branches, agents and easier undo. Zed https://zed.dev/blog/sequoia-backs-zed?ref=runtimewire is building operation-based version control that records edits at finer granularity and keeps collaboration context attached to code. Entire has launched a distributed Git network https://entire.io/news/entire-launches-distributed-git-network-for-the-agent-era?ref=runtimewire for agent-heavy cloning and pushing, alongside tools that preserve agent sessions and prompts. The incumbents see the same pressure. In June, GitLab put a next-generation source-code backend https://about.gitlab.com/press/releases/2026-06-10-gitlab-announces-new-capabilities-to-give-enterprises-speed-control-at-agentic-scale/?ref=runtimewire into private beta. GitLab says its system lets agents query project data through structured APIs instead of repeatedly cloning repositories, reducing network traffic and task time in its internal tests. East River's position in that field is unusually low in the stack. GitButler starts with the developer workflow. Entire adds distribution and agent history. GitLab can integrate repository intelligence into an established forge. East River is betting the storage engine itself needs replacement. Its deployment plans include hosted installations, deployments inside a customer's cloud account and self-managed operation using Kubernetes and S3-compatible storage. Customers could also bring their own code review, CI and issue-tracking systems instead of moving an entire software-development stack at once. Amplify backed the infrastructure bet early A 2025 SEC filing https://www.sec.gov/Archives/edgar/data/2076429/000207642925000001/xslFormDX01/primary doc.xml?ref=runtimewire records East River selling $4,864,998 of a planned $5 million equity offering to four investors. The filing lists Brittain as an executive officer and director, Barsky as a director, and Amplify Partners general partner Lenny Pruss as a director. East River identifies Amplify Partners https://www.amplifypartners.com/team/lenny-pruss?ref=runtimewire as a backer. Pruss has invested in developer-infrastructure companies including Datadog, HashiCorp, Temporal, Sourcegraph, Chainguard and Antithesis. His involvement fits East River's attempt to sell a foundational system into engineering organizations, where adoption cycles are long and reliability failures are costly. East River has chosen the cautious route into that market. It is keeping the Git command, Git protocol and existing tooling in place while asking customers to trust a young company with the system storing their code. That compatibility reduces migration risk, although it also means East River must prove its new backend creates enough operational value before customers reach the limits of Git hosting they already understand. Brittain and Barsky are wagering that coding agents will bring those limits forward. If they are right, the successor to Git may first arrive disguised as a Git server.