環境変数

デプロイ時にアプリの環境変数がGitHub secretからRailwayに流れる仕組み。

アプリはランタイムでRailwayからprocess.env.Xで環境変数を読みます。しかしアプリのコード、GitHubリポジトリ、Railwayサービスは3つの別の場所です — そこで厄介なのが「GitHubに保存したシークレットがどうやってRailwayに届くのか」という問題です。このページではそのパイプラインを説明します。

3つの場所

デプロイワークフローが3つの橋渡しをします。

マッピングファイル

各アプリのdeploy.config.ymlにはsecrets:ブロックがあります。左側がランタイムでアプリが見る変数名、右側がGitHubキー名です:

serviceId: "training-tracker"
rootDir: "apps/training-tracker"
secrets:
SLACK_BOT_TOKEN: "TRAINING_TRACKER_SLACK_BOT_TOKEN"
SLACK_WEBHOOK_URL: "TRAINING_TRACKER_SLACK_WEBHOOK_URL"
SLACK_CHANNEL: "TRAINING_TRACKER_SLACK_CHANNEL"
SLACK_SIGNING_SECRET: "TRAINING_TRACKER_SLACK_SIGNING_SECRET"

ランタイムで、training-trackerアプリのprocess.env.SLACK_BOT_TOKENはGitHubにTRAINING_TRACKER_SLACK_BOT_TOKENとして保存された値を読みます。

アプリごとのワークフローが値を渡す

各アプリのステージング/本番ワークフローが、GitHubの値を再利用可能なデプロイワークフローに転送します:

secrets:
SLACK_BOT_TOKEN: ${{ secrets.TRAINING_TRACKER_SLACK_BOT_TOKEN }}
SLACK_WEBHOOK_URL: ${{ vars.TRAINING_TRACKER_SLACK_WEBHOOK_URL }}

• 機密値には${{ secrets.X }}を使います。
• 非機密設定（チャンネル名、フィーチャーフラグなど）には${{ vars.X }}を使います。

命名パターン

30以上のアプリをまたいでGitHub変数が衝突しないように、アプリ名のsnake_caseプレフィックスを付けます:

{APP_NAME_SNAKE}_{VAR_NAME}

例: BREAKFAST_TRACKER_SLACK_WEBHOOK_URL, RECRUIT_ASHBY_API_KEY, STAFF_MEAL_TRACKER_OPENAI_API_KEY。

命名規則も参照。

新しい変数を追加するチェックリスト

1. GitHubキーを正しい環境（stagingまたはproduction）にsecretまたはvarとして追加。
2. apps/<your-app>/deploy.config.ymlのsecrets:にマッピングを追加。
3. deploy-app-<app>-staging.ymlとdeploy-app-<app>-production.ymlの両方で値を転送。
4. デプロイを起動し、Railwayサービス環境に変数が現れることを確認。

自動注入される変数（マッピング不要）

以下は宣言不要です — プラットフォームが提供します:

• DATABASE_URL — 環境のデータベースサービスから。
• AUTH_UI_URL — 非認証サービスすべてに。
• BUCKET_* — 共有Railwayバケットのストレージ認証情報。ファイルストレージでバケット作成とGitHubキー（BUCKET_ENDPOINT、BUCKET_ACCESS_KEY_ID、BUCKET_SECRET_ACCESS_KEY、BUCKET_NAME、BUCKET_REGION）の設定方法を参照。

Claudeに聞く

トラブルシューティング

GitHub secretの追加方法が分からない場合は、進める前に開発者に相談してください。

クイズ