環境の種類

Astar Management には大きく 2 つの実行環境があります。ローカル開発の起動手順そのものは はじめに / dev-loop にあります。ここでは「何が local と本番で違うか」「なぜそうなっているか」を整理します。

ローカル開発環境（worktree slot）

複数の git worktree を並行して動かせるよう、worktree ごとに 0〜9 の "slot" が割り当てられ、ポート・DB・キャッシュがすべて分離されます（infrastructure/local/worktree-env.sh）。

• 共有 PostgreSQL コンテナ: astarmanagement-postgres-dev（infrastructure/local/docker/postgresql/）が全 worktree で共有され、worktree ごとに別データベース（例: astarmanagement_dev_wt1）が作られます（infrastructure/local/worktree-db.sh）。init スクリプトが拡張機能と app_user ロールを作成し、以降のマイグレーションは Spring Boot 起動時の Flyway が担当します。
• ポート: 直接アクセスは http://localhost:{3000+slot}（frontend）/ http://localhost:{8080+slot}（backend）。Caddy プロキシ経由なら名前付き URL http://{worktree}.localhost:1355（frontend）/ http://api-{worktree}.localhost:1355（backend）が使えます。
• 周辺サービス（infrastructure/local/docker/storage/）: MinIO（オブジェクトストレージ）、fake-gcs-server（GCS 互換モック）、Mailpit（送信メールのキャプチャ・確認）、GreenMail（IMAP/SMTP テストサーバー）、Kreuzberg（OCR/テキスト抽出）をコンテナで用意しています。

本番環境

本番は GCP + Cloudflare のハイブリッドです。全体構成は前ページ インフラとデプロイ を参照。ここで押さえておくべき差分:

• api.astarworks.com は Cloudflare Tunnel 経由（GCE VM 上の cloudflared コンテナが localhost:8080 へブリッジ）。Tunnel にはリクエストボディ 100MB の上限があり、これを超えるアップロードはオリジン側に痕跡を残さず失敗します。大きなファイルの取り扱いを設計するときはこの制約を前提にしてください。
• バックエンドは Cloud Run ではなく GCE VM（コスト最適化のため 2026-03-17 に移行）。常時起動ワークロードは Cloud Run より GCE の方が安いという判断です。重い/バースト処理（OCR・Office変換・PDF出力）だけが個別の Cloud Run サービスに切り出されています。
• フロントエンドは Cloudflare Pages。ghcr.io に push される frontend の Docker イメージは本番配信には使われず、self-host 用 Kubernetes/Helm チャートの専用ビルドです（次ページ参照）。

リリースとバージョンの基点

• リリースは /release skill による git tag (vX.Y.Z) の push で開始します（詳細は インフラとデプロイ の「リリースパイプライン」節）。
• バージョンの基点は 直前の vX.Y.Z タグの系列です。origin/main の最新コミットを基点だと思い込まないこと — ローカル main が origin より意図的に進んでいる（未 push の作業がある）状態は珍しくありません。