您可以通过选择预安装的应用程序镜像，在 VoyraCloud VPS 上自托管 Gitea，通过 SSH 创建第一个管理员，然后使用 Web 界面、HTTPS Git 或 SSH Git 来管理您的代码库。 该镜像消除了手动安装步骤，而帐户策略、域名、HTTPS、代码库访问、更新、备份和事件响应仍然由您控制。
TL;DR
- VoyraCloud Gitea 应用程序镜像 提供了在 Cloud VPS 和 Residential IP VPS 上预安装的 Gitea Community Edition 实例。
- 安装页面在交付前被锁定。通过您资源详细信息中显示的 SSH 命令创建第一个管理员，而不是通过公开暴露的安装向导。
- 端口
3000绑定到 VPS 回环接口。使用资源详细信息中的 SSH 隧道命令进行首次 Web 登录；它不会作为公共 HTTP 暴露。 - 在发布 Web 界面或使用 HTTPS Git 之前，添加域名、反向代理和浏览器信任的 HTTPS。Gitea SSH Git 在您将公钥添加到帐户后使用单独的公共端口
2222。 - 默认情况下，新用户注册被禁用。管理员决定是手动创建用户还是更改注册政策。
- 代码库、帐户、问题、拉取请求、包、附件、配置和机密在正常 VPS 重启后仍然存在，但重启持久性并不是离线备份。
- VoyraCloud 在交付后不会自动升级、备份、监控或管理 Gitea 实例。
什么是 Gitea？
Gitea 是一个开源软件开发服务，用于托管 Git 代码库和协作源代码。 它提供了围绕标准 Git 工作流程的 Web 界面，以及用户帐户、组织、代码库权限、拉取请求、问题、项目、维基、发布、包、Webhooks 和 API 访问。
官方 Gitea 文档 描述了希望运营自己服务的团队的安装和管理。自托管在您希望将代码库服务、存储位置、帐户策略、网络访问、更新时机和备份过程置于自己管理之下时非常有用。
Gitea VPS 非常适合：
- 希望在个人服务器上拥有私有代码库的开发人员。
- 需要 Git 托管、代码审查、问题和组织权限的小团队。
- 为客户项目保留单独代码库的代理机构。
- 通过 SSH 密钥、访问令牌、Webhooks 或 API 将代码库连接到部署系统的基础设施团队。
- 需要轻量级替代大型软件开发平台的实验室或内部环境。
自托管并不意味着代码库操作无需维护。仍然有人负责操作系统安全、Gitea 更新、身份验证政策、HTTPS、备份、存储增长、滥用预防和恢复测试。
如何开始使用 VoyraCloud Gitea 镜像？
最快的部署路径是创建一个支持的 VoyraCloud VPS，并使用 Gitea 镜像，从资源详细信息中运行私有管理员设置命令。 您无需手动安装 Docker、Gitea 或初始数据库。
- 打开上面的链接，进入 VoyraCloud 的 Gitea 页面，并继续进行 VPS 购买流程。
- 选择一个符合条件的 Cloud VPS 或 Residential IP VPS 配置。Cloud VPS 是 Git 托管的一般用途选项；当您的更广泛工作负载特别需要该产品的网络特性时，Residential IP VPS 仍然可用。
- 选择当前所提供的任何区域，并确认在镜像部分选择了 Gitea。
- 创建 VPS，并等待资源和应用程序准备就绪。
- 打开资源详细信息并找到应用程序部分。
- 复制管理员设置命令。它遵循以下模式：
ssh -t -p <ssh-port> <ssh-user>@<server-ip> 'sudo /usr/local/sbin/voyra-gitea-create-admin'7. 从您的终端运行该命令，并输入管理员用户名和电子邮件。Gitea 的官方 CLI 生成一个 24 字符的一次性随机密码，并仅在当前 SSH 会话中显示。
8. 从应用程序部分复制 SSH 隧道命令，并保持该终端会话打开。它遵循以下模式：
ssh -N -L 3000:127.0.0.1:3000 -p <ssh-port> <ssh-user>@<server-ip>9. 在浏览器中打开本地访问 URL：
http://127.0.0.1:300010. 使用管理员帐户和一次性密码登录，然后在 Gitea 要求更改时设置新密码。
11. 创建一个私有测试代码库，添加 SSH 公钥，并验证一次 SSH 克隆和推送。
12. 连接您的域名，配置受信任的 HTTPS，更新 Gitea 公共 URL 设置，并确认生成的 HTTPS 克隆链接使用预期地址。
13. 重启 VPS 一次，并验证 Gitea 自动返回，管理员、测试代码库、提交历史、密钥和设置保持不变。
14. 创建离线备份，并在依赖该实例进行重要源代码之前执行测试恢复。
设置命令故意与网页分开。公共安装向导已经被锁定，因此互联网访客无法在所有者之前通过创建第一个管理员来声称新的实例。如果已经存在管理员，命令也会停止。
使用您 VPS 资源中显示的 SSH 用户名和端口。不要假设每个服务器都使用 root 或端口 22。用于管理的 VPS SSH 连接也不同于 Gitea 在端口 2222 上的 SSH Git 端点。
应用程序镜像包含什么？
Gitea 应用程序镜像包括一个持久的单服务器起点，而不是一个托管的源代码托管服务。 交付边界决定了您在正常团队使用之前必须配置的内容。
| 由应用程序镜像交付 | 用户管理或未包含 |
|---|---|
| 经过批准的 Gitea Community Edition 稳定版本 | 自动 Gitea 升级 |
| 基于 Ubuntu 的 VPS 环境 | 管理操作系统管理 |
| 在官方容器中运行的 Gitea，带有本地 SQLite 数据库 | 外部 PostgreSQL 或 MySQL 服务 |
| 锁定的安装页面 | 公共 Web 安装向导 |
| 用于创建第一个管理员的私有 SSH 命令 | 预创建的管理员或固定密码 |
| 默认情况下禁用注册 | 自动团队成员配置 |
在回环端口 3000 上的 Web 后端 | 公共 HTTP 暴露、域名注册、反向代理和自动 HTTPS |
在端口 2222 上的 SSH Git | 预安装的用户 SSH 密钥 |
| 持久的代码库、数据库、配置和应用程序数据 | 自动离线备份 |
| 正常 VPS 重启后的服务恢复 | 高可用性或自动故障转移 |
| 标准 Gitea 协作功能 | 管理的运行器、CI 容量、SMTP、OAuth、LDAP 或外部存储 |
该镜像不包括示例代码库、组织、用户、运行器、包、第三方凭据、电子邮件发送、域名或浏览器信任的证书。它也不在资源详细信息中暴露应用程序机密。
如何安全地设置第一个管理员？
第一个管理员是通过经过身份验证的 VPS SSH 会话创建的，而 Gitea 的公共安装页面保持锁定。 这防止了常见的竞争条件，即未初始化的 Web 安装程序可以从互联网访问，而意外访客首先完成设置。
应用程序镜像在交付之前准备数据库和配置。它启用 Gitea 的安装锁并禁用公共用户注册。然后，管理员设置命令在应用程序环境中运行 Gitea 的官方管理命令。
设置过程应具有以下属性：
- 它以交互方式询问用户名和电子邮件。
- 它告诉 Gitea 的官方 CLI 生成一个 24 字符的随机密码，而不是将您选择的密码放在命令行参数中。
- 它仅在当前 SSH 终端中显示一次性密码，而不将其写入 shell 历史、文件或日志。
- 它要求在第一次 Web 登录时更改密码。
- 在第一个管理员存在后，它拒绝创建另一个管理员。
- 它不会为您生成个人访问令牌或 SSH 密钥。
- 它不会打印 Gitea 的内部机密。
登录后，查看 站点管理 和用户注册政策。注册默认关闭，以便未知的互联网用户无法创建帐户。您可以从管理界面创建批准的用户，或者如果开放注册是有意的要求并且您有滥用控制计划，则可以更改政策。
不要通过聊天、工单或共享 shell 转录发送一次性或最终管理员密码。更改密码后关闭初始 SSH 会话。仅在操作所有权需要时添加第二个管理员，并在实际情况下使用单独的普通帐户进行常规 Git 工作。
HTTPS Git 和 SSH Git 有何不同？
HTTPS Git 使用您信任的 HTTPS 域后面的 Gitea Web 端点，而 SSH Git 使用专用的 Gitea SSH 服务和帐户级公钥。 两者都支持正常的克隆、获取、拉取和推送操作，但它们的身份验证和传输设置有所不同。
| 方法 | 初始地址模式 | 身份验证 | 设置后的最佳使用 |
|---|---|---|---|
| 初始 Web 界面 | http://127.0.0.1:3000 通过 SSH 隧道 | Gitea 用户名和密码 | 首次登录、密码更改和私有设置 |
| 常规 Web 界面 | https://git.example.com | Gitea 用户名和密码 | 域名设置后的代码库浏览和管理 |
| HTTPS Git | https://git.example.com/<owner>/<repo>.git | 优先使用个人访问令牌用于 Git 客户端 | 域名和受信任的 HTTPS 设置后的基于 Web 的 Git 传输 |
| SSH Git | ssh://git@<server-ip>:2222/<owner>/<repo>.git | SSH 公钥添加到 Gitea 帐户 | 适合开发人员 Git 客户端和使用管理密钥的自动化 |
| VPS 系统 SSH | 资源特定的主机和端口 | VPS SSH 密钥或当前服务器凭据 | 服务器管理和第一个管理员设置，而不是代码库访问 |
对于 SSH Git：
- 在工作站上创建或选择一个 SSH 密钥。
- 登录 Gitea 并在帐户设置下添加公钥。
- 从代码库页面复制 SSH 克隆地址。
- 在第一次连接时验证主机指纹，而不是在未检查的情况下接受意外密钥。
- 将私钥保留在客户端，并使用适当的文件权限保护它，并在适当时使用密码短语。
Gitea SSH Git 不应要求输入 Gitea Web 密码。端口 2222 属于代码库服务；它不提供服务器 shell。
对于 HTTPS Git，请创建一个仅具有该客户端或集成所需权限的个人访问令牌。避免将令牌直接放入将保留在 shell 历史中的命令中。使用您的 Git 凭据助手或适合您操作系统的秘密存储。
为什么要添加域名和 HTTPS？
域名和浏览器信任的 HTTPS 保护 Web 凭据和 HTTPS Git 流量，并为实例提供稳定的公共身份。 该镜像将端口 3000 保持在 VPS 回环接口上，因此在您故意配置反向代理之前，Web 服务是无法公开访问的。
官方 Gitea 反向代理指南 解释了 Gitea 如何在常见代理后面运行。生产设置通常包括：
- 指向 VPS 的 DNS 记录，例如
git.example.com。 - 在端口
80和443上监听的反向代理。 - 用于该域的浏览器信任的 TLS 证书。
- HTTP 到 HTTPS 的重定向。
- 与代理配置匹配的转发主机、客户端地址和协议头。
- 更新为最终 HTTPS URL 的 Gitea 公共
ROOT_URL和域设置。 - 更新
SSH_DOMAIN和显示的 SSH 端口，以保持代码库克隆说明的准确性。
更改地址后，验证以下所有内容：
- 登录页面在没有证书警告的情况下加载。
- Gitea 生成的链接使用 HTTPS 域而不是旧的 IP 地址。
- HTTP Git 克隆和推送通过 HTTPS 工作。
- SSH 克隆链接显示正确的域和端口。
- Webhooks 和 OAuth 回调 URL（如果稍后配置）使用预期的公共地址。
- 大推送不会因反向代理主体或超时限制而失败。
应用程序镜像不会为您注册域名或签发证书。这些步骤由用户管理，因为最终主机名和 DNS 帐户属于站点所有者。
如何组织用户和代码库访问？
使用个人帐户、组织团队、代码库权限、SSH 密钥和范围令牌，而不是共享一个管理员身份。 Gitea 可以托管私有和公共代码库，但管理员必须决定谁可以发现、阅读、写入、审查和管理每个资源。
一个实用的小团队基线是：
- 除非有明确理由开放，否则保持公共注册禁用。
- 给每个人一个个人帐户。
- 将管理员访问权限保留给服务器和服务所有者。
- 为相关代码库创建组织，为权限组创建团队。
- 为每个角色授予所需的最少代码库权限。
- 对重要分支使用分支保护和审查规则。
- 使用部署密钥或范围个人访问令牌进行自动化，而不是管理员密码。
- 当不再需要访问时，及时删除帐户、密钥和令牌。
- 在适合您的访问模型时，为特权用户启用双因素身份验证。
- 定期审查组织、代码库、Webhooks、OAuth 和令牌的所有权。
如果您稍后连接 SMTP、OAuth、LDAP 或 OpenID Connect，请将其视为单独的生产更改。在依赖集成之前，测试帐户链接、恢复、离职、管理员访问和故障行为。基础镜像不包括这些服务或其凭据。
Gitea 备份必须保护什么？
完整的 Gitea 备份必须保护数据库、Git 代码库、配置、应用程序机密以及您的实例使用的任何附件、LFS 对象、包、发布、头像或其他存储数据。 仅复制 Git 代码库不足以重建用户、权限、问题、拉取请求、令牌、Webhooks 和服务设置。
官方 Gitea 备份和恢复文档 描述了 gitea dump 工作流，并警告该服务包含多个可以一起更改的数据层。一个一致的备份需要协调；一个应用程序数据库在说代码库操作完成时，而代码库副本捕获了早期状态，可能会产生不完整的恢复点。
您的备份计划应定义：
| 层 | 示例 | 为什么重要 |
|---|---|---|
| 数据库 | 用户、权限、问题、拉取请求、设置、令牌 | 重建应用程序状态和关系 |
| Git 代码库 | 提交、分支、标签、Git 对象 | 保留源历史 |
| 配置和机密 | 公共 URL、服务设置、SECRET_KEY、内部令牌 | 保持加密数据可读且行为一致 |
| 应用程序数据 | 附件、头像、LFS、包、发布资产、索引 | 保留正常 Git 对象之外的内容 |
| 恢复程序 | 版本、所有权、钩子再生、验证步骤 | 将存储的文件变为可用的恢复服务 |
将恢复副本存储在 VPS 之外。当它们包含私有源代码、凭据、令牌、个人数据或内部配置时，请对其进行加密。保留多个恢复点，监控备份完成情况，并在单独的环境中测试恢复。
正常的 VPS 重启证明了持久性，而不是可恢复性。它无法保护意外删除、代码库损坏、升级失败、凭据泄露、文件系统丢失、VPS 删除或攻击者同时删除活动数据和本地备份文件。
有关 SSH、修补、监控和恢复所有权的更广泛服务器维护基线，请参见 VPS 管理：实用指南。
如何更新 Gitea？
将 Gitea 更新视为受控的应用程序更改：阅读发布说明，创建可恢复的备份，保留部署类型，并在之后验证代码库和身份验证。 该镜像使用固定的稳定版本，而不是浮动标签，因此重启不会默默更改应用程序版本。
在更新之前：
- 阅读源版本和目标版本的 Gitea 发布和升级说明。
- 确认支持的升级路径，而不是在未审查的情况下跨版本跳跃。
- 创建并验证离线备份。
- 记录当前容器镜像、配置、公共 URL、SSH 设置和存储所有权。
- 计划维护窗口，因为数据库迁移或备份一致性可能需要停机。
在更新之后：
- 确认容器达到健康状态。
- 使用普通帐户和管理员帐户登录。
- 通过 HTTP(S) 和 SSH 克隆、拉取和推送。
- 在测试代码库中打开一个问题和拉取请求。
- 检查您的实例实际使用的 Webhooks、包、LFS、电子邮件和身份验证集成。
- 验证生成的克隆 URL 仍然使用正确的域和端口。
- 确认用户、代码库、配置和机密在更改中幸存。
不要随意在 Gitea 的有根和无根容器布局之间切换；官方 Docker 文档指出，它们的存储和 SSH 行为不同。除非您有迁移和回滚计划，否则请保留应用程序镜像选择的部署模型。
Gitea 需要多少 VPS 容量？
Gitea 的容量取决于用户并发、代码库数量和大小、Git 操作模式、包、LFS、索引、自动化和数据保留要求。 在购买流程中选择符合条件的计划，监控实际工作负载，并在持续的 CPU、内存、磁盘或 I/O 压力出现时转移到更大的配置。
官方 Gitea 项目将小团队安装描述为相对轻量级，但该声明并未定义每个代码库工作负载的容量。大型单一代码库、频繁克隆、大型二进制资产、包存储、搜索索引和自动化作业可能会显著改变资源配置。
| 工作负载 | 容量考虑 |
|---|---|
| 少量小型源代码库 | 适合入门验证工作负载 |
| 小型开发团队 | 测量并发 Web 和 Git 操作 |
| 大型代码库历史 | 规划磁盘空间、备份时间和克隆流量 |
| Git LFS 或包注册表 | 单独规划存储和传输，而不是正常 Git 对象 |
| 许多 Webhooks 或集成 | 监控队列、失败和下游可用性 |
| Gitea Actions | 运行器容量是单独的，基础镜像不包括 |
| 外部数据库或对象存储 | 需要单独设计和操作的架构 |
监控内存压力、CPU 饱和、文件系统容量、inode 使用、SQLite 锁行为、容器重启、请求延迟、失败的 Git 操作、备份持续时间和恢复持续时间。最低购买门槛是经过验证的起点，而不是对无限代码库或用户的承诺。
常见错误
大多数早期 Gitea 故障来自将预安装的代码库服务视为完全托管的平台。 避免以下错误：
- 让安装向导暴露。 使用 SSH 管理员设置流程，并保持安装锁定。
- 在没有滥用计划的情况下开放公共注册。 除非开放注册是有意的，否则保持注册禁用。
- 将端口
3000暴露为公共 HTTP。 保持它在回环上，并在常规 Web 和 HTTPS Git 使用之前添加域名和受信任的 HTTPS。 - 将端口
2222与 VPS shell 访问混淆。 它是 Gitea SSH Git 端点，不提供服务器 shell。 - 共享一个管理员帐户。 使用个人帐户和最小权限。
- 将令牌放入 shell 历史或代码库文件中。 使用适当的凭据或秘密存储。
- 仅备份 Git 代码库。 还要保护数据库、配置、机密、附件、LFS、包和恢复程序。
- 将唯一备份保留在同一 VPS 上。 将加密的恢复副本存储在服务器外。
- 使用浮动容器标签。 固定经过测试的稳定版本并有意识地更新。
- 假设最低容量覆盖 CI 或大型二进制文件。 运行器、包、LFS、单一代码库和高并发需要单独的大小。
- 在未更新 Gitea 的情况下更改公共 URL。 验证
ROOT_URL、域名、SSH 域、克隆链接、回调和 Webhooks。 - 在没有恢复测试的情况下更新。 从未恢复的备份是未经验证的恢复计划。
常见问题解答
我可以在不手动安装的情况下自托管 Gitea 吗？
可以。VoyraCloud Gitea 应用程序镜像提供了在符合条件的 Cloud VPS 或 Residential IP VPS 上预安装的 Community Edition 实例。 您仍然需要创建第一个管理员，配置代码库访问，连接域名和 HTTPS，管理用户，并拥有更新和备份。
为什么第一个管理员通过 SSH 创建？
SSH 将管理员创建步骤保持在对 VPS 的访问后面，并防止互联网访客声称暴露的安装向导。 公共安装页面在交付前被锁定，而设置命令在已经存在一个管理员后拒绝创建另一个管理员。
我可以直接将端口 3000 暴露到互联网吗？
不可以。应用程序将端口 3000 绑定到 VPS 回环接口，第一次登录使用 SSH 隧道。 连接域名，配置反向代理和浏览器信任的 HTTPS，并在发布 Web 服务之前更新 Gitea 的公共 URL 设置。
VPS SSH 和 Gitea SSH Git 有什么区别？
VPS SSH 管理 Linux 服务器，而 Gitea SSH Git 使用附加到 Gitea 帐户的密钥传输代码库数据。 VPS 使用为资源显示的 SSH 主机和端口；Gitea SSH Git 使用 git 用户和端口 2222。
我应该为 HTTPS Git 使用密码还是令牌？
使用仅具有客户端或集成所需权限的个人访问令牌。 将其存储在适当的凭据助手中，而不是嵌入到代码库、脚本或 shell 历史条目中。
公共用户注册是否启用？
不。应用程序镜像默认禁用自注册。 管理员可以创建批准的用户，或在评估滥用、电子邮件验证和访问控制要求后故意更改注册政策。
该镜像是否包括 Gitea Actions 运行器？
不。基础镜像不配置或操作 Actions 运行器。 运行器执行能力、隔离、机密、网络访问和维护需要单独设计。
我必须备份什么？
保护数据库、Git 代码库、配置、应用程序机密、附件、LFS 对象、包、发布和任何其他存储的应用程序数据。 保持副本在 VPS 之外，并测试完整恢复。
VoyraCloud 会自动更新 Gitea 吗？
不会。新的 VPS 资源接收经过批准的稳定版本，而每个所有者控制后续更新。 阅读官方升级说明，创建可恢复的备份，并在每次更改后测试 Git 和身份验证工作流。
Residential IP VPS 是 Gitea 的必要条件吗？
不是。Cloud VPS 是源代码服务的正常通用选择。 当更广泛的工作负载特别需要其网络特性时，Residential IP VPS 也在技术上得到支持，但住宅身份本身并不会改善正常的 Git 托管。
结论
在 VPS 上自托管 Gitea 使开发人员和小团队能够控制代码库、帐户、协作数据、网络访问、更新和恢复。 VoyraCloud 应用程序镜像通过提供一个固定的稳定 Gitea 环境、锁定的安装页面、私有的第一个管理员设置、HTTPS 和 SSH Git 访问以及持久的本地数据，缩短了初始部署时间。
这个起点仍然需要一个所有者。添加受信任的 HTTPS，使用个人帐户和范围凭据，保持注册与您的访问政策一致，监控容量，固定更新，并在将服务视为关键基础设施之前维护经过测试的离线备份。
有关服务前的域名和反向代理层，请参见 VPS 上的 Nginx Proxy Manager 指南。
使用 VoyraCloud Gitea 应用程序镜像 从预安装的 VPS 环境开始，同时保持您的源代码服务在您的控制之下。