选择协作层
Forgejo 和 Gitea 是轻量级 forge 软件的示例；对于较小的工作流，纯 SSH Git 可能就足够了。将问题跟踪、评审、包存储和身份需求与项目相匹配。核实当前支持的版本和许可证。
将构建与代码托管分离
CI 运行器执行项目控制的代码，不应持有不受限制的代码托管平台或主机凭据。隔离运行器、限定令牌范围，避免在与仓库服务相同的特权账户上运行不受信任的任务。
保护访问与注册
当服务为私有时，禁用公开注册。使用个人账户、强身份验证和范围严格限定的部署密钥。记录 SSH 端口和主机密钥；不要默默训练用户忽略主机密钥警告。
备份完整服务
仅仓库可能不包含问题、账户、附件和配置。遵循代码托管平台的统一备份流程，并在文件权限和应用密钥完好的情况下测试恢复。
锻造恢复检查清单
一致地导出数据库，并保留仓库存储、附件、大文件存储（如启用）、配置和加密密钥。恢复后通过预期的 SSH 或 HTTPS 路由验证克隆。将代码托管平台和任何 CI 工作进程隔离，以免构建过程改写服务自身的配置。
保持部署权限范围狭窄
对于只拉取代码的服务器，只读部署密钥可能就足够了。发布自动化可能需要少量额外权限范围。为不同机器使用独立密钥，记录其用途，并在机器退役时移除。
使用最合适的协作服务
对于少量私有仓库，通过受限 SSH 的裸 Git 可能已足够。Forgejo 或 Gitea 增加了账户、拉取请求、问题和可选包，代价是数据库、应用更新和更多持久状态。记录团队实际会使用的功能。分别预算仓库增长、大文件对象、附件和构建产物；CI 计算可能超过 forge 本身。
- 选择一个规范的 HTTPS 名称并保护其 DNS 账户。
- 决定注册是关闭、邀请制还是审核制。
- 为 forge 服务分配非特权身份和持久私有存储。
官方文档：Forgejo 容器安装
分离 Web、SSH 和数据库路径
使用所选版本的上游配置，并固定预期的镜像版本。TLS 反向代理应能访问内部 Web 监听器；数据库应仅可由 forge 访问。如果 Git SSH 使用容器端口，请保持其对外公布的主机和外部端口与映射一致。更改 forge 时，不要替换或意外暴露主机管理员 SSH 监听器。创建初始所有者后，关闭安装/设置访问权限。
- 启动应用前检查持久卷所有权。
- 使用仅限于 forge 数据库的数据库用户。
- 将 CI 运行器置于单独的信任边界，尤其是针对不受信任的仓库。
验证克隆、推送和被拒绝的操作
创建一个一次性私有仓库，并使用普通开发者账户测试其 HTTPS 或 SSH 克隆 URL。提交并推送一个无害文件，然后验证另一位获授权的读取者能够获取它。未受邀账户必须无法读取该私有仓库。检查大文件处理和通知邮件（如已启用）。对于仅用于部署的机器，测试只读密钥能够获取但不能推送；仅认证成功并不能证明预期的权限边界。
# Use the disposable repository URL advertised by your forge:
git clone ssh://[email protected]:2222/team/check.git
# In a clone, inspect which remote is configured:
git remote -v恢复讨论以及代码仓库
进行一致的应用/数据库备份、仓库存储、附件、LFS 数据、配置和所需的加密密钥。遵循已安装 forge 版本的备份流程；Gitea 备份命令并非自动与每个 Forgejo 版本通用。在隔离环境中重建并验证问题、附件、登录和克隆。如果迁移后推送失败，请先检查 SSH 主机/端口、密钥映射、存储权限和公布的克隆 URL，然后再全局更改仓库权限。
官方文档：Gitea 备份与恢复