Discourse チームからは連絡がありませんでした（おそらくこの機能はプロジェクトの複雑さを増すものかもしれませんが、私はごくわずかだと考えています）。そのため、現時点では何もありません（ただし、上記の方法は公式の discourse_docker リポジトリに含まれていなくても動作するはずです）。
@justin 実際、私の主な目的はダウンタイムの最小化ではなく、Ruby の gems、プラグイン、そして Discourse リポジトリがすでにインストールされたベースイメージを維持することです。このイメージは、ステージングや本番環境など、異なる環境で、あるいは同じプラグインを使用する異なるプロジェクトでも利用可能です。ターゲットマシンで実行する必要があるデータベースマイグレーションとアセットのプリコンパイルタスクのみを実行すればよく、Discourse のアップグレード時の問題を防ぐことができます。
ダウンタイムの削減は、副次的な効果であり、歓迎すべきものです。とはいえ、最終的にはこの機能を採用するかどうかは Discourse チーム次第ですが、私は非常に喜ばしく思います。