Aspen: Self-hostable Git server for agent-scale traffic

Reason Machines launched Aspen, an independent self-hostable Git server engineered for repositories handling concurrent traffic from hundreds of automated agents, CI jobs, and developers. As reported in github.com's report, the pre-alpha system communicates over HTTP and SSH using stock Git clients. Instead of storing repository files on disk, Aspen writes immutable packs to object storage like S3 and tracks branch history inside PostgreSQL or SQLite.

This technical review details Aspen's architecture, concurrency guarantees, performance benchmarks, and pre-alpha readiness for engineering teams operating agentic coding fleets. It covers how the design eliminates repository-wide write locks, optimizes client fetch operations, and implements concepts from OpenAI's Pando and Cursor's Continuity storage engines. The article is written for infrastructure engineers, platform architects, and developer tooling specialists managing high-frequency version control workloads.

Self-hostable Git server for agent-scale: what actually changed

Standard Git servers store each repository as a directory on a single disk, forcing every push to claim an exclusive repository lock while fetches compel the server to recompress objects. Aspen removes this bottleneck by giving up the guarantee of a single global snapshot across every branch. Branches advance independently as version chains in a database using atomic compare-and-swap operations at the branch pointer. Concurrent pushes to different branches never wait on one another, while collisions on the same branch trigger standard Git non-fast-forward rejections.

Aspen also abandons the practice of building custom packfiles for every fetching client. Incoming pushes are validated, filled with missing base objects so they become self-contained, and written directly to object storage as immutable blobs. During fetch requests, the server streams these stored packs or hands out direct download links to caches and buckets without recompressing data. Furthermore, push negotiations advertise only the trunk branch. This restriction keeps pre-push discovery payloads constant in size regardless of how many temporary feature branches hundreds of autonomous coding agents generate.

Self-hostable Git server for agent-scale: how it works

The ingestion lifecycle begins when a client sends a pack over HTTP or SSH. Aspen inspects the pack, completes any thin delta chains using server-side objects, and persists the payload into object storage. Once durable in storage, a database transaction executes an atomic compare-and-swap on the branch pointer row in PostgreSQL or SQLite. This write records the new tip, the associated pack, and parent versions. Metadata updates are split into synchronous commit confirmations and asynchronous indexing tasks within the same transaction, keeping database latency bounded during heavy push bursts.

To satisfy read operations, Aspen manages stored packs using geometric levels reminiscent of log-structured merge trees. Background compactions merge smaller packs into larger layers that serve as skip lists across versions, enabling the fetch planner to identify necessary packs in logarithmic time. Stock clients receive missing packs stitched into a single streaming connection, while clients configured with URI protocol support download packs directly from storage or the regional aspen-express pack cache. Continuous integration workflows requesting depth-limited fetches are served precomputed shallow packs without requiring runtime commit graph traversals.

Self-hostable Git server for agent-scale: why it matters

The architecture resolves severe performance bottlenecks that arise when hundreds of automated coding agents push simultaneously to shared repositories. In benchmarks published by Reason Machines using an eight-core server, S3 Standard, and a four-core PostgreSQL database, Aspen sustained 567 pushes per second for five minutes against a copy of the Git project repository containing 4,500 files and 75,000 commits. Every push achieved durability in object storage and PostgreSQL before acknowledgment, recording a median latency of 208 milliseconds and a 99th-percentile latency of 314 milliseconds.

These results surpass reported rates from competing architectures while operating on general-purpose infrastructure. Cursor published push throughput of 120 pushes per second on S3 Standard and over 300 on S3 Express One Zone for its Continuity storage engine within an internal monorepo cluster. OpenAI reported cutting median push latency by nearly 80 percent with Pando while serving roughly one petabyte of Git data daily, without publishing explicit push rates. Aspen demonstrates that independent engineering teams can achieve comparable agent-scale throughput without proprietary hosted platforms or customized local client binaries.

Self-hostable Git server for agent-scale: who is affected

Organizations deploying autonomous software engineering agents, automated testing bots, and continuous integration suites stand to benefit most from this architecture. Traditional Git deployments struggle when hundreds of concurrent agents push distinct branches simultaneously, resulting in repository-level thread starvation and lock contention. Aspen isolates writes by branch, allowing bot fleets to push code independently without degrading responsiveness for human developers. Continuous integration pipelines also benefit directly from exact shallow pack serving, downloading single-depth commit snapshots from object storage without forcing the server to dynamically compute diffs during build spikes.

Teams requiring transactional visibility across multiple branches or high-frequency merges onto trunk will encounter clear operational boundaries. Because Aspen prioritizes per-branch consistency over repository-wide snapshots, readers querying several branches simultaneously may observe each ref at a slightly different point in time. Additionally, direct trunk merges do not match isolated branch throughput rates; sequential landings build upon prior commits and remain constrained by network round trips to roughly four updates per second. Workflows requiring high-throughput trunk updates must rely on batching mechanisms rather than uncoordinated pushes.

Self-hostable Git server for agent-scale: what to watch

Aspen is currently pre-alpha software that has not passed its internal launch gate, has no formal releases, and maintains storage formats that remain subject to revision. Reason Machines cautions users against storing critical production data in the server at this stage. Teams wishing to explore the design can run the single-process developer mode using SQLite or interact with an online shared canvas demo where each drawn stroke translates into a Git push. Organizations planning prospective migrations can test mirror mode to operate Aspen as a proxy alongside existing Git hosts.

Future tracking points include performance scaling on massive monorepos and formal benchmarks for Aspen's server-side merge queue. While individual branch pushes scale efficiently, very large monorepos face higher per-push overhead that moderates throughput. The optional merge queue is designed to batch multiple branch commits into single trunk updates, but its operational capacity remains unmeasured. Developers should also monitor release announcements for stable database schemas, group commit validation, and end-to-end benchmark results incorporating continuous integration fetch loads before deploying Aspen across mission-critical production infrastructure.