自架 Git 服務完整教學 2026：Gitea vs Forgejo vs GitLab CE 該選誰？Docker 部署、Actions CI/CD、從 GitHub 遷移與備份一次學會

結論先講：5 人以下的小團隊或個人開發者，選 Gitea（最低 512MB RAM、MIT 授權、開箱即用）；在意治理透明、資料主權與長期維護節奏的組織，選 Forgejo（非營利 Codeberg e.V. 治理、100% 自由軟體、LTS 分支）；30 人以上、需要內建 SAST/DAST 與完整 DevSecOps 的企業，才值得付 GitLab CE 那 4 到 8GB RAM 的代價。

為什麼 2026 年自架 Git 突然變成熱門題目

過去自架 Git 是「有法遵要求的企業才會做的事」，2026 年變成一般開發者也會認真考慮的選項，原因是三股壓力同時擠上來：

1. GitHub 對大型組織的定價上升，而自架的成本幾乎只跟機器規格有關——10 人或 100 人，一台中階 VPS 的月費差距不大。
2. 原始碼被拿去訓練 AI 的疑慮。Gentoo Linux 在 2026 年 2 月宣布在 Codeberg 建立官方據點，維護者直接點名 GitHub 推動強制 Copilot 整合是動機之一。
3. 歐洲數位主權政策。最具代表性的案例是荷蘭政府的 code.overheid.nl——一套專門用來讓政府原始碼離開美國管轄基礎設施的 Forgejo 實例，任何政府組織都能使用。

這三股力量讓「程式碼放在誰的機器上」從技術細節變成治理問題。而 Gitea、Forgejo、GitLab CE 正好佔據了「極簡輕量」到「功能全餐」之間的三個不同位置。

三者是什麼？一張表先看懂定位

Gitea：輕量的原點，也是大多數人的答案

Gitea 是從 Gogs 分家出來的專案（2016 年），定位從第一天就很清楚：用一台樹莓派就能跑的 GitHub 形狀 Git 伺服器。它是單一 Go 二進位檔，搭配 SQLite 就能啟動，冷啟動不到一秒。

官方安裝文件的硬體要求相當客氣：最低 1 核心 CPU、512MB RAM、100MB 磁碟（不含 repo 本身）；正式環境建議 2 核心以上、2GB RAM 以上並使用 SSD。實務上剛裝好的實例閒置大約只吃 150MB 左右。

這幾年補齊的功能也不少了：

• Gitea Actions（v1.21 起）：與 GitHub Actions 相容的 runner，這是它最好用的殺手級功能。
• 套件倉庫：npm、Maven、Container、Helm 等 registry。
• Issue、PR、Wiki、Release、Label 的內建匯入器：從 GitHub 搬家幾乎是填個表單的事。

Forgejo：從 Gitea 分家到硬分叉，治理才是賣點

Forgejo 在 2022 年底誕生，一開始是 Gitea 的 soft fork，訴求是「由非營利組織治理，而不是公司」。到了 2024 年初，專案決定升級成 hard fork——不再保證與 Gitea 的 drop-in 相容，換來的是能用自己的節奏清技術債。

它跟 Gitea 的差異主要在四個地方：

1. 治理與透明度：由 Codeberg e.V. 這個非營利組織控制，決策流程公開可稽核，資金來源也公開揭露。Forgejo 自己的比較頁就把「民主決策」「激進透明」列為與 Gitea 的核心差別。
2. 100% 自由軟體：Forgejo 官方指出 Gitea 的雲端版本含有部分未開放的程式碼，因此把它歸類為 Open Core；Forgejo 則堅持全部自由軟體。
3. LTS 分支：Forgejo 在 2026 年 3 月切出 v15.0 LTS，之後推進到 v16 系列（目前 v16.0.5，2026-09-17 發布）。對公部門與企業來說，LTS 是能不能採用的關鍵。
4. Forgejo Actions 與 runner：CI 系統從早期的 Woodpecker 一路演進，runner 本身也是硬分叉版本；另外還有 ForgeFed 聯邦化的實驗在跑。

實際案例很有說服力：荷蘭政府選了它，Fedora 也選了它。

GitLab CE：不是 Git 伺服器，是整套 DevOps 平台

GitLab 是完全不同的生物。它不是「一台 Git 伺服器加上一些功能」，而是「Git 伺服器本身就是整套平台的一個模組」——裡面有 CI/CD、容器 registry、Issue 追蹤、Wiki、安全掃描、Kubernetes 整合。

代價是架構重量：Ruby on Rails 單體應用，最低 4GB RAM 起跳，而且不是只有它自己——還要 Postgres、Redis、Gitaly、Sidekiq worker 一起跑。官方 Omnibus 安裝包把這些複雜度藏起來了，但資源帳單不會消失。其他來源的測試提到，GitLab CE 要「舒服地開機」大約需要 16GB RAM 與 8 個 vCPU。

什麼時候該選它？當你：

• 有 20 位以上開發者，而且希望 CI、registry、code review 在同一套工具裡完成
• 已經受不了自己把 Gitea + Drone + Harbor + 另一個 Issue tracker 縫起來
• 法遵稽核要求內建 SAST/DAST 這類掃描能力

反過來說，三個人的 side project 選 GitLab，就是每個月替那 4GB 的閒置記憶體付錢。

成本比較：8 倍 RAM 差距反映在月費上

對照台灣的 VPS 價格，Gitea／Forgejo 大多落在每月 5 到 15 美元的區間就能跑得很順；GitLab CE 則通常需要 16GB 的方案才不會 OOM。同一份工作負載，GitLab 的基礎設施成本大約是 Gitea 的三倍。

實戰：用 Docker Compose 部署 Forgejo

以下是 Forgejo 官方文件的 compose 範例，SQLite 版本最小可用：

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

啟動後打開 http://localhost:3000 走完初始化精靈即可。有兩件事一定要記住：

• volume 的擁有者必須符合 USER_UID／USER_GID，權限不對容器會直接起不來。
• SSH 走的是 222 埠，驗證方式：ssh -F /dev/null git@<address> -p 222。

要換成 PostgreSQL 的話，只要加上這幾行（官方文件用 diff 呈現，我省略了其餘不變的部分）：

services:
  server:
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=forgejo
    depends_on:
      - db

  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=forgejo
      - POSTGRES_DB=forgejo
    networks:
      - forgejo
    volumes:
      - ./postgres:/var/lib/postgresql/data

這裡有個很實用的技巧：所有 app.ini 的設定都能用 FORGEJO__[SECTION]__[KEY] 形式的環境變數覆寫。例如 FORGEJO__repository__ENABLE_PUSH_CREATE_USER=true 就等於在 app.ini 的 [repository] 段寫 ENABLE_PUSH_CREATE_USER = true。DEFAULT 段則用空字串表示，例如 FORGEJO____APP_NAME=。注意環境變數只能新增或修改，沒辦法用來刪掉既有值，那要直接改 app.ini。

Gitea 的 Docker Compose（對照用）

Gitea 官方版幾乎一模一樣，差在映像檔名稱與多掛了一個 timezone：

networks:
  gitea:
    external: false

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

要提醒一點：rootful 與 rootless 映像檔彼此不相容，選定一種就要一直用同一種，不要中途改 compose 裡的 image 值。外部連線建議配上 Cloudflare Tunnel 把服務安全搬上網，就不用為了自架 Git 去開防火牆埠。

Actions：Gitea 與 Forgejo 的 CI 到底有多「GitHub 相容」

這是很多人選 Gitea/Forgejo 的真正理由。Gitea Actions 在 v1.21 登場時，主打的就是跑得動 GitHub Actions 的 workflow YAML。實務上的意思是：

# 原本在 GitHub
.github/workflows/ci.yml

# 搬到 Gitea / Forgejo
.gitea/workflows/ci.yml     # 或 .forgejo/workflows/ci.yml

多數情況下只需要改路徑與 runner 設定，工作流程本身幾乎不動。如果本來就在寫 GitHub Actions，站上的 GitHub Actions 完整教學 可以直接沿用。

runner 的安裝重點：

1. runner 預設會與 Git 服務共用主機資源，正式 CI 負載建議放到另一台 VM 遠端註冊。
2. 在 Gitea 後台建立 runner registration token，再用官方 act_runner（Forgejo 為 forgejo-runner）註冊。
3. 記得在 app.ini 開啟 Actions 功能，否則 runner 註冊了也不會被派工。

GitLab CI 則是另一條路：.gitlab-ci.yml 的語法、runner 模型與 Gitea/Forgejo 完全不同，兩者之間沒有低成本的自動轉換方式。這也是「一開始就選對」比「之後再換」便宜的重要原因。

從 GitHub 搬家：實際會遇到什麼

想無痛搬家的話，建議先用**鏡像（mirror）**模式跑一段時間：在 Gitea/Forgejo 建立 mirror repo 指向 GitHub，兩邊同步驗證 CI 都能跑，確認沒問題再切換團隊的 remote。離開得早，永遠比離開得晚便宜。

備份與升級：dump 指令是核心

Gitea 提供 dump 指令，會把整份安裝打包成一個 ZIP。關鍵前提是備份期間必須停掉服務——因為資料庫、檔案與 Git 儲存庫三者都在變動，如果在 migration 進行中備份，資料庫會說 OK 但 repo 其實是半殘的，這種競態只有停機才能避免。

# 切到跑 Gitea 的使用者
su git
./gitea dump -c /path/to/app.ini

產出的 ZIP 內容包括：app.ini、custom/、data/、repos/、gitea-db.sql，以及 log/（還原時不需要）。Forgejo 沿用同一支指令（forgejo dump），流程相同。

資料庫建議用原生工具另外備份：官方文件明確指出 gitea dump 產生的 SQL 是用 XORM 匯出的，還原時仍有已知問題，所以 MySQL 請用 mysqldump、PostgreSQL 請用 pg_dump。

Docker 環境下跑 dump 有兩個小坑：必須用 app.ini 裡 RUN_USER 指定的使用者身分執行，而且 docker exec 的工作目錄要設在 --tempdir 裡，否則打包會撞到權限錯誤。

還原時記得重新產生 Git hooks：

./gitea admin regenerate hooks   # 安裝方式或路徑改變時必做
./gitea doctor check --fix       # 卡住時的診斷工具

升級路徑方面，Forgejo 官方明確說明：從 X 升到 X+1（例如 15 升 16）需要手動操作與人工驗證，不能無腦換 tag；但使用 16 這種 tag 可以自動拿到最新的小版本。Gitea 則維持每月左右的 patch 節奏。

三個最常見的踩坑

1. 反向代理後 ROOT_URL 沒設對。這是最常見的第一次架設失敗原因——webhook 會帶著錯誤的 hostname 回呼。在 app.ini 把 ROOT_URL 設成對外網址即可。
2. GitLab Omnibus 在小機器上被 OOM kill。Sidekiq 在負載下很吃記憶體，先加 RAM 再談其他優化。
3. GitLab 容器 registry 的 layer 堆積。第一天上線就設定清理政策，不然三個月後會醒來發現磁碟滿了。

選擇建議：用團隊規模決定

最後一個實務建議：如果你打算有一天要離開 GitLab，提早離開比晚離開便宜。歷史越長、Issue 與 MR 越多，搬家的腳本就越難寫。反過來說，如果你已經在用 Coolify 這類自架部署平台，Gitea/Forgejo 幾乎可以直接接上它的 Git 來源，形成一套完全自主的開發到部署鏈。

延伸閱讀

• Cloudflare Tunnel 完整教學 2026：不開防火牆 port 也能把自架服務搬上網
• Coolify 完整教學 2026：62K 星開源自架版 Vercel／Heroku，Git Push 自動部署
• GitHub Actions 完整教學 2026：免費 CI/CD 自動化
• Docker 完整教學 2026：從安裝、Dockerfile 到 Compose 實戰
• 自架 S3 物件儲存完整教學 2026：MinIO 社群版停止維護後該選誰
• Tailscale 完整教學 2026：36K 星 WireGuard Mesh VPN

原始來源

• Gitea 官方文件：Installation with Docker
• Gitea 官方文件：Backup and Restore（dump 指令）
• Forgejo 官方文件：Installation with Docker
• Forgejo 官方文件：Comparison with other Forges
• Forgejo 官方部落格：Forgejo forks its own path forward（硬分叉決策）
• Gitea GitHub Repository（stars／forks／授權）
• Codeberg：forgejo/forgejo Repository（stars／版本）
• Tech Insider：Gitea vs Forgejo vs GitLab CE 2026: 8x RAM Gap
• Elestio Blog：Gitea vs GitLab: Which Self-Hosted Git Server in 2026?