env を読めなくても、コード差し替えと再起動ができれば secrets は守れない

見える部分だけ直すのではなく、あとから困らない本番運用まで見て整える。

いま積み上げているのは、そんな改善です。

今回あらためて分かったのは、

env を直接読めないようにしていても、live code を書き換えて再起動できる構造が残っていると、secrets を間接的に引き出せる余地があるということでした。

つまり、守るべきなのは

「env を読ませないこと」だけではありません。

勝手に差し替えられないこと

勝手に再起動できないこと

ここまで含めて deploy 導線を設計しておかないと、本当の意味で安心できないと見えました。

いま取り組んでいる Agent Foundry でも、

runtime tree が dirty のままでも、deploy の正本を `/var/www/Agent-Foundry-deploy` に分けることで、より安全に運用しやすい形を作っています。

この切り分けをすると、

・どれが本番反映の基準か分かりやすい

・権限の境界を整理しやすい

・新しいアプリを増やしても運用を共通化しやすい

・あとから「この権限で大丈夫？」と不安になりにくい

というメリットがあります。

特に、

新しいアプリを増やしたい

でも本番 deploy は安全に揃えたい

そんな方には、この考え方がかなり効きます。

次に進めるなら、まずは

VPS path

runtime type

restart target

を最初に決めて、そのうえで restricted deploy scaffold を preview するところからで十分です。

最初にここを固めておくと、

後から権限設計や deploy フローがぐらつきにくくなります。

表面の修正だけでなく、

「増やしても壊れにくい運用」に整えたい方にとって、こうした設計の積み上げは大きな安心につながります。