dotenvx、ありがとう
dotenv
の改良版である dotenvx
が使ってみてめっちゃ良かったので紹介します。
特徴
特に大きいのは「環境変数の暗号化」と「複数 .env
ファイルへの対応」の2つです。
環境変数の暗号化
dotenvx 経由で環境変数をセットすることで、環境変数が公開鍵暗号方式で暗号化されます。
dotenvx set -f .env.development API_ENDPOINT https://example.com/graphql
#/-------------------[DOTENV_PUBLIC_KEY]--------------------/
#/ public-key encryption for .env files /
#/ [how it works](https://dotenvx.com/encryption) /
#/----------------------------------------------------------/
DOTENV_PUBLIC_KEY="03f8b376234c4f2f0445f392a12e80f3a84b4b0d1e0c3df85c494e45812653c22a"
API_ENDPOINT="encrypted:BD9paBaun2284WcqdFQZUlDKapPiuE/ruoLY7rINtQPXKWcfqI08vFAlCCmwBoJIvd2Nv3ACiSCA672wsKeJlFJTcRB6IRRJ+fPBuz2kvYlOiec7EzHTT8EVzSDydFun5R5ODfmN"
暗号化用の公開鍵は上記のように .env
ファイルに同梱、秘密鍵は.env.keys
というファイルで保管されます。
#/------------------!DOTENV_PRIVATE_KEYS!-------------------/
#/ private decryption keys. DO NOT commit to source control /
#/ [how it works](https://dotenvx.com/encryption) /
#/----------------------------------------------------------/
# .env.production
DOTENV_PRIVATE_KEY_PRODUCTION="bd7c50b352ce23973ec9db355d70212305a0baaade92f0165f02915b213bfbe2"
(公式ドキュメントから拝借)
dotenvx
経由で各種動作を実行することで、復号された環境変数が読み込まれます。
dotenvx run -f .env.development -- next build # API_ENDPOINT=https://example.com/graphql で動く
.env
ファイルへの対応
複数 .env.development
.env.staging
.env.production
など環境ごとに対応する複数の .env
ファイルを、下記のような形で柔軟に出し分けをすることができます。
dotenvx run -f .env.staging -- next build
何が嬉しいか
「環境変数の暗号化」と「複数 .env
ファイルへの対応」によって、秘密鍵さえ適切に管理しておけばすべての環境変数を安心してgit管理することができます(.env.keys
は必ず.gitignore
し、中身は安全な場所で保管しましょう)。
そうすると、環境変数の管理が劇的に改善するんです。
環境変数の管理にはときたま悩まされますよね。例えばこんなお悩みに直面したことはありませんか?
- うまく動かないと思ったら環境変数をタイポしてた
- うまく動かないと思ったらいつかの.env.localが上書きしてた
- うまく動かないと思ったらいつの間にか環境変数が変更/追加になってた
- 新しく入ったプロジェクトの管理が杜撰で、必要な環境変数がどこにあるかわからない
- 「機密性の高い環境変数が変更/追加になったんで、各自適切に更新しておいてください!」(めんどい)
git pull
で必要な環境変数がすべて手に入り、.env
にそれ以上触る必要がなければ、上記のようなお悩みが全部なくなります!
これがまた、ほんとに、ありがたいんです。
自分も最初は「暗号化?へー、そうなんや」くらいの気持ちで導入してみたのですが、実際に体験してみると「環境変数を全部git管理できるのって、こんなに快適なんだ…!」と驚きました。
環境変数周りで煩わされるのって非生産的すぎてほんとに萎えるので…「dotenvxほんまありがとう」の気持ちです☺️
デメリット
暗号化によってちょっとめんどうなところもあります。
パッと見で何が入ってるかわからん
例えば「APIのエンドポイント、ちゃんと開発環境のやつになってるかなー?」と.env.development
を開くと
API_ENDPOINT="encrypted:BD9paBaun2284WcqdFQZUlDKapPiuE/ruoLY7rINtQPXKWcfqI08vFAlCCmwBoJIvd2Nv3ACiSCA672wsKeJlFJTcRB6IRRJ+fPBuz2kvYlOiec7EzHTT8EVzSDydFun5R5ODfmN"
となっていて、全然わかりません。
中身を見るためには
dotenvx get API_ENDPOINT -f .env.development
などのようにする必要があり、ちょっとめんどうです。
全てに復号処理がつきまとうのでCIとかちょっとめんどう
単に「GitHub Actionsでビルドする」とかでも「Secretsに秘密鍵を登録して〜、コマンドで秘密鍵渡して〜」となるのでちょっとめんどうです。
- name: Run next build (dev)
run: DOTENV_PRIVATE_KEY_DEVELOPMENT=${{ secrets.DOTENV_PRIVATE_KEY }} pnpm run build:dev
大体は最初の1回で済みますが、環境の数だけその作業が発生します。
「過剰だよー、うちにはそんなの必要ないよー」という意見もありそうですが、.env
ファイルの出し分けや機密性の高い環境変数の管理は遅かれ早かれ必要になるもの。プロジェクトの最初にdotenvx
を設定しておいて、長期的に見て楽ができるといいですね。
“Run Anyware” を謳っていていろんな環境で使えるみたいなので、ぜひお手元のプロジェクトに導入してみてください!
途中から導入するのも簡単です✨
$ dotenvx encrypt
✔ encrypted (.env)
おまけ:設定例
"scripts": {
"dev": "dotenvx run -f .env.development -- next dev",
"dev:stg": "dotenvx run -f .env.staging -- next dev",
"dev:prod": "dotenvx run -f .env.production -- next dev",
"build": "dotenvx run -f .env.production -- next build",
"build:dev": "dotenvx run -f .env.development -- next build",
"build:stg": "dotenvx run -f .env.staging -- next build",
"setenv:dev": "dotenvx set -f .env.development",
"setenv:stg": "dotenvx set -f .env.staging",
"setenv:prod": "dotenvx set -f .env.production"
},
Discussion