見える形で積み上げているのは、「動けばいい」では終わらせない運用設計です。
今回あらためて見えたのは、
env を直接読めないようにしていても、live code を書き換えて再起動できる構造が残っていれば、secrets を間接的に引き出せる余地があるということでした。
この気づきは、単なるセキュリティの話ではありません。
アプリを増やしても、安心して運用を広げられる土台をどう作るかという話だと感じています。
いま取り組んでいるのは、Agent Foundry の deploy 設計です。
runtime tree が dirty のままでも、deploy の正本を /var/www/Agent-Foundry-deploy に分けることで、安全に運用できる形を整えています。
この切り分けを入れることで、
- 本番反映の基準が明確になる
- deploy 権限の境界を整理しやすくなる
- runtime 側の変更と正式な配備を分けて考えられる
という状態に近づけます。
今の判断軸は、とてもシンプルです。
secrets を守るには「読めないこと」だけでは足りない。
「勝手に差し替えられないこと」「勝手に再起動できないこと」まで含めて、deploy 導線を設計する必要がある。
この考え方があるだけで、
新しいアプリを増やすときも、毎回ゼロから不安にならずに済みます。
運用判断が軽くなり、チームで共通ルールを持ちやすくなるのも大きなメリットです。
次に進めるのは、
新規プロジェクトでは最初に VPS path、runtime type、restart target を決めてから restricted deploy scaffold を preview すること。
最初にここを決めておくと、後から権限設計や deploy フローが崩れにくくなります。
結果として、開発スピードと本番運用の安全性を両立しやすくなります。
こういう取り組みに価値を感じるのは、
新しいアプリを増やしながら、本番 deploy を安全に共通化したい人だと思っています。
派手な機能追加だけではなく、
増やしても壊れにくい運用の土台を、一緒につくっていける方と相性がよさそうです。
