git-server
==========
git-server is an OSS, MIT-licensed git server that is backed entirely by
S3/object storage. This makes it easy operationally, scalable for highly
concurrent/agentic workloads, and extremely cost effective.
Quickstart
----------
Run the server (requires a Rust toolchain for now). By default it listens
on 127.0.0.1:8470 and stores all data under ./git-server-data:
cargo run
From any repository push to the server. Unknown repositories are created
on the first push, so there is no setup step:
git push http://127.0.0.1:8470/myrepo main
Then clone it back from any other directory:
git clone http://127.0.0.1:8470/myrepo
Why git-server?
---------------
git-server is for developers building infrastructure like remote
filesystems, sandboxes and harnesses.
git-server is a low-level implementation of the git HTTP(S) protocol
that allows for concurrent, transactional access to multiple git
repositories backed by object storage. Unlike using an existing Git
hosting solution like GitHub, git-server has no rate limits or infrastructure
limitations. It is designed to be extremely cheap to store enormous amounts of
data and serve thousands of concurrent requests.
git-server is not a complete developer product, instead the intention is
to serve as an infrastructure component of other solutions such as
remote file systems and sandbox backends.
Why Is git-server On GitHub?
----------------------------
As suggested above, git-server is not a complete developer solution and
requires additional infrastructure (e.g. branch protection, pull request
functionality, authN/Z, etc...). We use GitHub to collaborate on the
development of git-server and mirror the repository to a self-hosted
git-server instance.
Also, whether we like it or not, GitHub is still the premier destination
for open source hosting. git-server has no intention of disrupting this for
open source human collaboration.
Architecture Overview
=====================
git-server is a single binary rust server built on https://slatedb.io that
speaks the git HTTP(S) protocol:
┌───────────┐ ┌────────────┐ ┌S3───────────┐
│ agent │────┐ │ git-server │█ │┌───────────┐│█
└───────────┘ │ │ │█ ││ blobs/ ││█
┌───────────┐ │ │ │█ │└───────────┘│█
│ agent │────┼───▶│┌──────────┐│─────▶│┌───────────┐│█
└───────────┘ │ ││ slatedb ││█ ││ slatedb/ ││█
┌───────────┐ │ │└──────────┘│█ │└───────────┘│█
│ human │────┘ └────────────┘█ └─────────────┘█
└───────────┘ ██████████████ ███████████████
Agents and humans can both concurrently connect to git-server and use it
to coordinate and resolve conflicts. All git objects (trees, commits, blob IDs)
are stored in SlateDB as well as any blob content that is under a certain
threshold (64KB default) while all blobs that exceed this threshold are stored
directly in S3. The blobs and the slatedb directories are stored within the same
S3 bucket.
> Note that S3 is a placeholder for any object storage system, we could use
> GCS, R2, Tigris, etc...
Contact/Contribute
==================
- open an issue / PR
- email almog [at] responsive [dot] dev
- X/Twitter @almoggavra
AI contributions are welcome after submitting a human-written issue
describing the problem/motivations. Any AI usage must disclose the
model used.
