はい、だからこそ、時間の経過とともに、より多くのリソースを持つ上位のプランにいつでもアップグレードできると言っていたのです。その…プラン…に長く留まるつもりはまったくありませんでした。ただ、水面を試すときに不必要な費用を避けたいだけなんです。わかりますか？
サーバーリソース以外に、それらを分離したいと思う理由をいくつか挙げてもらえますか？現時点では、それらを別々のサーバーに置く良い理由が見当たりませんが、まだ知らないことについていくつかの異なる視点を学ぶことはいつでも歓迎です。
それは非常に興味深い点ですね。それは知りませんでした。ですから、実際に既に行われており、機能しているもののようですね。知れてよかったです。
親サイトとはどういう意味ですか？各インストールは独立しているのではないでしょうか？どちらが親と見なされるのでしょうか？
少し混乱しています。app.yamlファイルを見ると、Brevoメールと認証情報専用の部分がありますね。コミュニティごとに個別のapp.yamlファイルを持つ方法も取れると言っていましたよね。そうすると、各コミュニティに独自のBrevo認証情報（通知メールを含む）があるということになりませんか？
適切にバックアップできなくなるようなこと、または通知メールが正しく送信されないようなことです。繰り返しますが、私は専門家ではなく、Discourseを使い始めたばかりなので、他の人が問題と見なすかもしれないが、私にはまだ見えていないこともあります。
はい、私もそう考えていました。共有されるのはサーバー自体だけで、他はすべて別々のインストールとして機能するはずなので、上記のメールに関する質問が出てきたのです。
私にとって最も困難なステップは、数か月前にDiscourseのインストールに深く飛び込んだことだったと思います。それについてはまったく知識がありませんでした。「docker」が何を意味するのかさえ知りませんでした。現時点では、セルフホスティングに関してはまだ「基本的なDiscourseユーザー」だと考えていますが、より明確な視点を持っています。そして、このコミュニティとChatGPT/Claudeの助けを借りて、もう少し学び、物事がどのように機能し、インストールされるかについてメモを取ることができました。課題は構いませんし、正直なところ、これは単にソフトウェアをインストールしているだけです。核爆弾を作っているわけではありません 
何か問題が発生したら、すべて削除して、サーバーごとに単一のインストールに戻せばいいだけです。すべてOKです 
前述したように、自分のコミュニティはすでにインストールされているので、最も難しい部分はすでに終わっていると思います。指示に従い、質問をすることが得意なので、試しながら、いつでも一時停止して調査したり、メモを取ったりすることができます。
今の私の目標は、その仕組み、長所と短所、何が可能で何が不可能かといった仕組みを理解することにあります。そうすれば、後で後悔することになるような、物事を修正するのに時間をかけすぎるような、良い決断ができるようになるからです。
ですから、皆さんが今日共有してくださっているこれらの情報は非常に貴重です。考えるべき良いアイデアを与えてくれます。特に、Discourseチームが提供する管理ホスティングがマルチサイトであると述べたことは、これが可能であることを私に実感させてくれました。もう少し手順が必要かもしれませんが、すべて実行可能です。
フィードバックに本当に感謝しています 