自建 Git 服务器怎么省成本?walgit 单二进制直接怼对象存储上

Tobi Lütke(Shopify CEO)把 Cursor《Git at any scale》里的 Continuity 架构用 Rust 落地成 walgit:没数据库、没 master、没重要本地状态,一个二进制指向 S3/GCS 桶就有 smart HTTP fetch/push、bundle-uri 克隆、Git LFS、Web 管理界面、JSON API 和 webhook,单机能服务比它自身更大的仓库。适合受够自建 Git 复杂度的团队,以及想把仓库托管成本压到只剩对象存储的人。

💡 快速判断Shopify CEO Tobi Lütke 用 Rust 落地的开源 Git 服务器 walgit,把 Cursor《Git at any scale》的 Continuity 架构做成单二进制怼在 S3/GCS 对象存储上:无数据库、无 leader、无重要本地状态,一个二进制就有 smart HTTP fetch/push、bundle-uri 克隆、Git LFS、Web 管理界面、JSON API 和 webhook,能服务比它自身更大的仓库。适合受够自建 Git 复杂度的团队、仓库巨大单机装不下的项目,以及喜欢单二进制工程哲学的开发者。注意:不含 PR/issues/CI,只专注托管;项目很新,生产前建议先跑其测试与故障注入模拟。

这是什么

walgit(tobi/walgit)是 Shopify CEO Tobi Lütke 用 Rust 写的一个 Git 服务器,核心思路一句话:没有数据库、没有 leader、没有重要的本地状态,你只需跑一个二进制、指向一个 S3(或任何 S3 兼容对象存储 / GCS)桶,就得到了完整的 Git 托管能力。

它的定位是把 Cursor 那篇《Git at any scale》里描述的架构(Cursor 内部叫 Continuity)搬到「比仓库还小的机器」上。作者 README 里直说:Git 是分布式的,但托管它的痛点全在 packfiles——仓库被压成不可按顺序读的大二进制包,每一次 git 操作都在跟这些大包搏斗。walgit 的解法是把「仓库变成对象存储里的一个 WAL(write-ahead log)」,每个节点只是可丢弃的缓存,真正的仓库是那个桶。

亮点

怎么用

一个桶 + 一份配置,然后就是跑起来:

# 1. 建桶 + 配置
cat > walgit.toml << 'EOF'
[server]
listen = "0.0.0.0:8080"
public_url = "https://git.example.com"
auto_create_on_push = true
[server.auth]
mode = "token"
anonymous_read = false
tokens = [{ principal = "me", token_env = "WALGIT_TOKEN_ME", write = true }]
[store]
backend = "s3"
bucket = "my-walgit"
[store.s3]
endpoint = "https://s3.us-east-1.amazonaws.com"
region = "us-east-1"
EOF

# 2. 跑服务
WALGIT_TOKEN_ME=$(openssl rand -hex 24) walgit serve --config walgit.toml

# 3. 用——push 到一个新名字就自动建仓库
git -c http.extraHeader="Authorization: Bearer $WALGIT_TOKEN_ME" \
  push https://git.example.com/acme/app.git main

就这么简单。同一桶上再加机器,它们服务同一批仓库、无需任何协调;全杀掉只是丢「热度」,丢不了数据(桶才是仓库)。

开发者侧设置交给一条幂等命令:

sh -c "$(curl -fsSL 'https://git.example.com/services/public/install.sh')"

它会把 token 写进只有用户能读的文件、装一个极小的 git credential helper(git ≥ 2.46),并开启 transfer.bundleURI

本地先试单机全功能:just dev-store + ./target/release/walgit-server --config walgit.standalone.toml(自带自签 TLS + rustfs 本地对象存储)。

适合谁

三点注意:不含 pull request / issues / CI——它专职做托管仓库,协作层还是得配 GitHub/GitLab/Forgejo 之类的平台(README 也明说了不覆盖这些);目标受众偏中大型自托管场景,不是替代 GitHub 全部功能;项目还很新(上线没几天),生产环境请先跑 just test 与故障注入模拟 cargo test -p walgit-server --test sim 再上。

⚡ 每日一荐,先人一步 电报频道「效率工具情报」每天 11:00 推送精选工具 + 编辑点评,还有网站没有的彩蛋内容。 👉 订阅频道:t.me/toolintel