awesome-selfhosted ：自托管软件的维基百科

你打开了一个 GitHub 上 30 万 Star 的仓库，准备看看是什么神仙代码。往下翻了三屏，一个 .py 文件都没有。不是藏起来了，是真的没有。

awesome-selfhosted 是一个纯粹的收录清单。它不执行任何操作，不提供任何 API，不输出任何二进制。它干的事只有一件：把几千个能自己在服务器上部署的免费软件，按 80 多个分类整理好，每条附上简短说明、许可证和技术栈。用维护者自己的话说，Self-hosting is the practice of hosting and managing applications on your own servers instead of consuming from SaaSS providers。

但仅仅说它是一个”清单”是严重低估了它的价值。从 2015 年建立到现在，这个仓库积累了 7000 多次提交、14k forks，社区贡献者来自全球各地。它的 HTML 版本（awesome-selfhosted.net）是很多自托管爱好者每天打开的第一个网站，在国内技术社区里也被反复推荐。

这篇文章不是要告诉你”有个清单叫 awesome-selfhosted”，而是要讲清楚这个清单为什么比大多数自托管教程都有用，以及你在用它的时候最容易踩的两个坑。那这个没有一行代码的清单，到底凭什么拿到 30 万 Star？

为什么值得关注

先说结论：awesome-selfhosted 的信息架构做得很聪明，比绝大多数同类清单强一个档次。

数据驱动的生成架构是最大的差异化优势。大多数人不知道，你在 GitHub README 里看到的那个 Markdown 列表不是手写的。项目的实际数据存在一个独立的仓库里，每个软件是一个结构化的 YAML 文件。Markdown 版本和 HTML 网站都是从这个数据源自动生成的。这意味着同一条数据可以被不同前端消费，维护者改一个 YAML 字段，两个版本同步更新。

这种架构在 Awesome 列表里极其罕见。绝大多数同类项目（包括 awesome-sysadmin）还是纯手写 Markdown，改一个描述要在多个地方同步。awesome-selfhosted 的分离式设计让它能支撑起几千条记录的规模而不失控。

严苛的收录标准是另一个被低估的亮点。维护团队设了四道硬门槛：必须是自由软件（专有软件去独立的 non-free.md 页面）、首次 Release 必须超过 4 个月、不接受纯库或 SDK 或 PaaS 类项目、禁止 LLM 生成的贡献内容。最后这条尤其有意思，在当前 AI 内容泛滥的背景下整个 GitHub 都在被 AI 生成的 PR 淹没，awesome-selfhosted 选择直接 ban 掉机器内容，违规者会被封禁。

定期清理机制也值得单独提一句。CI 管道里跑着死链检测和无人维护项目自动扫描，没有开发活动超过 6 到 12 个月的项目会被清理。这保证了清单不会沦为链接公墓，这个质量控制的成本远低于大多数同类项目。

社区驱动的精度控制让条目质量出奇地一致。贡献规则非常具体：描述中禁止使用 open-source、free、self-hosted 等冗余词汇（因为在 awesome-selfhosted 里出现已经隐含了这些属性），描述要尽可能短，fork 项目必须标注与原项目的差异。这些看似琐碎的规则攒在一起，导致你看清单时不会出现”前面是精品、后面是灌水”的体验断层。

但架构说得再漂亮，你不打开用一下也白搭。实际体验是什么感觉？

上手什么感觉

awesome-selfhosted 本身不需要安装。但如果你想高效地用它，有几个路径。

直接浏览推荐用 HTML 版本。awesome-selfhosted.net 提供搜索、标签过滤和分类导航，体验比 GitHub README 好很多。网站支持按编程语言、平台（Docker、Node.js、Python 等）和许可证筛选，比纯文本阅读效率高不少。

如果想把数据拉到本地做批量检索，把数据仓库 clone 下来然后用你习惯的工具处理：

git clone https://github.com/awesome-selfhosted/awesome-selfhosted-data.git
cd awesome-selfhosted-data/software
grep -rl "Docker" . | head -20

每个软件条目的 YAML 结构是标准化的，你可以写脚本按平台、许可证、标签做筛选：

name: "My Awesome Software"
website_url: "https://example.com"
source_code_url: "https://github.com/example/awesome"
description: "Short description of the software"
licenses:
  - MIT
platforms:
  - Docker
  - Nodejs
tags:
  - Automation

如果你想贡献新项目，三个容易踩坑的地方要提前知道：

• 贡献入口不是主仓库：实际的 PR 入口在 awesome-selfhosted-data 仓库，很多人搞错这一点直接往主仓库提 PR
• 文件命名必须 kebab-case：新增软件的 YAML 文件用下划线命名会被打回
• 新标签至少需要 3 个引用：创建一个新分类标签前，确保有至少 3 个已有软件能引用它

另外描述里不要写”a self-hosted tool that…”这种废话，直接写核心功能是什么。

贡献流程本身很规范：创建 YAML 文件、写提交信息、提 PR、等 CI 检查跑完、等维护者审核。整个过程完全在 GitHub 上完成，不需要额外工具。

体验上的坑说清楚了，不过更关键的问题还没聊。你拿到了这个清单，然后呢？哪些场景用它效率最高，哪些场景你不如直接搜 GitHub？

适合谁，不适合谁

不适合用它的情况也很明确：

• 想直接得到一个”最好用的自托管 XYZ”？清单不做评测也不做推荐，你得自己逐个评估
• 在找一个特定语言的库或 SDK？去 awesome-sysadmin 更合适，awesome-selfhosted 明确排除了纯库和 PaaS 类项目
• 要部署一个生产级邮件服务器？清单能告诉你有哪些选项，但不会给你运维建议

还有一个很多新手会掉进去的坑：清单收录不等于”好用”。有些项目虽然进了清单，但最后一次 commit 是两年前，文档只有三行 README。清单的筛选标准是自由软件加 4 个月 Release 年龄的最低门槛，不是”经过验证的生产级工具”。这条没理解透，你就容易翻到一堆好看但跑不起来的项目。

不过适合不适合是一回事，这个项目本身能不能长期维护下去是另一回事。把核心数据摆在面前看看它到底靠不靠谱。

维护靠不靠谱

判断一个列表类项目的维护质量，不能看代码覆盖率或者 CI 通过率这种传统指标。得看三个东西：更新频率、清理机制、社区参与度。awesome-selfhosted 在这三项上都做得不错。

自动化 CI 是可持续性的核心保障。死链检测和无人维护项目扫描跑在 GitHub Actions 上，不需要维护者手动翻几千个链接。数据与展示层分离的架构让维护改动成本很低，删一个死链只需要删掉对应的 YAML 文件然后等 CI 重新生成页面。这种设计的工程意识在 Awesome 列表项目里属于第一梯队。

社区讨论这块比较特殊。因为仓库本身是列表，Issue 和 Discussion 功能都关闭了，外部反馈主要出现在知乎和掘金等中文技术社区。知乎上一篇推荐帖将 awesome-selfhosted 称为”自我托管界的百科全书”，掘金上的系列文章介绍了它覆盖的 100 多个分类，定位为”自托管爱好者的必备索引”。两份内容都强调了它作为 SaaS 替代品发现工具的独特价值。

不过有一点值得关注：维护团队通过 Liberapay 众筹来支付域名费用。目前月收入覆盖域名开支有余但远不足以支撑全职维护，核心维护者的参与程度取决于个人时间，存在波动风险。

维护我看完了，聊点真的：这个项目到底值不值得在你的书签栏里占一个位置，还是看完这篇文章就够了？

我的真实看法

我翻这个清单翻了很久，最深刻的感受不是”收录了多少项目”，而是这件事的价值在加速放大。

自托管运动在 2025 到 2026 年经历了一轮明显的加速。SaaS 订阅费用累积到让个人用户和小团队吃不消的地步，Docker 和 Docker Compose 把部署门槛降到了一两条命令，再加上数据隐私意识在全球范围内的提升，这三个因素叠加让”自己部署”从一个极客爱好变成了理性的技术选择。

awesome-selfhosted 作为这个领域的核心索引，它的价值是与自托管运动一起增长的。每多一个人开始自托管，这个清单就多一分实用价值。

但这个清单有一个结构性局限，大部分使用者没意识到。它收录的是”可以自托管”的软件，不是”自托管体验好”的软件。一个用 PHP 写的、需要手动配置 nginx、Redis 和 MySQL 才能跑起来的笔记应用，和一个用 Go 打包成单二进制文件一键部署的同类型应用，在清单里是一样的待遇。维护者有意不做评价，把判断留给读者，这本身就是清单类项目的核心哲学。但作为使用者，你要清醒地知道你在一个没有评级的目录里挑东西。

非自由软件页面（non-free.md）是个容易被忽视的宝藏。它收录了不少高质量的专有自托管软件，涵盖一些知名的项目管理工具和监控平台。如果你不介意不是纯开源的，这个页面的很多项目比主列表里的功能完整得多。很多自托管老手翻完自由软件区之后会直奔这个页面。

趋势上看，这个项目处于健康的上升期。Stars 增长不是因为一次性的 viral 效应，而是跟自托管运动的整体趋势同步。维护架构的数据驱动设计和自动化 CI 让它不太可能因为维护者 burnout 而烂掉。只要自托管运动不降温，这个清单就不会停止更新。

资源地址

资源都在这了，接下来聊聊怎么用好它们。不是收藏然后吃灰，是真的用起来。

先用搜索，再看分类

如果你正在考虑自托管一些服务，从 awesome-selfhosted.net 的搜索框开始最直接。输入你正在付费的 SaaS 名字，看看有没有可部署的替代品。

如果你在为团队或公司做技术选型，建议的做法是先在清单里锁定 3 到 5 个候选，然后各自去翻 GitHub Issue 和最近半年的 commit 记录。清单负责发现，你自己负责评估。

如果你已经在自托管的路上了，关注两个变化趋势。第一，清单里支持 Docker 和 Docker Compose 部署的项目占比在持续上升，这是一个健康信号，说明自托管工具的易用性在整体改善。第二，留意被列入 non-free 页面的项目，它们往往是商业自托管市场中增长最快的部分。

在这个所有 SaaS 都在想办法让你产生依赖的时代，知道自己有什么替代选项本身就是一种权力。awesome-selfhosted 不替你选，但它让你知道自己有的选。