轻量代码托管怎么自建？Gitea、Actions、备份与服务器配置

给个人项目或小团队建私有 Git 仓库，Gitea 算轻量。真正要解决的不是“网页能打开”，是代码能不能正常推送、数据放哪、更新失败怎么回滚、服务器坏了仓库能不能恢复。

这次用固定版本 Gitea 1.27.1 跑 Docker 部署，实际完成了仓库创建、HTTP Git 推送、停止写入后的卷备份，以及从全新数据卷恢复。测试环境是本地 1核2G 容器，不等同于萤光云 VPS 压力测试；多人并发、Git LFS 和 Actions Runner 要另行验证。

先看结论：什么配置适合你的Gitea

Gitea本体通常不是整套研发环境里最吃资源的部分。仓库体积、并发克隆、全文索引、LFS文件、附件和Actions Runner，往往比“有几个账号”更影响配置。

这些是部署起点，不是固定承载人数。下单前至少估算：现有Git仓库总大小、未来一年增长、单次备份大小、保留份数、LFS和附件规模、每天克隆次数，以及是否运行Actions。

本次实测了什么

测试编号为 T058-GITEA-LOCAL-001，日期为2026年8月2日。环境是Apple Silicon Mac上的Colima Linux虚拟机，Gitea容器限制为1 vCPU和2GB内存，数据库使用SQLite。

本次完成了以下业务路径：

1. 启动固定镜像 docker.gitea.com/gitea:1.27.1；
2. 创建管理员和一个私有仓库；
3. 从本地Git客户端提交README并推送到 main 分支；
4. 停止Gitea，备份完整 /data 数据卷；
5. 将备份解压到全新数据卷，并从另一个端口启动恢复容器；
6. 通过API读取原仓库，再用 git ls-remote 验证恢复后的 main 引用。

恢复前后的主分支均指向同一提交。空闲瞬时采样约为105.6MiB内存，但这只是一个空仓库、单用户、无Runner的短时样本，不能外推为长期生产占用。

部署前要准备什么

服务器和系统

本文命令面向64位Linux服务器。建议使用仍在安全维护期内的Ubuntu或Debian，并先完成系统更新、时区、SSH密钥和防火墙设置。

至少准备：

• 一个可持续使用的域名，例如 git.example.com；
• 对外的HTTPS端口443；
• 一个Git SSH端口，可以使用22，也可以映射为2222等其他主机端口；
• 足够容纳仓库、附件、LFS、数据库和备份副本的磁盘；
• 独立于当前服务器的数据备份位置。

不要把容器内部的3000端口直接长期暴露给公网。生产环境应通过Nginx或Caddy终止HTTPS，只允许必要端口通过防火墙。

选择SQLite还是PostgreSQL

SQLite最适合个人、验证环境和低并发小团队，部署简单，备份时必须严格控制写入一致性。团队扩大、自动化增多或需要更清晰的数据库运维边界时，可以改用PostgreSQL。

切换数据库并不会自动解决所有性能问题。大仓库克隆主要消耗网络和磁盘，全文索引、LFS和Runner则有不同瓶颈。先观察指标，再决定拆分。

用Docker Compose安装Gitea 1.27.1

先建立工作目录：

sudo mkdir -p /opt/gitea
cd /opt/gitea

创建 docker-compose.yml：

services:
  gitea:
    image: docker.gitea.com/gitea:1.27.1
    container_name: gitea
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      GITEA__database__DB_TYPE: sqlite3
      GITEA__database__PATH: /data/gitea/gitea.db
      GITEA__security__INSTALL_LOCK: "true"
      GITEA__service__DISABLE_REGISTRATION: "true"
      GITEA__server__DOMAIN: git.example.com
      GITEA__server__ROOT_URL: https://git.example.com/
      GITEA__server__SSH_DOMAIN: git.example.com
      GITEA__server__SSH_PORT: "2222"
    ports:
      - "127.0.0.1:3000:3000"
      - "2222:22"
    volumes:
      - gitea-data:/data

volumes:
  gitea-data:

然后启动并检查：

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 gitea
curl -fsS http://127.0.0.1:3000/api/healthz

本文固定1.27.1是为了让操作可复现。以后升级时先看官方发行说明、备份并固定目标版本，不要在生产环境长期使用无法追踪变化的 latest。

创建第一个管理员

如果关闭了公开注册，可以在服务器上通过Gitea CLI创建管理员：

docker exec --user git gitea gitea admin user create \
  --config /data/gitea/conf/app.ini \
  --username your-admin \
  --email admin@example.com \
  --password '请替换为随机强密码' \
  --admin \
  --must-change-password=false

不要把真实密码写进Shell历史、Compose文件或文章截图。生产环境还应启用双因素认证，按团队建立普通成员和组织权限，避免所有人共用管理员账号。

验证Git推送，而不是只看首页

登录后创建一个测试仓库，再从本地电脑执行：

mkdir gitea-check
cd gitea-check
git init -b main
printf '# Gitea check\n' > README.md
git add README.md
git commit -m 'test: first push'
git remote add origin https://git.example.com/your-name/gitea-check.git
git push -u origin main

验收时要同时确认：

• 网页上能看到仓库、分支和提交；
• 本地可以再次克隆；
• 普通成员不能进入管理员设置；
• 删除成员权限后，原凭据不能继续读写私有仓库；
• 服务重启后，仓库和数据库仍在。

如果使用SSH推送，还要检查域名、主机映射端口、Gitea显示的克隆地址和云防火墙是否一致。只开放容器端口并不代表公网路径已经正确。

Gitea Actions要不要和主服务放在一起

Gitea Actions由独立Runner执行。Runner可能拉取第三方Action、执行仓库脚本、构建镜像并访问外部网络，因此它既是资源消耗点，也是安全边界。

小团队可以先不开Runner。确实需要CI/CD时，至少做到：

• Runner与Gitea Web/数据库分开运行；
• 不让不可信公开仓库使用具有宿主高权限的Runner；
• 对Runner设置CPU、内存、磁盘和任务超时；
• 控制能读取的密钥、内网地址和镜像仓库；
• 单独监控任务队列、失败率和临时磁盘。

本次没有运行Actions任务，所以不能用本次105.6MiB空闲采样推算Runner配置。

如何做可恢复的备份

Gitea的数据不只有Git仓库，还包括数据库、附件、LFS、头像、配置和索引。只复制某个裸仓库目录，不能完整恢复账号、权限和工单。

官方文档强调备份一致性：备份期间如果数据库、仓库和附件继续变化，恢复后可能互相对不上。本次实测采用的是停机卷快照：

docker compose stop gitea

docker run --rm \
  -v gitea-data:/source:ro \
  -v gitea-backup:/backup \
  alpine:3.22 \
  sh -c 'tar -C /source -czf /backup/gitea-data.tar.gz .'

docker compose start gitea

生产环境不能只把备份留在同一台服务器。至少再复制到独立服务器或对象存储，并为备份文件设置加密、保留周期和访问权限。

恢复演练

不要等服务器损坏后才第一次尝试恢复。可以创建一个全新的数据卷：

docker volume create gitea-restore-data

docker run --rm \
  -v gitea-backup:/backup:ro \
  -v gitea-restore-data:/restore \
  alpine:3.22 \
  sh -c 'tar -C /restore -xzf /backup/gitea-data.tar.gz'

再让一个临时Gitea容器挂载该卷，从不同端口启动。恢复验收至少包括登录、仓库列表、私有权限、HTTP/SSH克隆、Git推送、附件和LFS。本文实测完成了仓库读取和HTTP Git引用校验，未覆盖LFS与SSH恢复。

如何安全更新Gitea

Gitea 1.27.1包含安全修复。升级不应只执行一次 pull：

1. 阅读目标版本发行说明和升级说明；
2. 记录当前镜像摘要、配置和数据库类型；
3. 停止写入并完成可恢复备份；
4. 在恢复副本上先升级，验证登录、仓库、克隆、推送、工单和Actions；
5. 修改Compose中的固定版本，再启动生产容器；
6. 检查日志、数据库迁移和核心业务路径；
7. 保留旧镜像和升级前备份，直到观察期结束。

不要在没有数据库备份的情况下直接降级。数据库迁移可能使旧版本无法识别新结构，回滚应以官方说明和恢复完整备份为基础。

常见故障怎么排查

网页能开，但克隆地址端口不对

检查 ROOT_URL、SSH_DOMAIN、SSH_PORT、反向代理转发头和云防火墙。容器内22端口映射到主机2222时，页面上也必须显示2222。

容器不断重启或无法写入数据

先看：

docker compose ps
docker compose logs --tail=200 gitea
docker inspect gitea --format '{{json .Mounts}}'

主机目录挂载时，UID/GID和目录权限不匹配很常见。命名卷由Docker管理权限，部署更简单，但仍要验证备份导出和恢复。

推送返回413或连接中断

检查反向代理请求体限制、超时、出口链路和仓库大小。大文件不应长期直接塞进Git历史，应评估Git LFS或对象存储，同时重新估算备份空间。

恢复后仓库存在但推送失败

确认恢复了数据库、仓库和配置，检查文件所有者。安装路径或部署方式改变后，还可能需要按官方文档重新生成Git Hooks。

服务器上线前检查表

• 固定Gitea版本并订阅安全更新；
• 域名、HTTPS和Git SSH端口一致；
• 禁止公开注册或配置审批流程；
• 管理员使用独立账号和双因素认证；
• 普通成员、组织和仓库权限经过测试；
• /data位于持久存储；
• 备份位于独立位置且已完成恢复演练；
• 监控CPU、可用内存、磁盘空间、磁盘延迟和错误日志；
• Actions Runner单独评估与隔离；
• 记录真实仓库增长和备份时间，再决定扩容。

如何选择萤光云服务器

个人验证可以先从较小Linux配置开始，但生产团队不要只按“账号数量”购买。代码库增长、克隆流量、LFS和备份保留量会直接影响磁盘与网络；Actions Runner还需要单独资源。

可以在萤光云海外VPS节点列表核对当前可售地域和配置。先选择接近主要团队成员的地域，再确认Linux镜像、SSD空间、带宽流量和备份去向。价格、库存、线路和服务规则以产品页及下单页面实时信息为准。

如果不确定从哪一档开始，先建立恢复得出来的测试环境，导入脱敏仓库，记录一周的CPU、内存、磁盘增长、克隆耗时和备份窗口，再决定是否升级。这比根据一张通用人数表购买更可靠。

FAQ

Gitea 1核2G够用吗？

可以作为个人或小仓库功能验证的起点。本次1核2G限制容器完成了安装、Git推送和恢复，但没有测试多人并发、LFS和Runner，因此不能据此保证你的生产团队够用。

Gitea必须使用Docker吗？

不是。官方也提供二进制和包管理等安装方式。Docker的优势是版本和数据边界更容易复现；无论采用哪种方式，都必须明确配置、数据库、仓库和附件的位置。

SQLite可以用于生产吗？

低并发小团队可以评估SQLite，但要严格控制备份一致性并监控锁等待。需要更清晰的数据库运维、并发或高可用边界时，优先评估PostgreSQL。

只备份Git仓库目录可以吗？

不够。账号、权限、工单、附件、LFS和配置不一定在仓库目录里。完整恢复需要数据库、仓库和其他持久数据保持一致。

Gitea Actions会占用Gitea服务器资源吗？

任务由Runner执行，但Gitea仍负责调度、日志和状态。Runner本身可能大量消耗CPU、内存和磁盘，建议与主服务分开估算和隔离。

资料来源

• Gitea 1.27.1发行说明
• Gitea官方Docker安装文档
• Gitea官方备份与恢复文档
• Gitea Actions概览
• Gitea Actions设计

这篇中的第一方测试仅对应 T058-GITEA-LOCAL-001 所述环境和步骤。软件版本、安全建议及产品库存可能变化，实际部署前请再次核对官方资料和萤光云产品页。