ウィザードのような手取り足取りのアプローチを使用しないことが、「opiniated、specific、またはspecial」ではない 
いずれにせよ、手がかりはDiscourseのオリジナルのDockerイメージを持っていることです。それだけです。
公式ガイドと「ランチャー」を使用してセットアップを試しましたが、うまくいきませんでした（ユーザーがrootであるかどうかを確認する非常に単純なチェックは別として、それは問題を引き起こすだけです）。
その後、Bitnamiイメージ（および彼らが提案するComposeファイル）をhttps://hub.docker.com/r/bitnami/discourse から使用し、1回のdocker compose up（およびいくつかのSQLエラー[これは良い兆候ではありません]とRubyからの警告[同じ注意点]）の後、Discourseの実行インスタンスを取得しました。
純粋に複雑で「標準外の魔法」…
では、なぜ通常のイメージがないのでしょうか？
ソースとリポジトリを調べたところ、ベースイメージが使用されていること（https://hub.docker.com/r/discourse/base/）を発見しましたが、そのバージョン管理/タグ付けに驚きました（https://hub.docker.com/r/discourse/base/tags）…まともなバージョンがないのはなぜだろうか？そして確かに、メインリポジトリを見ると、リリースがないように見えましたが、少なくとも適切にタグ付けされたバージョンはあります（https://github.com/discourse/discourse/tags）。
では、なぜメインのDocker Hubに一致するイメージがないのでしょうか？
ですから、物事がどのように整理されているかを見て、同意します。
一方で（またはむしろ：「物事がどうあるべきか」）、例のプロジェクト（スコープは小さいですが、理由は同じです）：https://github.com/miniflux/v2。
まともなリリースがあります：Releases · miniflux/v2 · GitHub
対応するイメージが正しくタグ付けされています：https://hub.docker.com/r/miniflux/miniflux/tags
そして、アップグレードは単にバージョンをxからyに切り替えるだけです（またはlatestタグを使用して、単純なstop/pull/startで更新されたバージョンを取得します（これにより、必要なすべてのマイグレーションが自動的に実行されます））。
（ああ、そしてイメージは約70倍小さいですが、それはまた別の話です）