開発モードで十分に開発されたプラグインがある場合、サードパーティのサービスに頼らずに本番環境に移行するにはどうすればよいでしょうか？そんな方法があるのでしょうか？
はい、このドキュメントで説明されています。
本気ですか？そのチュートリアル全体がGitHubに依存しているのに、私の質問はサードパーティに依存しない方法についてなんです。
GitHub または GitLab でホストし、通常通りクローンしてください。
Discourse自体は、GitHub、Docker Hub、Rubygems、NPMレジストリ、LetsEncryptなど、いくつかの外部サービスに依存しています。私の意見では、プラグインのデプロイをGitHubに依存させなくするだけでは、あまり意味がありません。
ああ、その部分を見落としていましたね。
納得です。私は小さな機能を担う多くの小規模プラグインを開発してきましたが、それらは更新を必要としないため、それらを GitHub に公開して管理するのはやりすぎで、手間がかかりすぎます。
プラグインをGitHubに公開するのは、わずか1分ほどの作業です。リポジトリを作成し、作成時に出力されるシェルスクリプト（git init、git add、git pushを実行するもの）をコピー＆ペーストするだけです。そのため、この質問をしたのはあなただけが最初なのです。また、プラグインのサイズが小さくても、バージョン管理下に置くのは良いアイデアです。
インストールスクリプトをコピーして修正し、プラグインディレクトリを直接Dockerイメージにコピーするようにすることもできます。ただし、これにはプラグインのコードが既にローカルにあることが前提となります。しかし、私は、更新がかかるたびに修正されたインストールスクリプトをメンテナンスするのは、10倍の労力がかかるのではないかと推測します。
私だけが初めて質問しているわけではありません（以前にも同じ質問をした人はいます）が、議論がどんどん複雑になるばかりで、結局、皆さんは実際には何も答えてくれません。
柔軟性を許さないこのアプローチには、正当な理由がありません。少なくとも WordPress や他のサービスで一度試してみてください。プラグインのインストールが Discourse のような悪夢ではないことがわかるはずです。
GitHub を使うのは問題ありませんが、ローカルで作業したいと思うことが嫌がられるのでしょうか？
念のため申し上げますが、私はDiscourse.orgの社員ではありません。あなた方と同じく、ここで活動している一人のユーザーに過ぎません。
当社のCommuniteqでは、プラグインの簡単インストール・アンインストールを可能にする独自のコントロールパネルを開発しています。面白い事実：これはGitHubを置き換えるものではなく、GitHubの上に構築されています。
もしあなたがWordpressのプラグインを作成（インストールではなく）したことがあれば、そんなことは決して言わないでしょう。なぜなら、それがまさに悪夢だからです。
適切なバージョン管理を徹底すれば、将来の多大なトラブルや手間を未然に防げます。プラグインを将来にわたって安全に保つだけでなく、更新履歴の監査証跡を残すのにも役立ちます。
また、関心の分離をモジュール化して実現し、複雑さを軽減します。
インスタンスを独立して管理できるため、サーバーの移行や再構築が格段に簡単になります。
これは何より、プロフェッショナルなアプローチです。
「well-developed」なプラグインを、GitHubやその他の類似のリポジトリサービスを使わずに、どのように構築・テストしたのか興味があります。Discourse向けに「多数の小さなプラグイン」をどのように開発したのですか？
手伝おうとしている人に対して攻撃的な態度を取っても、良い結果は得られません。あなたが言うように以前にプラグインを開発した経験があるなら、Discourseへのインストールがナイトメアではないことはご存知のはずです。リポジトリを使用し、app.ymlファイルを編集することは、プラグイン開発の経験がありセルフホスティングをしている人にとって簡単であるべきです。
CodebergでDiscourseプラグインをホストするのが機能するかどうかは分かりませんが、もし可能なら、おそらくOPが探しているのはそれでしょう。
GitHubの使用を疑問視する意見に同意します。彼らは事前の連絡なしにDMCA関連で約30万リポジトリを削除しました。また、カーネギーメロン大学（CMU）の研究の手法——以前観測されていたリポジトリが後に削除されたかどうかを確認する——によれば、内部執行によって削除されたリポジトリの数は桁違いに多いことが示唆されています。
CMUの研究だけでも、1回の「フェイクスター」一掃作戦で約1万4000リポジトリが削除されたのに対し、DMCAによる年間削除数は約2万～4万7000件でした。これらのリポジトリは404エラーを表示するため、総数は把握されていません。
つまり、Discourseプラグインに実際のリスクがあるわけではありませんが、今やFarbleは国家安全保障上の懸念事項となっています。もしすべての人間の投稿が「Persona」のようなものを通じてKYC（本人確認）を必要とするようになった場合、将来何が起こるのか誰も分からないのです。
つまり、DiscourseチームにGitHubからの移行を推奨しているわけですか？
代替案は複数ありますし、それで問題ありません。どうしても必要ならそれらを使えばいいですが、Discourseを運用するには多少の努力が必要ですよ。その気のない限り、Discourseを動かすのは無駄だと思います。
それを『攻撃的』と呼ぶのですか？申し訳ありませんが、誰も戦っていません。おそらく、あなたが少し過敏になっているだけでしょう。そして、もしそれが攻撃的に聞こえたなら、それも申し訳ありません。
ともあれ、ご質問にお答えします。もちろん、使い捨ての GitHub アカウントを使って行いました。しかし、それらは非常に小規模なので、それほどテストを重ねたり、多くのコードを書いたりする必要はありません。
すでに使い捨てアカウントを使ってインストールし、動作確認も済ませています。しかし、長期的には、変更を加えるたびにリポジトリを監視し続けるのは避けたいと考えています。非常に小規模だと言っているのは冗談ではありません。例えば、その一つは単にホームページの外部ページにボタンを追加するだけのものです。それだけです。
それは、車は欲しいけど、車検を受ける手間をかけるのが面倒だと言っているようなものです。
オープンなウェブ上で公開ホスティングする場合、これはビジネスを行うためのコストです。
もしお望みなら、インストールスクリプトを修正し、サーバー上のどこかからシンボリックリンクで接続する方法を見つけることもできるでしょう。しかし、あなたは何もしたくないと言っているように聞こえ、その解決策の作成と保守はあなた自身の責任となります。
それをテーマコンポーネントにまとめられれば、discourse_theme を使ってローカルマシンからサーバーへプッシュするという、ヒース・ロビンソン方式の手法も可能です。ただし、ローカルマシンが故障、紛失、盗難に遭い、コードを取り戻せなくなった場合（その後、サーバーからライブコピーを取得する方法を考え出す必要がありますが）に泣きつかないでください。
discourse_theme gem をインストールしたくない場合は、さらに簡単です。テーマは ZIP ファイルとしてアップロードでき、管理画面で直接かなり多くの機能を構築できます。
繰り返しになりますが、Ruby を使用していない限り、プラグインはまったく不要です。したがって、おそらく必要なのはテーマの方でしょう……git は不要です。
良い点ですね！しかし、discourse_theme の利点は、その場で即座に更新されることです。そのため、更新ファイルを zip 圧縮して再アップロードする必要なく、変更点を素早く確認できます。
どちらかと言えば、ガソリンスタンドに寄ることもなく、車に乗りたいだけのように聞こえます。「素手でガソリンをタンクにすくうんだ」。 
プラグインの開発にGitHubを使用しているなら、それをインストール元として利用するのは簡単なことです。リポジトリに変更をプッシュする方が、更新されたプラグインファイルをサーバーに手動で転送するよりも手間がかかりません。
あなたが行おうとしているのは、ホスト型Discourse環境にプラグインを展開するためにインストールプロセスを回避しようとしているように見えます。