Sourcehut 介绍与选型指南

Sourcehut（sr.ht 模块化代码托管套件，AGPL-3.0）的认知选型篇：来历治理、meta/git/builds 模块化架构、Python+Go 双层服务设计、最新版本 core 0.84.10 / meta 0.88.9 / git 0.102.8，及与 Gitea/GitLab CE/Forgejo 的量化对比。

SourcehutSourcehut代码托管版本控制Python 编程2026/10/28

Sourcehut 介绍与选型指南

本篇是 Sourcehut 系列四篇中的认知选型篇：讲清楚它"由谁维护、为什么长得和别的代码托管平台不一样、模块化架构意味着什么、最新版本到了哪里、和 Gitea/GitLab CE/Forgejo 摆在一起该怎么选"。安装请看《Sourcehut 0.88.9 + git.sr.ht 0.102.8 Ubuntu 22.04 安装指南》，配置调优见《Sourcehut 配置参数详解》，日常维护见《Sourcehut 常用命令与运维详解》。

一、项目是什么：一句话与三个标签

一句话：Sourcehut（内部代号 sr.ht）是一套模块化开源代码托管平台套件——不是一个"软件"，而是一组可以独立安装、独立升级、独立扩缩的协作服务，由统一认证中心 meta.sr.ht 串成一张网络。

给它的三个标签：

  1. 黑客风极简主义：界面以纯文字、列表、快捷键为主，几乎没有图表与动画；协作方式高度依赖 git 原生工作流与邮件补丁（mail-driven development），这是它区别于所有主流平台的精神底色。
  2. 模块化到服务粒度：代码托管（git.sr.ht）、缺陷跟踪（todo.sr.ht）、邮件列表（lists.sr.ht）、持续构建（builds.sr.ht）、文档（man.sr.ht）、粘贴板（paste.sr.ht）、项目聚合（hub.sr.ht）、静态站点（pages.sr.ht）、Mercurial 托管（hg.sr.ht）各自独立成仓库、独立版本号、独立部署，任何一个服务坏掉不影响其余服务可用。
  3. 没有数据库之外的"魔法依赖"：核心栈是 PostgreSQL + Redis + Nginx + systemd，Web 层 Python（Flask + SQLAlchemy + Ariadne GraphQL），API 层 Go。没有 Elasticsearch、没有对象存储强依赖（S3 是可选）、没有内置的消息总线。

二、来历与治理沿革

2.1 出身：Drew DeVault 的"反臃肿"实验

Sourcehut 由 Drew DeVault（Sway/Wayland 生态知名开发者）于 2018 年前后创建并对外运营，最初的目的非常朴素：给自己和同好一个"够用就好、不催也不烦"的代码托管地。随着 hg.sr.ht、builds.sr.ht、lists.sr.ht 等服务陆续上线，它逐渐成为一套完整的协作平台，并从 2019 年起对外销售托管服务（托管版至今仍在运营，付费用户承担了开发费用）。

2.2 治理：AGPL-3.0 与"公地"模式

  • 所有服务代码以 AGPL-3.0-only 发布（部分 Go 基础库为宽松许可），托管在自家 git.sr.ht 上——吃自己的狗粮是它最直接的对外演示。
  • 项目定位是"可自托管的公地"：官方鼓励自托管，但从不隐瞒自托管的门槛（下文详述）。运营托管版与开源代码的关系类似"服务养软件"。
  • 主力维护者为 SourceHut 团队成员（Drew DeVault、Conrad Hoffmann、Simon Martin 等），社区贡献走源码仓 + 邮件列表，这本身就是平台工作流的示范。

2.3 版本节奏：按服务独立发版

Sourcehut 没有"整体版本"，每个服务有自己的 tag 序列。截至本文查询日期 2026-10-28，核心三个仓库的最新 tag 为：

组件角色最新 tag发布时间（距今）
core.sr.ht公共库（全部服务的地基）0.84.107 天前
meta.sr.ht统一认证/用户中心（必装）0.88.95 天前
git.sr.ht代码托管服务0.102.85 天前

（来源：git.sr.ht 各仓库 refs 页，查询日期 2026-10-28。发布频率大约每月 1-2 个 tag，小步快跑，无 LTS 概念。）

三、架构：为什么它是"套件"而不是"软件"

3.1 服务拓扑

一次典型部署中，各服务的角色与依赖如下：

                    ┌──────────────┐
        Nginx ──►   │  meta.sr.ht  │  用户、认证、OAuth、SSH key、计费（可选）
                    │  web :5000   │
                    │  api  :5100  │  Go GraphQL API
                    └──────┬───────┘
                           │ 内部 GraphQL 互调（service-key/network-key 签名）
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
 ┌────────────┐    ┌────────────┐     ┌────────────┐
 │ git.sr.ht  │    │ todo.sr.ht │     │ builds.sr.ht│ ...
 │ web :5001  │    │  web :5002 │     │  web :5003 │
 │ api :5101  │    │  api :5102 │     │  api :5103 │
 │ clone :5051│    └────────────┘     └────────────┘
 └────────────┘
        │
        ▼
 PostgreSQL（每服务一库） + Redis（缓存/webhook） + /var/lib/git/（裸仓库）

三条铁律：

  1. meta.sr.ht 是唯一必装服务，其余一切可按需增减。只装 meta 就能得到一个"单点登录 + 用户管理"的最小站。
  2. 每个服务都是"web + api"双进程：web 层是 Python（Flask），api 层是 Go（GraphQL，端口约定为 web + 100）。web 层之间不直接查对方的库，一律走内部 GraphQL 调用——这是"模块化"能兑现隔离性的关键。
  3. 数据不共享：git.sr.ht 只读自己的 git 库，用户信息通过 rid（全局资源 ID）与 meta 关联。扩容时可以按服务拆机器，一台跑 meta，两台跑 git，各管各的库。

3.2 每服务的 Go API + Python Web 双层设计

这个双层结构在同类平台中相当少见，值得展开：

  • Python web 层：Flask + SQLAlchemy + Jinja2，负责页面渲染、表单、会话；GraphQL 客户端代码由 ariadne-codegen 从 schema 生成。
  • Go api 层：gqlgen 实现的 GraphQL 服务，负责写操作、权限与跨服务 RPC；服务间调用用 service-key/network-key 加密签名（sr.ht-keygen 生成）。
  • 静态资源：SCSS 源码由 sassc 编译、minify 压缩，统一落在 /usr/share/sourcehut/static/<服务>/，运行时按内容哈希做指纹 URL。

对部署者的直接含义：装一个"最小可用集"（meta + git）实际要跑 4 个进程（meta web/api + git web/api），外加可选的 http-clone CGI 网关——比"单二进制"平台重，比"全家桶"平台轻。

3.3 数据流：一次 git push 走了哪里

以 git push 为例（SSH 通道，生产形态）：

  1. 用户 git push 到 git@git.example.com:~user/repo，sshd 触发统一 SSH 分发器（sourcehut-ssh）按用户名前缀路由到 git 服务。
  2. 仓库 hooks（pre-receive/update/post-update，均为指向 git.sr.ht-update-hook 二进制的符号链接）拦截推送：pre-receive 阶段经 Go API 校验权限，post-receive 阶段刷新 DB、触发 webhook（Redis 队列）、同步到外部 Git 托管商（可选）。
  3. 页面读取与 HTTP clone 则由 web 层与 CGI 网关（git.sr.ht-http-clone + fcgiwrap）直接服务裸仓库目录 /var/lib/git/~user/repo。

这套"裸目录 + 钩子 + GraphQL 编排"的设计意味着：仓库永远是可以直接 git bundle/rsync 备份的标准裸仓库，没有私有存储格式。

四、功能盘点：有什么、没什么

4.1 有什么（以最小可用集 meta + git 为例）

  • 统一账号体系：注册、登录、TOTP 两步验证、PGP/SSH 密钥管理、审计日志、OAuth 2.0 客户端与令牌。
  • 代码托管：公开/私有/未列出三级可见性、fork、分支保护级别的轻量实现、README 渲染、提交/分支/tag 浏览、构建徽章。
  • GraphQL API：全套服务的读写 API，复杂度预算可配（默认 200），比 REST 更省流量的按需取数。
  • Webhook：per-repo 配置，Ed25519 签名载荷。
  • 工件与补丁：通过邮件列表收发 git 补丁是 git.sr.ht 的一等公民工作流（send-email 集成）。

4.2 没什么（选型前必须有心理预期）

  • 没有内置 PR/Issue 一体化：Issue 在 todo.sr.ht，代码评审走邮件列表补丁或 fork + 邮件，"网页上一键 Merge"的体验弱于 GitHub 系平台。
  • 没有内置 CI：builds.sr.ht 是独立服务（本系列部署不覆盖），触发靠清单文件提交给 builds API。
  • 没有 Web 端在线编辑：所有代码修改都必须走 git 命令行。
  • UI 无中文：界面仅英文，文案风格极简。

五、量化选型对比：Sourcehut vs Gitea vs GitLab CE vs Forgejo

四者同为可自托管代码托管平台，但产品哲学差异极大。下表数据口径：官方文档与 release 信息，查询日期 2026-10-28；内存为官方推荐起步值。

维度Sourcehut（meta+git 最小集）Gitea 1.24.xGitLab CE 18.xForgejo 13.x
许可证AGPL-3.0MITGitLab CE 专有许可（MIT 内核+企业代码混合源可得）MIT（由 Codeberg 主导，GPL 栈友好）
架构形态多服务套件，按模块安装单二进制 + 单库单体（Ruby on Rails + Go 组件群）单二进制 + 单库（Gitea 硬分叉）
语言栈Python(Flask)+Go+SCSSGoRuby+Go+VueGo
官方推荐起步内存每服务 web+api 各 256-512MB，最小双服务建议 ≥2GB2 核 4GB（1 核 512MB 可跑小站）4 核 8GB（官方最低，4GB 勉强）同 Gitea 量级，1-2GB 可跑
单点登录/多服务组合原生：meta 统一认证，模块自由组合无（单体即全部）无（单体即全部）无（单体即全部）
Issue/PR独立服务 todo.sr.ht；评审偏邮件补丁内置，体验类 GitHub内置，功能最全内置，体验类 GitHub
CI独立服务 builds.sr.ht内置 Actions（兼容 GitHub Actions 语法）内置 CI/CD（成熟）内置 Actions
Mercurial 支持原生（hg.sr.ht）无无无
邮件驱动工作流一等公民（lists.sr.ht + send-email）无部分支持（service desk 邮件转 Issue）无
中文界面无有有有
安装包无官方 deb/RPM（2023 年起停发），源码编译官方 deb/RPM 及各类打包形态全官方 deb/RPM 全官方 deb/RPM 及各类打包形态全
运维心智每服务独立升级/迁移，版本碎片化管理一个版本号管到底一个版本号管到底一个版本号管到底

三条结论性判断：

  1. 选 Sourcehut 的理由：想要模块化隔离（git 服务崩了不影响 issue 服务）、想要邮件补丁工作流、想要 Mercurial、想要"每台机器只跑该跑的东西"的 hacker 美学，且团队不依赖网页重交互。
  2. 不选的理由：团队要 GitHub 式 PR 评审、要中文界面、要"一个包一键升级"、只有 1 台小机器想跑全功能——这些场景 Gitea/Forgejo 更合适；要全家桶企业功能则 GitLab CE 更合适。
  3. 隐藏成本提示：Sourcehut 官方自 2023 年起不再发布 apt/RPM 包（官方公告声明维护负担过重），自托管只有源码编译一条路，且要求 Python ≥3.10（上游按较新 Python 开发，Ubuntu 22.04 自带的 3.10 需要少量兼容处理，详见安装篇实录）。这是它区别于三个对比对象的显著门槛，也是本文系列存在的意义。

六、适用场景画像

  • 个人/小团队的"安静的代码托管"：不需要花哨界面，看重 API、裸仓库与邮件工作流。
  • 多服务并行演进的研发组织：认证/托管/CI/缺陷各自独立部署与升级，隔离性好，故障半径小。
  • 已有 PostgreSQL + Redis + Nginx 运维能力的团队：没有新的运维栈学习成本（相比 GitLab 的专属运维心智）。
  • 反例：非技术团队、需要中文界面、需要网页端重交互评审的团队，请直接看 Gitea/Forgejo。

七、本系列的验证口径

本系列四篇的全部实测基于：Ubuntu 22.04.5 LTS、PostgreSQL 14、Redis、Python 3.10（含兼容补丁）、core.sr.ht 0.84.10 + meta.sr.ht 0.88.9 + git.sr.ht 0.102.8，交付目标为单机最小可用集（meta + git），示例账号 srhtadmin（密码 q1w2e3r4，注意 admin 属于上游内置保留用户名，无法注册）。其余模块（todo/lists/builds 等）安装方式同构，在安装篇末尾给出指引。

参考资料

  1. Sourcehut 官网与自托管文档：https://sourcehut.org 、https://man.sr.ht/pages/install.md （查询日期 2026-10-28）
  2. 各服务源码与版本 tag：https://git.sr.ht/~sircmpwn/meta.sr.ht/refs 、https://git.sr.ht/~sircmpwn/git.sr.ht/refs 、https://git.sr.ht/~sircmpwn/core.sr.ht/refs （查询日期 2026-10-28）
  3. Gitea 安装文档（硬件需求）：https://docs.gitea.com/installation/install-from-binary
  4. GitLab CE 系统需求：https://docs.gitlab.com/ee/install/requirements.html
  5. Forgejo 项目主页：https://forgejo.org