为何从GitHub迁移到Forgejo有人把代码从GitHub迁移到了自建的Forgejo上这并非因为GitHub的服务中断问题而是因为其背后的所有权和控制权。荷兰政府也做出了相同的选择。2026年4月27日荷兰内政部软启动了[code.overheid.nl](https://www.nldigitalgovernment.nl/news/soft-launch-for-government-open-source-code-platform/)这是一个用于存放荷兰政府源代码的自建Forgejo实例。项目经理鲍里斯·范·霍伊特马Boris Van Hoytema表示该平台“源于内政部必须在自己拥有的平台上合法发布源代码的要求”并且选择Forgejo而非GitLab是因为它完全开源能提供实现[数字自主](https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/dutch-alternative-sharing-public-code)所需的所有自由。就在前一周有人也悄悄将自己的代码进行了同样的迁移。现在其主要Git托管平台是[code.jorijn.com](https://code.jorijn.com)它在一台经过加固设置的NUC上运行Forgejo v15 LTS。部分仓库已经迁移过去其余的也在排队等待。长期计划是在迁移完成后将在GitHub上的公共仓库存档并将每个存档指向新的地址。大多数关于离开GitHub的文章都会首先提及服务中断问题。服务中断确实存在但这并非离开的原因。服务中断、默认开启的AI功能以及GitHub不再有独立的CEO这些都是一个根本问题的表现并不拥有这个平台。荷兰政府也得出了相同的结论。接下来将详细阐述思考过程以及做出迁移决定后实际的操作情况。总结2025年5月至2026年4月期间GitHub共发生257起事件其中48起为重大事件。CTO公开道歉并表示需要将容量扩大30倍才能应对AI驱动的负载。2025年8月GitHub不再有独立的CEO现在它是微软CoreAI部门的一部分该部门负责构建Copilot和更广泛的AI堆栈。2026年4月24日起GitHub默认将Copilot免费版、专业版和专业增强版用户的交互数据用于AI训练且无法在仓库级别进行选择。《外国情报监视法》FISA第702条和《云法案》CLOUD Act带来的美国司法管辖区风险尚未解决。微软的律师在法国参议院听证会上宣誓表示无法保证欧盟数据不会被美国政府秘密访问。2026年4月荷兰政府出于同样的原因选择Forgejo搭建code.overheid.nl。有人也为自己的工作做出了相同的选择。code.jorijn.com在一台NUC上运行Forgejo v15 LTS并配备一个通过KVM隔离、每周重建的Actions运行器。迁移完成后GitHub上的公共仓库将被存档并指向新的地址。为何服务中断并非真正原因2026年4月的服务中断让工程师们十分恼火。4月23日[合并队列的squash - merge代码路径](https://www.theregister.com/2026/04/29/github_says_sorry_and_says/)在一个功能标志未完全推出后默默地恢复了658个仓库和2092个拉取请求中之前合并的提交。包括Modal和Zipline在内的公司不得不进行手动数据恢复。四天后过载的Elasticsearch集群导致拉取请求、问题和软件包离线超过六个小时。但随便选一个月来看情况都同样糟糕。仅2026年2月就记录了37起事件其中一次长达3小时40分钟的中断使Actions、Copilot编码代理、代码审查、CodeQL、Dependabot和Pages同时下线。2025年10月1日macOS运行器中断了十个小时。根据IncidentHub的汇总2025年5月至2026年4月期间GitHub共发生[257起事件和48起重大中断](https://blog.incidenthub.cloud/github-reliability-outage-history-2025-2026)总停机时间约为112小时。正确看待这些事件的方式并非认为“GitHub不可靠”。大型系统难免会出现故障。正确的理解应该参考GitHub自己的说法。CTO[弗拉德·费多罗夫Vlad Fedorov](https://github.blog/news-insights/company-news/an-update-on-github-availability/)在4月28日道歉并表示为了应对负载容量必须扩大30倍。他将负载的增加直接归因于自2025年12月以来“智能AI工作流的增长”。服务可靠性问题是AI发展带来的结果。GitHub并没有放缓AI功能的开发反而在加大投入。服务中断就是这种投入在实际运行中的表现。《务实工程师》The Pragmatic Engineer指出[GitLab、Bitbucket、Vercel、Linear和Sentry在这一年并没有出现类似的问题](https://newsletter.pragmaticengineer.com/p/the-pulse-ai-load-breaks-github-why)。它们在相同的总体需求压力下为开发者提供服务。GitHub所面临的问题是其特有的。GitHub不再有独立的CEO更重要的事实其实更早发生但却很少受到关注。2025年8月11日[托马斯·多姆克Thomas Dohmke](https://github.blog/news-insights/company-news/goodbye-github/)辞去了GitHub CEO的职务。微软没有任命新的CEO而是将GitHub[并入了微软的CoreAI部门](https://www.geekwire.com/2025/github-will-join-microsofts-coreai-group-with-departure-of-ceo-thomas-dohmke/)。这个部门是[萨蒂亚·纳德拉Satya Nadella](https://blogs.microsoft.com/blog/2025/01/13/introducing-core-ai-platform-and-tools/)在2025年1月设立的其使命是为第一方和第三方客户构建端到端的Copilot和AI堆栈。如今GitHub的收入、工程和支持团队都向微软开发者部门的朱莉娅·柳森Julia Liuson汇报。GitHub的首席产品官向微软AI平台副总裁汇报。虽然GitHub品牌仍然存在但独立的领导体系已不复存在。这很重要因为过去选择留在GitHub的一个理由是微软对其保持一定的距离。从2018年到2024年这确实是事实。多姆克拥有实际的决策权产品决策明显是由GitHub做出而非微软。但自2025年8月之后这个理由就不再成立。如今当你将代码推送到github.com时实际上是推送到了微软AI组织的一个部门。这是否会让你担忧取决于你对微软AI组织能否像过去的GitHub那样为你的仓库做出决策的信任程度。有人已经不再信任而这种不信任的原因将在下一部分体现。训练数据默认设置的改变2026年3月25日GitHub[宣布对隐私声明进行更改](https://github.blog/changelog/2026-03-25-updates-to-our-privacy-statement-and-terms-of-service-how-we-use-your-data/)该更改于4月24日生效。从这一天起“Copilot免费版、专业版和专业增强版用户的交互数据包括输入、输出、代码片段和相关上下文将被用于训练和改进我们的AI模型除非用户选择退出”。关于这一声明有三点值得关注。首先是选择退出而非选择加入。默认设置发生了改变。任何使用Copilot免费版、专业版或专业增强版的用户除非前往Copilot设置页面关闭该功能否则都将为模型训练做出贡献。其次没有仓库级别的开关。作为仓库维护者无法告诉GitHub“不要在我的仓库内的交互数据上进行训练”。选择退出是基于用户账户的因此每个贡献者都必须自行做出选择。实际上无论代码库采用何种许可方式只要有使用Copilot免费版、专业版或专业增强版的用户接触到它代码库就会成为训练材料。第三对私有仓库的例外情况比听起来更有限。GitHub表示不会将私有仓库“静态”的内容用于训练但会收集在私有仓库中使用Copilot时生成的“代码片段和交互上下文”。“静态代码”和“编辑时生成的代码片段”之间的界限可以说是相当模糊。Copilot Business和Copilot Enterprise的客户不受此影响因为他们受单独的数据保护协议约束。界限很明确支付足够的费用你的交互数据就不会被用作训练数据否则就会被使用。几周前有人写过一篇关于[智能GitHub Actions](https://jorijn.com/en/blog/github-actions-agentic-workflows-natural-language-cicd/)的文章当时安全模型是重点。训练数据默认设置的改变是同一个故事的后半部分GitHub对用户交互数据的战略兴趣现在是结构性的而非可选项。有人不想在别人的平台上争论这种策略的优劣更愿意离开这个平台。司法管辖区问题在所有这些问题之下有一个层面不会随着隐私声明的改变而改变。GitHub公司和微软公司都是美国公司它们所拥有的任何数据都受美国法律管辖包括[《外国情报监视法》第702条](https://www.congress.gov/crs-product/R48592)和[2018年《云法案》](https://natlawreview.com/article/beyond-server-location-why-new-fight-over-fisa-702-and-cloud-act-matters-corporate)。无论数据实际存储在哪里这两部法律都适用。《外国情报监视法》第702条在2024年4月获得了为期两年的重新授权目前正在根据2026年4月底签署的[45天延期协议](https://www.cnbc.com/2026/04/30/fisa-section-702-congress-extension.html)运行同时国会正在就长期续签进行争论。该条款授权美国情报机构通过位于美国的电子通信服务提供商收集非美国公民的信息。《云法案》则允许美国执法部门要求总部位于美国的公司提供存储在世界任何地方的数据。GitHub在2024年10月宣布[企业云服务实现欧盟数据驻留](https://github.blog/changelog/2024-10-29-github-enterprise-cloud-data-residency-in-the-eu-is-generally-available/)。这解决了数据存储位置的问题但没有解决司法管辖区的问题。《云法案》的影响取决于公司的控制权而非地理位置。最坦诚的表述并非来自监管机构而是微软自己的律师。他在2025年6月的法国参议院听证会上宣誓表示[无法保证存储在欧洲微软数据中心的法国数据不会被美国政府秘密访问](https://techcrunch.com/2026/04/27/whats-behind-europes-efforts-to-ditch-u-s-software-in-favor-of-sovereign-tech/)。有人在之前的文章[《为何“托管在法兰克福”并不意味着符合GDPR》](https://jorijn.com/en/blog/eu-data-sovereignty-hosted-in-frankfurt-not-gdpr-compliant/)中探讨过更广泛的法律问题在[《关于NIS2指令对托管服务提供商及其客户的影响》](https://jorijn.com/en/blog/nis2-directive-for-hosting-providers-and-their-clients/)中讨论过对托管服务提供商的运营影响因此这里不再赘述细节。关键在于只要你的代码存放在github.com上就处于美国法律的管辖范围内。欧盟数据驻留只是一种安慰并不能真正解决问题。荷兰政府的选择code.overheid.nl荷兰政府的选择值得更多关注。其法律驱动因素是荷兰自2020年起实施的 “[Open, tenzij](https://fsfe.org/news/2020/news-20200424-01.en.html)” 政策用公共资金开发的软件默认是开源的除非有安全或保密方面的要求。为了遵守这一政策内政部需要一个能实际控制的平台来发布代码。code.overheid.nl就是答案。值得注意的是他们选择的代码托管平台。欧盟委员会自2022年9月起就在[code.europa.eu上运行自建的GitLab](https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/ecs-codeeuropaeu-launches)。德国的[openCode](https://opencode.de/en)也是基于GitLab。法国的[code.gouv.fr](https://code.gouv.fr/fr/)是一个聚合器用于索引托管在其他地方的仓库本身并不是一个代码托管平台。荷兰政府选择Forgejo而非GitLab是经过深思熟虑的。正如OSOR文章所述原因在于Forgejo完全开源没有开源核心和商业版本的区分能提供实现数字自主所需的所有自由。范·霍伊特马还补充说Forgejo的路线图与他们的需求“更加契合”。荷兰政府不仅想要一个自主的代码托管平台还希望这个平台不会被商业供应商的高级版本所限制。这种机构层面的选择很重要一个拥有专业律师和丰富经验的国家政府看到了和作者相同的情况做出了相同的决定并在作者之前一周实施。这并不能证明这个决定是正确的但至少说明这个决定不再是少数人的选择。为何选择Forgejo而非GitLab有人认真考虑过GitLab。自建的GitLab CE是一个成熟的选择拥有更庞大的商业生态系统而且用户界面也更加完善。但有两个因素让作者最终选择了Forgejo。首先是许可证问题。GitLab采用开源核心模式社区版遵循MIT许可证但许多在实际生产中需要的功能都在企业版中且采用非免费许可证。而Forgejo则不同。自[2024年8月的v9.0版本](https://forgejo.org/2024-08-gpl/)起该项目将许可证从MIT改为GPLv3明确目标是保持共享版权防止代码库被未来的商业行为控制。2022年12月[从Gitea分叉出来](https://blog.codeberg.org/codeberg-launches-forgejo.html)正是因为Gitea有限公司以社区未同意的方式控制了商标和域名。这个教训体现在了许可证上。其次是治理问题。Forgejo由[Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/)管理这是一个自2018年9月起在柏林注册的非营利组织拥有成员选举产生的董事会、公开的预算其托管实例上有超过30万个仓库。成员每年对预算进行投票2025年的预算计划以88票赞成、0票反对、1票弃权获得通过。这不是关于社区治理的营销说辞而是一个德国社团在切实履行职责。[Forgejo v15.0 LTS于2026年4月16日发布](https://forgejo.org/2026-04-release-v15-0/)这是该项目的第100个版本。长期支持将持续到2027年7月15日。Forgejo Actions在v15版本中达到了作者所需的成熟度临时运行器、OpenID Connect、可复用工作流扩展。分叉后的版本发布一直很稳定每月都有活跃的报告。需要坦诚指出的是Forgejo的商业生态系统虽然存在但还不够完善。目前最成熟的商业服务是[VSHN推出的Codey](https://www.codey.ch/)这是一个瑞士托管的Forgejo服务每月收费19瑞士法郎于2025年3月在Servala上推出。没有类似红帽的企业支持订阅服务。如果你需要24/7的电话支持和明确的供应商责任可能需要自己搭建或者等待。作者愿意等待因为更希望拥有对平台的控制权。搭建方案及原因code.jorijn.com运行在作者家庭办公室的一台配备64GB内存的英特尔NUC上。Forgejo v15 LTS、Postgres 17和Traefik都运行在Docker容器中。一个由Incus管理的KVM虚拟机与它们并行运行作为Forgejo Actions运行器。这就是整个平台的架构。有趣的决策不在于Forgejo的部署因为Forgejo加上Postgres再加上反向代理并不是什么新鲜事。最需要思考的决策在于运行器。真正的风险所在如果你自建代码托管平台平台本身其实是比较容易搭建的部分。困难的部分在于运行CI作业的部分。作者的运行器需要按照Renovate的每日计划执行npm install、composer install和pip install针对自己仓库生成的锁定文件。这意味着它要执行生命周期脚本也就意味着每个作业都有可能运行不可信的代码就像最近npm蠕虫和axios供应链攻击利用依赖机器人在一小时内自动合并代码那样。换句话说运行器的任务不是运行代码而是在代码运行时对其进行隔离。运行器架构的所有设计都是为了这个目的。作者在[《关于未维护依赖的隐藏风险》](https://jorijn.com/en/blog/unmaintained-dependencies-hidden-risk/)中描述的逻辑同样适用于这里假设任何一层都可能出现故障设计时要确保下一层能够吸收故障。防御措施从弱到强运行器采用了五层防御措施从最薄弱到最强依次如下1. **持久的KVM虚拟机**运行器运行在自己的虚拟机中而不是主机上的容器里。主机的内核不会与作业环境共享。运行器内部的Linux内核漏洞必须突破KVM边界才能影响到NUC。2. **gVisor作为虚拟机内的默认Docker运行时**作业容器在runsc下运行它在用户空间拦截系统调用而不是将其传递给主机内核。容器逃逸必须同时突破gVisor和周围的KVM才能造成影响。3. **每周进行破坏性重建**每周一UTC时间02:00整个虚拟机将被销毁并从新烘焙的Ubuntu基础镜像重新创建同时为Forgejo生成新的持久运行器注册信息。基础镜像本身在周日重建因此新的虚拟机将使用本周的apt和内核补丁。持久状态的保存时间不能超过七天。4. **运行器网桥的nftables出口过滤器**运行器可以访问公共目的地的:443、:80、:22和:53端口如npm、pypi、ghcr以及通过路由器的Hairpin NAT以公共主机名访问自己的Forgejo。但它无法访问192.168.0.0/16、10.0.0.0/8或172.16.0.0/12。受攻击的作业无法扫描局域网无法访问路由器管理界面也无法访问主机的其他服务。5. **作用域受限的运行器令牌无管理员权限**两个持久的运行器注册信息分别绑定到单个用户作用域和单个组织作用域具有write:user、write:organization的个人访问令牌PAT权限用于管理。泄露的令牌无法在其作用域之外注册运行器更无法执行任何管理员权限的操作。这些防御措施是有意重叠的。每一层都是一道防线它们共同构成了一个有深度的防护边界。这些措施本身并不是什么创新因为所有的基础技术都有上游文档且广为人知。新的地方在于将它们组合起来应用于一个单用户的家庭实验室整个平台可以在一台NUC上运行并且在出现问题时能够干净地恢复。底层的基础技术如KVM隔离、gVisor、每周重建和作用域受限的运行器注册都是Forgejo和Incus原生支持的。作者只需要将它们组合起来即可。放弃了什么这部分是作者必须写的因为尊重的每一篇“权衡利弊”的文章都会有这一部分。那么诚实地说迁移到Forgejo让作者失去了什么呢**发现功能和社交图谱**GitHub是作者的贡献者找到作者的地方。当有人向公共仓库推送小的修复时他们通常希望在github.com上进行而不是在一个他们从未听说过的域名上。作者的计划是在迁移完成后将每个公共GitHub仓库存档并在其README中指向code.jorijn.com。这样发现路径仍然保持完整人们仍然可以通过GitHub找到作者看到存档通知然后跟随链接到新的地址。目前还没有完全完成迁移一些仓库已经迁移到code.jorijn.com其余的还在排队。在此之前这个差距是真实存在的作者接受这一点。**GitHub Actions生态系统的脆弱性**Forgejo Actions有意追求“熟悉感而非兼容性”。大多数功能都能正常工作但也有一些不行。工作流级别的permissions:块会被默默忽略。2026年初actions/checkoutv6在非GitHub运行器上无法进行认证签出所以作者将所有版本固定为v5。actions/upload-artifactv4需要使用Forgejo托管的分叉版本。OpenID Connect可以正常工作但使用的工作流键 (enable - openid - connect: true) 与GitHub的permissions: id - token: write不同。这些都不是无法解决的问题但会带来一些摩擦。如果你的工作流严重依赖GitHub特定的功能迁移将是一个项目而不是一个晚上就能完成的事情。**Dependabot**Forgejo没有这个功能。作者在同一个自建运行器上以3小时为周期运行[Renovate](https://docs.renovatebot.com/)它能完成相同的任务但配置更复杂。设置花了作者一天时间。**24/7供应商支持**GitHub Enterprise提供电话号码和服务级别协议SLA。Forgejo则只有问题跟踪器和聊天室。对于个人开发者来说这没问题但对于一个有200名工程师的组织来说可能就不够了这也是一个需要考虑的因素。何时不值得迁移如果以下任何一种情况成立不建议迁移到自建的Forgejo- 团队没有意愿或能力运行基础设施。托管的Forgejo服务如Codey或面向开源项目的Codeberg可以弥补大部分差距但仍然需要承担迁移成本。- 严重依赖GitHub特定的功能如GitHub应用市场、Codespaces、Copilot Workspace、高级安全功能等。Forgejo是一个代码托管平台而不是开发者平台即服务。- 贡献者群体主要依赖GitHub的社交图谱。如果可发现性比控制权更重要那么留在贡献者所在的平台。或者接受迁移带来的摩擦在迁移完成后将公共仓库存档并指向新的地址之后再重新评估。- 没有可靠的运行器运营方案。运行器是关键部分。如果没有准备好考虑KVM隔离、gVisor、nftables和每周重建等问题那么可以选择使用托管的运行器主机或者继续留在GitHub。荷兰政府的做法也是一个很好的参考。他们并没有一步到位迁移所有内容。code.overheid.nl是一个用于各部门共享开源代码的软启动平台而不是对他们使用的所有其他工具的全面替代。作者的设置也是类似的Forgejo是作者工作的主要平台GitHub作为镜像作者愿意在之后重新评估镜像的设置。关键要点- GitHub不再是一个拥有独立CEO的公司。自2025年8月起它成为了微软CoreAI部门的一部分。- 2026年4月的服务中断和Copilot训练数据默认设置的改变都是同一转变的结果。从架构上看这都是可预见的。- 《外国情报监视法》第702条和《云法案》带来的美国司法管辖区风险是真实存在的且从客户角度无法解决。欧盟数据驻留只是一种安慰不能真正解决问题。- 2026年4月荷兰政府出于同样的原因选择Forgejo搭建code.overheid.nl。这种机构层面的选择趋势正在形成。- 在一台NUC上搭建一个可靠的自建Forgejo部署是可行的但运行器部分需要特别关注包括KVM隔离、gVisor、每周重建、作用域受限的令牌和阻止访问局域网的出口过滤器。- 迁移过程中会有摩擦。将公共GitHub仓库存档并指向新的地址可以在迁移过程中保持发现路径的完整性。服务器或部署问题反复出现可以帮助团队通过CI/CD、Kubernetes和云技术确保生产环境的可靠性让修复措施得以持续让部署不再令人头疼。[了解DevOps咨询服务](https://jorijn.com/en/services/devops-consultancy/)相关文章1. [2026年4月30日copy.failCVE - 2026 - 31431一个影响范围异常大的Linux内核小漏洞](https://jorijn.com/en/blog/copy-fail-cve-2026-31431-linux-kernel-bug-explained/)copy.fail是2026年4月29日披露的一个Linux内核本地权限提升漏洞。它几乎可以在所有现代发行版上运行不会在磁盘上留下痕迹还能绕过Kubernetes的默认seccomp机制。本文将解释其重要性以及应对方法。1631字2. [2026年4月29日HashiCorp Vault与OpenBao的全面比较为平台团队提供参考](https://jorijn.com/en/blog/hashicorp-vault-vs-openbao/)两款密钥管理器拥有相同的代码库但采用了截然不同的许可证。本文为平台工程师提供了HashiCorp Vault和OpenBao的深入实用比较帮助他们做出选择。4605字3. [2026年4月19日2026年OpenTofu与Terraform的分道扬镳](https://jorijn.com/en/blog/opentofu-vs-terraform-2026-the-fork-finally-diverged/)分叉三年后OpenTofu和Terraform在许可证、治理和技术特性方面出现了差异。对于评估基础设施即代码策略的欧盟团队来说选择不再是理论上的问题。1950字页脚信息- [主页](https://jorijn.com/en/)- [关于](https://jorijn.com/en/about/)- [工作与成果](https://jorijn.com/en/work-and-results/)- [博客](https://jorijn.com/en/blog/)- [DevOps咨询服务](https://jorijn.com/en/services/devops-consultancy/)- [网页开发](https://jorijn.com/en/services/web-development/)- [WordPress维护](https://jorijn.com/en/services/wordpress-maintenance/)- [电子邮件托管](https://jorijn.com/en/services/email-hosting/)- [知识库](https://jorijn.com/en/knowledge-base/)- [常见问题解答](https://jorijn.com/en/frequently-asked-questions/)- [隐私声明](https://jorijn.com/en/privacy-statement/)- [联系我们](https://jorijn.com/en/contact/)- [31 6 16 66 64 81](tel:31616666481)- [jorijnjorijn.com](mailto:jorijnjorijn.com)- [GitHub](https://github.com/jorijn)- [LinkedIn](https://www.linkedin.com/in/jorijnschrijvershof/)- [Arbory for Plausible](https://arbory.io)- [下载简历](https://jorijn.com/static/documents/CV.pdf)- 商会注册号54726956- 增值税号NL002200178B51搜索本网站开始输入进行搜索或者浏览知识库和博客。[查看所有结果 →](https://jorijn.com/en/search/)- [CoC]商会Chamber of Commerce- [VAT]增值税Value - added tax