@Stephen あなたの議論には欠陥があります。マルチコンテナの説明には、更新の責任を自分が負い、仕組みを理解する必要があるという警告が満載であり、上記の長い説明はあまりにも難解で、それを見た人は誰でも諦めてしまうでしょう。私の Migrate quickly to separate web and data containers を読んで、それを読めば混乱する人々を遠ざけてしまうこと、あるいは万が一の際にバックアップの必要性と、何か問題が起きた場合にバックアップに戻れる能力を強調していないことを否定してみてください。
セキュリティ修正のために機能性の高いサーバーに移行した直後に ./launcher rebuild app を実行した際、サイトが非常に長い間ダウンし、その大部分がコンテナ内の PostgreSQL 部分の再構築に費やされました。その時に 2 コンテナのドキュメントとこのドキュメントを見つけ、4 時間のダウンタイムを再び避けるために、復元に 4 時間かかることを避けるため、./launcher rebuild app による長いダウンタイムを繰り返し受けることになりました。ある程度有能な人間として、この設定が事実上隠されていたことに長い間非常に腹が立ちました。
PostgreSQL 12 のトピックは優れた参考資料です。なぜなら、人々は 全体 のアプリを複数回再構築しなければならないため、かえって より ダウンタイムが長くなるからです。本来なら PostgreSQL コンテナを 2 回だけ再構築すれば済むはずなのにです。6 日間の自動削除機能のためスレッド全体を読んだわけではありませんが、そこでの大きな問題は、無能なマルチコンテナデプロイである、あるいは少なくとも大きな問題の一つであるとは全く思えません。
（申し訳ありませんが、ここでは「すべてのユーザーが無能である」という雰囲気に時々疲れ果ててしまいます。）