しかし、この場合、bootstrap ステップは本番環境のサーバーで実行されなければなりません。これは、コンテナレジストリにベースイメージをプッシュするという目的をむしろ損なうことになります（私の認識が正しければ）。なぜなら、本番環境でイメージを bootstrap する必要性をなくすことが意図されているからです（データベースのマイグレーション実行など、ごく一部の処理を除いて）。
私がホストしている Discourse 以外のサイトでは、通常、Flyway を使ってデータベースのマイグレーションを実行し、Redis キャッシュのクリアなどの他の処理も行います。ただし、外部サービスに依存する重い処理は避けます。例えば、HTTPS 証明書の更新（初回のみ例外として cronjob で実施）や、コードベースの変更（イメージ内で静的にパッケージ、ライブラリなどを固定）などです。Discourse が Rake を使用しているのは問題ありませんが、Gem のインストール、アセットの生成、MaxMind DB の更新、あるいは他のサービスへの依存など、他の処理も含まれています。これらは、例えばサービスがダウンしている場合や API が変更された場合（稀ですがあり得ます）、ビルドステップを失敗させる可能性があります。
もちろん、Discourse がそのような方法を採用すべきだと言っているわけではありません。CI 環境でイメージを生成し、ステージング/本番サーバーでデータベースのマイグレーションステップを実行し、環境変数を設定するというアプローチは、WordPress、MediaWiki、Rocket.Chat などの他のソフトウェアでは容易に実現可能です。Discourse はフォーラムソフトウェアとして最高だと思いますし、彼らが現在の方法を採用しているのには良い理由があるかもしれません。しかし、現時点では、手間を避けるために標準インストール（またはマルチコンテナインストール）のみを使用し、ビルド時に何か問題が起きないことを祈るしかありません。
どうやら、bootstrap は依然として本番環境で行う必要があり、CI 環境でステージングと本番の両方で使用するベースイメージを生成するべきではないようです。さらに、標準インストールではないことは大きな警告信号であり、ソフトウェアが更新されるにつれて将来的に大きな頭痛の種になる可能性があります。