環境の種類

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

ローカル開発環境（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/テキスト抽出）をコンテナで用意しています。

staging 環境

main pushで、backend imageとCloudflare Pagesを app-staging.astarworks.com / api-staging.astarworks.com へ自動配信します。typecheck/testはこのdeploy laneに 置かず、build失敗またはbackend不健康時は直前のbundle/Pages deploymentを残して Discordへ通知します。本番とは次の境界を持ちます。

• GCE VM astar-staging-backend と /opt/astar-staging、Cloud SQL astar-postgres 内の別DB astarmanagement_staging
• Secret Managerの staging- prefix、Cloudflare Pages astar-frontend-staging
• 同一Auth0 tenant内のstaging web/desktop/CLI client 3本。production clientへのfallbackなし
• R2 documentsは tenant/staging key prefix、GCSのdocuments/STT bucketとScheduler/Tunnel/DNSはstaging専用
• Tauriは Astar Staging、identifier com.astarworks.astar.staging（tauri.staging.conf.json）

Discord、Google OAuth、メール同期などの外向き連携は専用credentialを使い、未プロビジョン ならdeployを成功扱いにしません。共有による本番側への二重反応を防ぐため、未設定の 連携は本番credentialへfallbackしません。

本番環境

本番は 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 の作業がある）状態は珍しくありません。