按当前标价，一个 3 人团队使用 GitHub Team、Vercel Pro、Sentry Team、Linear Basic 和 Notion Plus，每月起价约 158 美元，还不含 1Password、用量费用和附加项。范围划定得当的自托管技术栈能显著压低这笔开支，但公平的比较还要算上比 4 GB 实验下限更大的 VPS，以及人人都会忽略的维护时间。
本指南面向已经认定“SaaS 账单很烦人”以及“把私有代码和开发工作流放在第三方基础设施上让人不放心”，现在想弄清楚具体该运行什么的开发者或小团队。这套技术栈分四层：代码、构建与部署、运行、文档。每一层给出一个推荐工具、一个备选方案、资源开销和失效方式。范围限定为单台 VPS 上的私有与团队使用。邮件托管、DNS、面向客户的身份认证以及 Kubernetes 不在范围内，理由会在相应位置说明。
简短版本
如果你只看要点：
- 代码： 默认选 Forgejo。只有当你想把 git、CI/CD、镜像仓库和议题放进同一个产品时才用 GitLab CE；GitLab 当前的单节点基准是 16 GB 内存，8 GB 是留给内存受限环境的。
- 构建与部署： Coolify on the current stable release (v4.3.0 at QC time), with the dashboard kept off the public internet. Dokku suits solo developers; pure Docker Compose suits teams that prefer visible moving parts.
- 运行： 共享凭据用 Vaultwarden，监控用 Uptime Kuma，错误追踪用 GlitchTip，容器管理用 Portainer 或 Dockge。相比自托管 Sentry，GlitchTip 的部署要小得多，前者官方最低要求是 16 GB 内存外加 16 GB 交换空间。
- 文档： 文档用 Docmost，议题跟踪用 OpenProject（或 Plane）。AFFiNE 适合偏好画布式 Notion 模型的团队。
- 规格选型： 把 4 GB 当作跑几个轻量服务的实验规格，8 GB 当作去掉 OpenProject、Plane 和本地构建的精简试点，16 GB 则是本指南这套完整 Forgejo 技术栈的现实起点。GitLab 的 8 vCPU/16 GB 基准只针对 GitLab 本身，因此基于 GitLab 的单机技术栈需要额外容量或单独做负载测试。
- 短板在哪： 有外部贡献者的公开开源项目。GitHub 的网络效应是真实存在的，自托管会让你损失被发现的机会。
先决条件
在继续阅读之前，本指南假设：
- 一台装好 Docker 和 Docker Compose 的 Linux VPS。完整的 Forgejo 技术栈按 16 GB 内存来规划；若是去掉较重的项目管理工具和本地构建的精简试点，8 GB 就够用。
- 首次部署时，每一层需要投入 30 到 60 分钟。
- 能自如地阅读 Compose 文件并调整环境变量。
- 愿意维持固定的更新窗口、及时打上安全补丁，并且真去验证备份，而不是配置完就算了。
如果其中任何一条是你无法接受的，那么 SaaS 套餐确实才是适合你团队的答案。这是站得住脚的选择，不是失败。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 Linux 套餐第 1 层，代码：Forgejo、Gitea 或 GitLab CE
三个可行选项，落在资源与治理曲线上的三个不同位置。对 2026 年刚开始自托管的人来说，我们的建议是 首选 Forgejo.
Forgejo 是为小规模基础设施设计的，提供合并请求、议题跟踪、项目看板、维基、软件包仓库以及 Forgejo Actions。它的工作流采用类似 GitHub Actions 的格式，但兼容性并不完全；请测试流水线所依赖的每一个第三方 action。
只有当你已经依赖某个 Gitea 独有的功能，或者工具链被钉死在某个 Gitea 版本上时，才选 Gitea。代码本身并没有问题。Forgejo 的 官方对比 指出这次分叉源于 2022 年 10 月 Gitea 的域名和商标在未经社区同意的情况下被转让给一家营利公司；Forgejo 的 许可声明 记录了从 v9.0 起的版本采用 GPL v3+。
如果你想用一个产品同时搞定 git、CI/CD、容器镜像仓库和议题跟踪，并且负担得起它的资源门槛，那就选 GitLab CE。 GitLab 当前的配置要求 把 16 GB 内存和 8 vCPU 定为单节点基准；8 GB 是给内存受限环境的。Gitea 足够轻，一个小型私有实例大约 1 到 2 GB 内存就能跑起来，Forgejo 也差不多，但两者在生产环境的规格仍取决于仓库数量、runner 和并发用户数。
| 工具 | 起步资源 | 治理方 | 许可 | 内置 CI/CD | 何时选它 |
|---|---|---|---|---|---|
| Forgejo | 1-2 vCPU / 1-2 GB 内存（轻量使用估算） | 社区主导（Codeberg e.V.） | GPL v3+ (v9.0+) | Forgejo Actions；需测试兼容性 | 2026 年自托管新手的默认选择 |
| Gitea | 1-2 vCPU / 1-2 GB 内存（轻量使用估算） | 营利性（Gitea Ltd，自 2022 年 10 月起） | MIT | Gitea Actions；需测试兼容性 | 已有对 Gitea 的依赖，或工具链被钉死在特定版本 |
| GitLab CE | 8 vCPU / 16 GB RAM baseline; 8 GB constrained | GitLab Inc | MIT（Community Edition） | 原生，功能齐全 | 想用一个平台搞定 git、CI/CD、镜像仓库和议题，而且内存够用 |
CI 这一块值得单独点出来。Gitea Actions 的设计目标是与 GitHub Actions 大体兼容，而 Forgejo Actions 刻意追求的是熟悉感，而非完全兼容。多数工作流只需小改，但 runner 镜像、权限、上下文、标签和第三方 action 的行为可能不同。迁移前请测试流水线依赖的每一个工作流和 action。
有一条提醒适用于这三个选项。本指南假定的是私有和团队使用，管理界面藏在 VPN 或 IP 白名单之后。公开的 git 服务要面对机器人流量、滥用以及可发现性方面的取舍，而小型私有部署没有这些问题。对于公开的开源项目，可以镜像到 GitHub 以获得曝光，同时把 Forgejo 保留为事实来源，如果这种治理模式对你很重要的话。
按工作负载来定服务器规格，而不是按服务商的套餐名。轻量私用的独立 Forgejo 或 Gitea 服务，大约 1 到 2 vCPU、1 到 2 GB 内存就能起步。去掉 OpenProject、Plane 和本地构建的精简技术栈，大约 4 vCPU、8 GB 内存起步。本文描述的完整 Forgejo 技术栈，从约 8 vCPU、16 GB 内存起步，然后在真实的 CI 和应用负载下验证。GitLab 官方的 8 vCPU/16 GB 基准只针对 GitLab 本身，所以别把它当成 GitLab 加上本栈其余部分的够用配置。使用 SSD 或 NVMe 存储，为仓库、容器镜像、日志、数据库和备份分别留出预算，并保留 20% 到 30% 的余量应对更新和负载尖峰。
本节关键要点： 2026 年代码层的默认推荐是 Forgejo；Gitea 依旧稳健；而 GitLab CE 只有在你负担得起它 16 GB 的基准，或明知故犯地跑在 8 GB 受限配置上时，才是那个一体化选择。
第 2 层，构建与部署：Coolify（附带注意事项）、Dokku 或纯 Docker Compose
老实说：只要你跑的是最新的生产版本、把管理面板挡在公网之外、并且跟进安全公告，Coolify 就是这套技术栈推荐的 PaaS 方案。质检时，GitHub 把 Coolify v4.3.0 标为最新版。请把打补丁和管理面隔离当作运维要求，而不是可选的加固。
专业提示： 用防火墙、VPN 或可信访问代理限制 Coolify 的面板和 API。已部署的应用照样可以接收公网流量；目标是减少管理控制面的暴露面。
独立开发者的替代方案是 Dokku，一个小巧的 PaaS，支持 Heroku 式的 git push 部署和 buildpack。它的攻击面比 Coolify 小，功能集也相应更少。这让它对一两个不需要控制面板的开发者来说，是个站得住脚的“无聊选择”。
老练的运维者会选的第三条路是 干脆不用 PaaS，只用 Docker Compose。如果你的团队本来就在写 Compose 文件，而且你更喜欢让各个部件一目了然，那这完全是个合理的答案。当你想要点一下就重启，而不是敲 docker compose restart 时，可以加上 Dockge 或 Portainer 作为管理界面层。代价体现在运维上：没有预览环境，没有内置的 TLS 自动化，也没有不费功夫就能得到的零停机部署。这些能力要靠自己写脚本换来；在 Coolify 里它们是现成的，同时也附带了它的安全历史。
Cloudzy 的最佳 CI/CD 工具指南 更深入地讲了构建流水线，适合需要单独 runner 的团队；而一旦有了 Forgejo Actions 或 GitLab CI/CD，许多小团队其实并不需要。
本节关键要点： 只有在跑当前稳定版并且限制了管理面的前提下，Coolify 才是推荐的 PaaS；Dokku 是保守的单人选择；纯 Docker Compose 依然是站得住脚的第三选项。
第 3 层，运行：Vaultwarden、Uptime Kuma、GlitchTip 与容器管理
这套技术栈里资源差距最悬殊的地方就在这一层。 Sentry 官方的自托管配置要求 把最低要求列为 4 个 CPU 核心、16 GB 内存、16 GB 交换空间和 20 GB 可用磁盘，并推荐 32 GB 内存。 GlitchTip 的安装指南 推荐 512 MB 内存，必须有 PostgreSQL，Valkey 则是可选的。对于跑在单台 VPS 上的小团队，GlitchTip 是务实的默认选择。
| 工具 | 内存（典型） | 容器数量 | API 兼容性 |
|---|---|---|---|
| 自托管 Sentry | 16 GB RAM plus 16 GB swap minimum; 32 GB recommended | 多服务的大型部署 | 原生 |
| GlitchTip | 512 MB recommended; 256 MB minimum for the all-in-one setup | 2 个核心服务；Valkey 可选 | 接收 Sentry SDK 流量；需测试功能对等性 |
这一层剩下的四个工具，几句话就能说完。
Vaultwarden 是一款兼容 Bitwarden 的密码管理器，支持 Bitwarden 的手机应用和浏览器扩展，也支持团队共享。它实际占多少资源，取决于用户数、附件和所选数据库。 Cloudzy 的自托管密码管理器对比 更深入地讨论了当你需要更有层次的权限、审计控制或另一种安全模型时的取舍。
Uptime Kuma 是那个小巧的监控与告警工具：支持 HTTP、TCP、ping、push 和证书到期检查，还可选配状态页。通知可以走聊天、邮件或 webhook。资源占用随监控项数量和保留时长而变；设置成连续第二次失败才告警，是抑制短暂抖动的实用办法。
GlitchTip 是这里的错误追踪器。多数 Sentry SDK 集成都能上报到 GlitchTip 的 DSN，但功能并未完全对齐；请测试性能监控、source map、告警，以及任何被你们团队视为关键的集成。
容器界面可以选 Portainer 或 Dockge。Portainer 覆盖的容器管理场景更广，Dockge 则专注于 Docker Compose。对于只用 Compose 的小型技术栈，Dockge 更贴合。只有当你确实需要更大的覆盖面时，再转向 Portainer。
这一层有个好用的 Compose 习惯：每个工具放在各自的子目录里，配各自的 compose.yml；只在确实需要跨工具通信的地方共享 Docker 网络；前面放一个反向代理统一做 TLS 终止。
# /opt/stack/glitchtip/compose.yml (excerpt)
services:
web:
image: "glitchtip/glitchtip:${GLITCHTIP_VERSION:?Set GLITCHTIP_VERSION in .env}"
environment:
DATABASE_URL: "${DATABASE_URL:?Set DATABASE_URL in .env}"
SECRET_KEY: "${GLITCHTIP_SECRET_KEY:?Set GLITCHTIP_SECRET_KEY in .env}"
GLITCHTIP_DOMAIN: "https://errors.example.com"
DEFAULT_FROM_EMAIL: "[email protected]"
ports:
- "127.0.0.1:8000:8000"专业提示： 只有当服务能被还原、数据也经过校验，备份才算得到验证。每月一次，把一个有代表性的服务还原到隔离的测试环境里，启动它、登录进去、检查记录和附件，确认应用运行正常。列一遍还原出来的文件，只能证明压缩包可读，并不能证明数据库、数据卷、权限和应用状态都能成功恢复。
本节关键要点： GlitchTip 用比自托管 Sentry 小得多的部署，把错误追踪的核心工作办妥了；但要验证你们团队真正在用的那些 Sentry 功能和集成。
第 4 层，文档：Docmost、AFFiNE，以及用 OpenProject 或 Plane 做议题跟踪
Notion 的界面本来挺好，直到维基越长越大，让浏览和搜索都变得拖沓。对小团队，推荐的分工是：文档和维基用 Docmost，议题跟踪用 OpenProject。如果你的团队明确想要 Linear 那种视觉模型，并且愿意维护它受支持的自托管部署，就把 OpenProject 换成 Plane。
Docmost 是这里最接近 Notion 的自托管替代品，而且它并不假装自己就是 Notion。它的块编辑器、页面层级和团队权限，很适合传统的内部维基。这一层的规格按并发编辑人数、附件量，以及 PostgreSQL 和 Redis 是否同机来估。AFFiNE 则是给那些相比嵌套页面更喜欢画布和白板模型的团队的备选。两个都合理，挑一个就行。
OpenProject 面向习惯 Jira 风格工作流的团队，把议题跟踪这块承担下来：史诗、工作包、冲刺和工时记录一应俱全。Plane 则是 Linear 形态的备选，界面更快、更以议题为中心，运维负担也不一样。
老实承认：Linear 那种键盘优先的速度确实好，而 Plane 并没有把每一处交互都复刻下来。如果你们团队的工作流建立在 Linear 命令菜单的肌肉记忆之上，迁移的摩擦是真实存在的。这未必是致命障碍，但确实是一笔实打实的代价。
本节关键要点： Docmost 承担内部文档这一角色，议题跟踪则交给 OpenProject 或 Plane；与 Linear 之间的键盘体验差距，是这一层唯一要你妥协的地方。
这套技术栈要花多少钱，又跑在什么上面
把完整的 Forgejo 技术栈塞进一台机器，现实的起点大约是 8 vCPU 和 16 GB 内存。把 2 vCPU 加 4 GB 内存当作跑几个轻量服务的实验规格，把 4 vCPU 加 8 GB 内存当作去掉 OpenProject、Plane 和本地构建的精简试点。真实需求取决于并发用户、CI 活动量、数据库增长、附件、镜像存储、日志和保留策略，所以要在真实负载下验证，并保留 20% 到 30% 的余量。在做过负载测试的前提下，16 GB 这一档起步配置可以为一个负载较轻的 2 到 3 人开发团队容纳下列服务：
- Forgejo
- Coolify
- Vaultwarden
- Uptime Kuma
- GlitchTip
- Docmost
- OpenProject
- Dockge
4 GB 的服务器只适合跑几个轻量服务。8 GB 的机器更适合当作去掉 OpenProject、Plane 和本地构建的精简试点。完整的 Forgejo 技术栈从 16 GB 起步，一旦要跑 GitLab、并发构建、Plane、更长的保留期或更重的数据库负载，就加配置。同一个团队的 SaaS 套餐包含：
- GitHub Team
- Vercel Pro
- Sentry
- Linear
- Notion
- 1Password
以各家定价页面上公布的基础价为准（在适用处采用年付价格）。五个计费产品加起来，三个人每月约 158 美元： GitHub Team 首 12 个月每用户 4 美元； Vercel Pro 的开发者席位三个，每个 20 美元； Sentry Team 起价 26 美元； Linear Basic 每用户 10 美元；以及 Notion Plus 每用户 10 美元。用量费用、税费、附加项和 1Password 都要另算。基础设施确实还是可能便宜不少，但不把运维者的时间算进去，这个比较就没有意义。
什么时候该加配置：GitLab 的单节点基准是 8 vCPU 和 16 GB 内存。就算不上 GitLab，多个并发构建也可能需要额外容量。自托管 Sentry 同样从 16 GB 内存加 16 GB 交换空间起步，并推荐 32 GB，这正是本指南在单机技术栈里推荐 GlitchTip 的原因。
没有标价的那部分成本，是运维时间。做规划时，按每月 1 到 2 小时来预留更新和备份验证的时间，再加上每周花一点时间扫一遍你所运行项目的安全公告。真实数字取决于变更量、故障响应，以及你把多少事情自动化了。它不是零，理应写进成本模型里。
部署方式改变的是便利程度，不是运维要求。无论你用官方 Compose 文件还是应用市场模板，都要钉住镜像版本、设置 CPU 和内存上限、把服务数据放进具名卷，并且备份和恢复都要测。把整套技术栈塞进一台主机，也意味着它们共享同一个故障域，所以当停机或凭据泄露的影响很大时，请把关键服务隔离出来。
如果你想部署这套技术栈，可以按 CPU、内存、SSD 或 NVMe 存储、流量额度和地区，比较我们的 cloud VPS 套餐，然后套用上面那套配置估算方法。想更快搭起来，可以逛逛我们的 一键应用目录，但仍然要钉住版本、设置资源上限，并在上生产之前验证备份。
本节关键要点： 小实验用 4 GB，精简试点用 8 GB，完整的 Forgejo 技术栈则以约 8 vCPU 加 16 GB 内存作为现实起点。要跑 GitLab、并发构建、更重的项目管理工具和不断变大的数据库时，再加配置。
自托管这套技术栈真正失灵的地方
四种失效方式，直说不绕弯，因为这份指南的其余部分一直在为这条路子辩护。
失效方式 1：公开开源项目上的 GitHub 网络效应。 对私有代码来说，自托管 git 是对的。但对那些全部价值都系于外部贡献者能否找到你的项目，它就是错的。开发者第一眼看的地方就是 GitHub。合并请求、fork、星标、身处 github.com 所自带的那份隐性信任信号、第三方工具集成，全都是。如果你的项目是公开开源，诚实的做法是镜像到 GitHub 换取曝光，同时把事实来源留在 Forgejo。别指望一个自托管实例能替代 GitHub 在公开工作上的可发现性。它做不到。
失效方式 2：公开 Git 实例上的机器人和抓取流量。 面向公网的 Forgejo 和 Gitea 服务需要反滥用手段、速率限制、监控，以及足以吃下不可预测流量的容量。本指南假定的是私有和团队使用，管理界面藏在 VPN 或 IP 白名单之后。一个真正公开的代码托管站，威胁模型和容量模型都不一样。
失效方式 3：维护负担。 “你就是 IT 部门”是句老话，而且基本属实。更新会弄坏东西。Compose 文件会慢慢跑偏。证书会过期。备份会以最不体面的方式悄无声息地失败。Coolify 在 2026 年发布的那些安全公告，正好提醒我们打补丁的节奏很重要。如果你没法在动手之前就承诺一个维护窗口，那说实话，SaaS 套餐才是对的答案。
失效方式 4：集成的流失。 第三方 GitHub Action、绑定 GitHub PR 的 Vercel 预览部署、Sentry 托管的 PagerDuty 与 Linear 告警集成、Notion 那份庞大的集成目录。多数都有自托管的对应物（Forgejo Actions、Coolify 的 webhook 部署、GlitchTip 通知、用 n8n 把流程粘起来），但替代并不总是一比一。在把团队绑上迁移这条船之前，先给最要紧的那条工作流做个原型。你最习以为常的那个集成，往往就是最会给你惊喜的那个。
本节关键要点： 这套技术栈适合私有代码、小团队和愿意动手的运维者；它不适合公开开源项目的曝光度、不愿沾手的团队，也不适合零维护的期待。
运维者的技术栈
四层，四条建议，直说不绕。代码：Forgejo。构建与部署：限制了管理面的 Coolify，或 Dokku，或 Compose。运行：Vaultwarden、Uptime Kuma、GlitchTip、Portainer 或 Dockge。文档：Docmost 加 OpenProject（或 Plane）。精简试点从 8 GB 起步，完整的 Forgejo 技术栈从 16 GB 起步。遇到 GitLab、并发构建、更重的数据库或持续的应用负载，就加配置。
如果你要迁移，先从 Uptime Kuma 和一个不关键的内部服务开始。它们能让你以更低的风险摸熟运维节奏（更新、监控、备份验证和证书续期），再去动团队工作流或凭据库。别把 Vaultwarden 当作第一个试水的部署：等到异地加密备份、一次成功的恢复演练、受限的管理权限和多因素认证都到位之后，再迁它。等这套节奏稳了，再搬 Forgejo，然后是 Coolify，然后才是其余部分。
对于专门选了 GitLab CE 的团队，请判断它自带的 CI/CD 是否足以取代独立 runner，还是你的工作负载仍然需要专门的构建资源。
常见问题
2026 年 Gitea 最好的自托管替代品是什么？
对 2026 年刚开始自托管的人来说，推荐的选择是 Forgejo。2022 年 10 月 Gitea 的商标和域名在未经社区事先同意的情况下转让给一家营利公司，正是这件事在 2022 年底催生了 Forgejo 这次分叉。从 v9.0 起，Forgejo 的发行版采用 GPL v3+；更早的 v8.0 和 v7.0 补丁版本仍然是 MIT。就日常功能而言，两者相当接近。
2026 年能安全地把 Coolify 跑在生产环境吗？
可以，但前提是持续维护加纵深防御。跑经过审阅的最新稳定版，盯住新公告，收紧团队权限，把面板和 API 挡在防火墙、VPN 或可信访问层之后。不要把 beta.451、beta.474 或任何历史补丁版本当成永久安全的分界线。
一套完整的自托管开发者技术栈到底需要多少内存？
对 2 到 3 人的开发团队来说，把 4 GB 当作跑几个轻量服务的实验规格，把 8 GB 当作去掉 OpenProject、Plane 和本地构建的精简试点。完整的 Forgejo 技术栈，现实起点约为 8 vCPU 和 16 GB 内存。GitLab 的 8 vCPU/16 GB 基准只针对 GitLab 本身，而自托管 Sentry 要求 16 GB 内存加 16 GB 交换空间，并推荐 32 GB。最终配置要在真实负载条件下验证。
为什么选 GlitchTip 而不是自托管 Sentry？
差在资源和运维上。自托管 Sentry 至少要 16 GB 内存加 16 GB 交换空间，而且是个多服务的大型部署。GlitchTip 的一体化服务推荐 512 MB，必须有 PostgreSQL，Valkey 可选。它能接收 Sentry SDK 的流量，但功能并未完全对齐，所以要测试你所依赖的那些功能和集成。
跟对应的 SaaS 相比，这套技术栈实际要花多少钱？
把 4 GB 当作跑几个轻量服务的实验规格，把 8 GB 当作去掉 OpenProject、Plane 和本地构建的精简试点。完整的 Forgejo 技术栈，现实起点约为 8 vCPU 和 16 GB 内存。按公布的基础价，GitHub Team、Vercel Pro、Sentry Team、Linear Basic 和 Notion Plus 加起来，三个人每月约 158 美元，还不含 1Password、用量费用、税费和附加项。自托管确实可能便宜不少，但运维者的时间和备份基础设施都是实打实的成本。
