在小鸡上部署私有 Git：Gitea / Forgejo 比 GitLab 省多少内存？Docker 一键与 Actions 实战

延伸阅读

更多相关攻略推荐：Ollama AI系列(2)：VPS上的AI推理与API应用、Ollama AI系列(2)：VPS上的AI推理与API应用、【CPU选型 01】搭载 AMD Ryzen 9950X 的 VPS、ARM / Ampere 席卷 VPS：性价比真香还是兼容陷阱？、Ollama AI系列(2)：VPS上的AI推理与API应用。

一、部署代码仓库的选型陷阱：GitLab 太能吃内存

很多人在小鸡上第一次想搭"自己的 GitHub"时，直觉是装 GitLab——毕竟名气最大、功能最全。然后灾难就来了。GitLab 官方文档写的"最低要求"是单节点至少 4 GiB 内存，但那只是能启动的底线；在新版文档里，单节点基线已经提到 16 GB 内存、8 vCPU，内存受限环境勉强能跑到 8 GB。实际上一套 Omnibus GitLab 跑起来，Puma、Sidekiq、Gitaly、PostgreSQL、Redis、Prometheus 一堆组件同时吃内存，4GB 的机器基本是卡死、OOM、动不动 502。

更现实地说，GitLab 是给"公司级代码平台"设计的，内置 CI、容器仓库、安全扫描、Pages、监控系统，样样都要资源。你只是想存点私有脚本、放几个个人项目，结果为了它租一台 8GB 的机器，每月成本直接翻倍。在小鸡（1 核 512MB / 1GB 那种几美元月付的 VPS）上硬上 GitLab，等于让一只大象睡在鞋盒里——注定翻车。所以选型的第一课是：按需求规模选工具，别被名气带偏。

二、轻量神器：Gitea 与它的社区分支 Forgejo

如果你要的是"能推代码、能建私有库、能看提交、最好还能跑点 CI"，那 Gitea 才是小鸡的真命天子。它是用 Go 语言写的，编译出来一个二进制，常驻内存往往只有 几十 MB（常 cited 不到 50MB 空闲占用），1 核 512MB 的 VPS 都能丝滑运行，启动快、占用低、界面清爽，操作和 GitHub 高度相似，老用户零学习成本。

这里插一句背景：Gitea 本是 Go 社区对另一个老牌轻量 Git 服务 Gogs 的 fork，后来自己长成了主流。2022 年左右，Gitea 背后的商业公司（Gitea LLC）成立，引发社区对治理模式的担忧，于是部分核心贡献者又 fork 出了 Forgejo，定位为社区驱动、完全开源的版本。两者今天功能几乎一致、配置通用，你装哪个都行；Forgejo 更强调"无单一商业控制"，Gitea 迭代更快。本文以 Gitea 为例，命令对 Forgejo 基本通用。

三、Docker 一键部署 Gitea

Gitea 官方提供 Docker 镜像，最省事的方式是用 docker-compose。先建个目录放数据，再写一份 docker-compose.yml。最精简的 SQLite 版本（连数据库都不用额外装）长这样：

version: "3"
services:
  server:
    image: docker.gitea.com/gitea:1.27.0
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"

几个关键点：3000 是 Gitea 的 Web 端口，映射出来就能浏览器访问；222:22 是把容器里的 SSH（22）映射到宿主机的 222，这样你既能用 3000 走 HTTP，也能用 222 走 Git 的 SSH 协议拉推代码，避免和宿主机自带 SSH（22）冲突。数据全部落在 ./gitea 这个 volume 里，持久化靠这一行，删容器数据不丢。首次启动后访问 http://你的IP:3000，按向导设管理员账号、数据库类型（默认 SQLite 即可）、仓库根目录，点完成就进系统了。

如果你预期项目多、并发高，可以把 SQLite 换成 MySQL 或 PostgreSQL。在 compose 里加一个 db 服务，并给 Gitea 注入环境变量即可：

    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=mysql
      - GITEA__database__HOST=db:3306
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=gitea
    depends_on:
      - db
  db:
    image: docker.io/library/mysql:8
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=gitea
      - MYSQL_USER=gitea
      - MYSQL_PASSWORD=gitea
      - MYSQL_DATABASE=gitea
    volumes:
      - ./mysql:/var/lib/mysql

四、配置 SSH 密钥登录与创建私有库

进系统后，第一件事是把自己的公钥传上去：在右上角头像 → Settings → SSH / GPG Keys → Add Key，把本机 ~/.ssh/id_ed25519.pub 的内容粘进去。之后克隆就用 SSH 地址，比如 ssh://git@你的IP:222/用户名/项目名.git（注意端口是 222，不是默认 22）。

建私有库很简单：点右上角 "+" → New Repository，填名字、描述，把 Visibility 选成 Private 即可。私有库只有你和被授权的人能看到。如果你用的是 222 这种非标准端口，clone 时记得带上端口，或者在本地 ~/.ssh/config 里给这个主机写一段配置，把端口固定下来，省得每次手敲。

五、团队与权限控制

一个人玩用不上权限，但只要你拉了朋友或小团队，就得管权限。Gitea 的权限是分层的：所有者（Owner）拥有组织最高权限；管理员（Admin）能管设置和用户；具体到某个仓库，成员角色通常是写入（Write，能推代码）和读取（Read，只能拉只能看）。建组织（Organization）后，可以把人加进组织、再分配进不同团队（Team），每个 Team 对一组仓库有不同权限，精细化管理就像 GitHub 的 org/team 模式。

实用建议：自己的私密项目放个人名下设 Private；多人协作建 Organization，按"核心开发=Write、外包/观察员=Read"分配，避免出现"谁都能推生产分支"的事故。Web 上还能设分支保护规则，比如禁止直接推 main、必须走 PR，这就很有团队那味儿了。

六、用 Gitea Actions 打造私有轻量 CI/CD

光有仓库还不够"专业"，很多人想要的是"push 一下自动跑测试、自动构建"。好消息：Gitea 从 1.19 起内置了 Gitea Actions，语法几乎完全兼容 GitHub Actions，很多现成的 .github/workflows 文件直接挪到 .gitea/workflows 目录就能用。底层用的是基于 act 改的 act_runner。

先开开关。编辑 Gitea 的配置文件 app.ini（在 volume 的 /data/gitea/conf 下），加上：

[actions]
ENABLED = true
DEFAULT_ACTIONS_URL = github

DEFAULT_ACTIONS_URL = github 让你能直接引用 GitHub 市场里的公共 action（比如 actions/checkout@v4）。改完重启 Gitea 容器。然后准备一个 runner：去管理后台 Site Administration → Actions → Runners 生成一个注册令牌（token），在任意装了 Docker 的机器上下载 act_runner 并注册：

chmod +x act_runner
./act_runner register --no-interactive \
  --instance https://你的Gitea地址 \
  --token 你的注册令牌 \
  --name my-runner \
  --labels ubuntu-latest:docker://node:20-bookworm
./act_runner daemon

注册时给的 label（如 ubuntu-latest:docker://node:20-bookworm）意思是：当工作流写 runs-on: ubuntu-latest 时，runner 会起一个 node:20-bookworm 的 Docker 容器来执行。daemon 启动后，runner 就在线待命了。生产环境建议用 systemd 或 Docker 把它做成后台常驻服务。

然后在你的仓库里建 .gitea/workflows/ci.yaml，写一个最简单的"push 后自动测试"：

name: CI
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test

把这份文件推上去，Actions 标签页就会自动出现运行记录：每次 push，runner 拉起容器、装依赖、跑测试，绿了才算过。这体验和 GitHub Actions 几乎一模一样，但 runner 在你自己机器上，隐私和可控性拉满。敏感信息（如部署密钥、Registry 密码）放进仓库 Settings → Actions → Secrets，工作流里用 secrets.变量名 引用，不会明文进代码。

想再进一步，还能写部署流水线：测试通过后打 Docker 镜像、推到私有 registry、再 SSH 到目标机 docker compose up -d，一套属于你自己的轻量 DevOps 就成型了。相比 GitLab 那套吃掉几 GB 内存的 CI，Gitea Actions + 一个小 runner 在小鸡上跑得毫无压力。

七、总结：小鸡的正确打开方式

回到开头那个坑：别拿 GitLab 为难你的小内存 VPS。要"自己的 GitHub"，Gitea / Forgejo 是更聪明的解法——几十 MB 内存、1 核 512MB 就能跑，Docker 一键起，SSH 密钥 + 私有库 + 团队权限一应俱全，再配上兼容 GitHub Actions 语法的 Gitea Actions，连 CI/CD 都白送。把省下来的内存和预算，留给真正吃资源的业务，才是折腾党该有的清醒。

#VPS #Gitea #Forgejo #私有Git #GitLab #Docker #Actions #CI/CD #轻量部署 #小鸡