あなた自身の Git サーバーを。
リポジトリは組織図である。

問題を解決する最小のものから始めること。その上に積むレイヤーはどれも、自分で運用しなければならないサービスになるからだ。SSH 経由のベアリポジトリは、すでに持っているサーバー上のコマンド一つで済み、認証、履歴、プッシュ権限を備えた本物の Git リモートを与えてくれる。Web アプリケーションもデータベースもアップグレードの踏み車もなく、sshd 以外にパッチを当てるものもない。ノート PC とプラットフォームからコミットを解放したいだけの一人であれば、これで完全な答えになり、ステップ02 の後は読むのをやめてよい。

# On the server, as an unprivileged user:
mkdir -p ~/git/project.git && cd ~/git/project.git
git init --bare

# On your laptop:
git remote add origin ssh://user@git.example.com/~/git/project.git
git push -u origin main

フォージが必要になるのは、二人目が関わってくるとき、あるいはベアリポジトリのディレクトリではできない4つのこと——ブラウザで履歴を閲覧すること、変更をプルリクエストとしてレビューすること、コードのそばでイシューを追跡すること、そして一人の人物に一つのリポジトリへのアクセスを許可すること——のいずれかを望むときだ。それは能力における本物の飛躍であり、運用上の重さにおいても本物の飛躍である。慎重に選ぶこと。

Forgejo と Gitea は祖先を共有しており、日常の使用では今も見分けがつかないほどよく似ている。Forgejo は2024年初頭にハードフォークとなり、ベルリンに登録された非営利団体 Codeberg e.V. が保持している。Gitea は、自らの商標を所有しコントリビューターに著作権の譲渡を求める営利企業によって開発されている。どちらも良いソフトウェアだ。ただし、その運営者のインセンティブがあなたがこのページを読んでいる理由と一致するのは、片方だけである。

このガイドの以降ではForgejoを使用する。ステップ02 から06 までの内容は、ほぼそのまま Gitea にも当てはまる——変わるのはコンテナ名といくつかの環境変数だけで、形そのものは変わらない。

Forgejo、PostgreSQL、Caddy。Forgejo はリポジトリを保持しインターフェースを提供し、PostgreSQL は Git オブジェクトでないものすべてを保持し、Caddy は TLS を終端し、二度と尋ねられることなく証明書を取得する。PostgreSQL は意図的にホストへ公開されていない——それを必要とするただ1つのコンテナから、名前を介して Compose ネットワーク経由でのみ到達可能である。

/srv/forgejo/.env

FORGEJO_DOMAIN=git.example.com
FORGEJO_VERSION=15                             # the LTS line; 16 is current stable
POSTGRES_PASSWORD=$(openssl rand -base64 32)   # paste the value, do not leave the $( )

/srv/forgejo/docker-compose.yml

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:${FORGEJO_VERSION}
    container_name: forgejo
    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: ${POSTGRES_PASSWORD}
      FORGEJO__server__DOMAIN: ${FORGEJO_DOMAIN}
      FORGEJO__server__ROOT_URL: https://${FORGEJO_DOMAIN}/
      FORGEJO__server__SSH_DOMAIN: ${FORGEJO_DOMAIN}
      FORGEJO__server__SSH_PORT: "2222"          # what clones will say
      FORGEJO__server__SSH_LISTEN_PORT: "22"     # what the container listens on
      FORGEJO__service__DISABLE_REGISTRATION: "true"
      FORGEJO__repository__DEFAULT_PRIVATE: private
      FORGEJO__security__INSTALL_LOCK: "true"
    restart: unless-stopped
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:3000:3000"    # web, reached only by Caddy
      - "2222:22"                # git over SSH, public
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    container_name: forgejo-db
    environment:
      POSTGRES_USER: forgejo
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: forgejo
    restart: unless-stopped
    volumes:
      - ./postgres:/var/lib/postgresql/data
    # No ports: block. This is the point.

  caddy:
    image: caddy:2-alpine
    container_name: forgejo-caddy
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data
      - ./caddy-config:/config

/srv/forgejo/Caddyfile

git.example.com {
    encode zstd gzip
    request_body {
        max_size 512MB          # raise it if you push large repositories
    }
    reverse_proxy 127.0.0.1:3000
}

この2つの SSH の行は、みなが間違えるところなので、二度読む価値がある。SSH_LISTEN_PORTはコンテナの内側で、Forgejo 組み込みの SSH サーバーがバインドするポートだ。SSH_PORTは Forgejo が表示するクローン URL に印字するポートで——ポートマッピングの公開側と一致していなければならない。この2つが食い違うと、ユーザーがコピー&ペーストする、まさにその一点を除いてすべてが動いてしまう。

起動し、それからコマンドラインで管理者を作成する。 Web インストーラーは使わないこと。まっさらなインスタンスでは、ホスト名を見つけた誰からでも到達可能であり、それを通じて最初に作成されたアカウントが管理者になってしまう——参加する必要のない競争だ。上のファイルにあるINSTALL_LOCKが、コンテナが起動する前にそれを閉じてくれる。

docker compose up -d
docker compose logs -f forgejo        # wait for "Starting new Web server"

docker compose exec -u git forgejo forgejo admin user create \
  --admin --username you --email you@example.com --random-password

ブラウザでホスト名を開き、表示されたパスワードでサインインしてから変更する。次に、動作するインスタンスを閉じたインスタンスへと変える設定を一通り確認する——ほとんどは上の環境変数ブロックですでに設定済みだが、思い込みではなく一つひとつ確認する価値がある。

覚えておく価値のあるパスが一つ——実運用中の設定はホスト上の./data/gitea/conf/app.iniにある。Forgejo は既存のインストールとの互換性のためにgiteaというディレクトリ名を維持しており、これは誰もが一度だけ驚く点だ。FORGEJO__section__KEYという形式の環境変数は起動時にそのファイルへ書き込まれるため、Compose ファイルから設定全体を管理できる——ただしapp.iniを手で編集した場合、同じキーの環境変数は次回の再起動時にその編集を上書きしてしまう。どちらか一方を選び、一貫させること。

Forgejo Actions は、GitHub Actions と同じ形式のワークフローファイルを.forgejo/workflows/から読み込み、Forgejo Runnerという別のプログラムに渡す。ランナーはフォージの一部ではなく、同じマシン上に置く必要もない——それがこの設計のすべてであり、このステップに肩をすくめるだけでなく警告が添えられている理由である。

インスタンス上で Actions を有効にし、それから管理パネルで登録トークンを取得する——インスタンス全体に対して、あるいは1つの組織か1つのリポジトリに限定して。確信が持てないときは後者がより良いデフォルトだ。ランナーはフォージへ向けて外向きに接続するため、受信ポートはまったく不要であり、公開アドレスを持たないマシンも含め、好きなファイアウォールの内側に置くことができる。

# In the Compose environment of the forge, or app.ini:
#   FORGEJO__actions__ENABLED: "true"
# Then: Site administration -> Actions -> Runners -> Create new runner

# On the runner machine:
forgejo-runner generate-config > config.yml

forgejo-runner register --no-interactive \
  --instance https://git.example.com \
  --token <REGISTRATION_TOKEN> \
  --name runner-01 \
  --labels docker:docker://node:22-bookworm,debian:docker://debian:12

forgejo-runner --config config.yml daemon

ラベルはワークフローとランナーの間の契約である——runs-on: docker を要求するジョブは、右辺のイメージからビルドされたコンテナを得る。実際に提供する準備があるラベルだけを宣言すること。誰も提供していないラベルを要求するジョブは、失敗するのではなく永遠に待ち続けてしまい、長い一日の終わりにデバッグするには紛らわしいものだからだ。

.forgejo/workflows/ci.yml

on: [push, pull_request]

jobs:
  test:
    runs-on: docker
    container:
      image: node:22-bookworm
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

シークレットも同じ考え方でスコープを絞る。Forgejo はそれらをリポジトリ、組織、インスタンスの各レベルで保管する。1つのリポジトリだけが必要とするデプロイキーは、そのリポジトリだけに存在させるべきであり、無関係なプロジェクトの侵害されたワークフローがそれを読み取れないようにする。対象がサポートしているならどこでも、長命なトークンより短命なトークンを優先し、ワークフローファイルには決してシークレットを置かないこと——ワークフローファイルはリポジトリの中にあり、リポジトリには履歴があるのだから。

ビルドが毎回同じベースイメージを取得するなら、キャッシュしておくこと。ローカルのレジストリミラーや永続的なランナーキャッシュは、2分かかるイメージ取得を2秒に変えてくれるし、酷使しているアップストリームのレジストリに対する礼儀でもある。そしてこの設計全体が誘っているパターンに注目してほしい。それがこのガイドがエージェントランタイムガイドの隣にある理由でもある——ランナーはあなたのフォージからジョブを取得する汎用ワーカーであり、定期メンテナンス、データパイプライン、エージェントのワークロードもまた、そこに属するものなのだ。

フォージをセルフホストすることは、あなたの成果物を誰が握るかという点での本物の変化であり、不可視になることではない。上のすべてを終えたあとも真実であり続ける4つのことがあり、それを知っているかどうかが、防御と自分に言い聞かせる物語との違いになる。

ディスクは誰かの建物の中にある。 レンタルサーバーは、扉とスタッフのいるデータセンターのハードウェア上で動いている。NordBastion は顧客のワークロードを検査しないし、透明性レポートとワラントカナリアが、もし何かを要求された場合に何が起こるかを説明している——しかし、正直なのはアーキテクチャ上の言明のほうだ。変わるのは、あなたのリポジトリの製品レベルのインデックスも、あなたのコミットに対する分析パイプラインも、改定されうるプライバシーポリシーも存在しないということ。変わらないのは、マシンが物理的であり、あなたの家の中にはないということだ。

証明書が発行された瞬間、ホスト名は公開される。 信頼された証明書はすべて、誰でも検索できる証明書透明性ログに公開されるため、一度もリンクしたことがなくても git.yourproject.com は発見可能だ。それはコードの漏洩ではないが、プロジェクトが存在し、おおよそいつ始まったかという事実の漏洩ではある。すでに公開している名前のサブドメインを使うか、公開証明書を完全に省略して WireGuard かオニオンサービス経由でフォージに到達すること。

あなたは今や、Web アプリケーションにパッチを当てる立場にある。 フォージは、ログインページ、信頼できないマークアップのレンダリングパイプライン、SSH サーバー、CI エンジンであり、そのすべてがインターネットから到達可能だ。それはステップ01 のベアリポジトリよりもかなり大きな表面積であり、常に最新の状態を保たなければならないものでもある。リリースアナウンスを購読し、セキュリティリリースは四半期単位ではなく週単位の仕事として扱うこと。

フェデレーションはまだここにはない。 Forgejo はフォージ間フェデレーションについて実際に作業を進めており、その進捗も公開しているが、今日の時点では、共有プラットフォームでできるように自分のインスタンスから他人のインスタンスへプルリクエストを開くことはできない。実務上それは、外部の貢献者には依然としてあなたのフォージ上のアカウントが必要であるか、パッチをメールで受け取るか、ふらりと現れる貢献のために公開ミラーを維持するか、のいずれかを意味する。驚かされるのではなく、この3つのうち自分のプロジェクトに合うものを計画しておくこと。

実際に手に入れたものを正確に言えば——あなたが何を、誰と、いつ作っているかという日付入りの記録は、それを分析することがビジネスモデルに含まれる企業にはもはや握られていない。それは限定的な主張であり、同時に本物の主張でもある。それがその代償に見合うのは、ステップ06 が完了している場合に限られる——検証済みの復元を持たないセルフホストのフォージは、プライバシーの改善ではなく、ブランディングだけが優れた単一障害点である。