設定(データベース URL、API キー、ポート、フィーチャーフラグ)は、ハードコードせず、環境変数の中のコードの外に置くべきです。これによりシークレットをソース管理の外に保ち、同じコードを異なる設定で dev、staging、production で実行できるようになります。
原則: 設定は環境から取得する
js
dbUrl = ;
dbUrl = process..;
port = process.. || ;
これは twelve-factor app の原則に従っています。設定とコードを厳密に分離することで、新しい環境へのデプロイはコードではなく環境変数の変更で済みます。
# .env — ローカルの値、GITIGNORE 対象(決してコミットしない)
DATABASE_URL=postgres://localhost/myapp_dev
JWT_SECRET=dev-secret
PORT=3000
// .env を process.env に読み込む(旧: dotenv、新しい Node: --env-file フラグ)
import "dotenv/config"; // または: node --env-file=.env app.js
const secret = process.env.JWT_SECRET;
.env ファイルはローカルの設定を保持します。必ず gitignore する必要があります。何が必要かを文書化するために、(キーはあるが実際の値は含まない).env.example をコミットしましょう。
import { z } from "zod";
const env = z.object({
DATABASE_URL: z.string().url(),
JWT_SECRET: z.string().min(16),
PORT: z.coerce.number().default(3000),
}).parse(process.env); // ❗ 設定が欠落 / 不正なら起動時に即座に失敗させる
起動時に環境変数を検証する(zod/envalid を使う)と、シークレットの欠落や不正があれば明確なメッセージとともに即座にクラッシュします。リクエストの奥深くでわかりにくいランタイムエラーになるより、はるかに優れています。
開発: .env ファイル(gitignore 対象)
本番: プラットフォーム / オーケストレータによって注入される —
クラウドのシークレットマネージャー(AWS Secrets Manager、GCP Secret Manager、Vault)、
コンテナ / オーケストレータの環境変数、CI/CD のシークレット。
本番のシークレットを、コミットされた、またはアプリと一緒に出荷される .env ファイルに決して置かない。
// config.js — アプリがインポートする、検証済みの単一の設定モジュール(process.env をあちこちに散らさない)
export const config = { dbUrl: env.DATABASE_URL, port: env.PORT };
適切な設定とシークレットの管理は、セキュリティ上も運用上も必須です。
シークレットをハードコードするとバージョン管理に漏洩します(深刻でよくある侵害です)。設定をコードに混ぜると、環境をまたいだデプロイが苦痛になります。
標準的なアプローチ — 環境変数、ローカル開発用の gitignore された .env、文書化のための .env.example、起動時の検証、本番でのプラットフォームのシークレットマネージャー — は、シークレットを安全に保ち、アプリを環境間で可搬にし、設定ミスを早期に表面化させます。
これは Node アプリを責任もって運用するための基礎です。