好的，如果我已经有一个处于开发模式的成熟插件，该如何在不依赖第三方服务的情况下将其迁移到生产环境？这真的可行吗？
是的，这在本文档中有说明
你是认真的吗？整个教程都依赖于 GitHub，而我的问题是关于不依赖第三方。
在 GitHub 或 GitLab 上托管，然后像往常一样克隆。
Discourse 本身依赖许多外部服务，例如 Github、Docker Hub、Rubygems、NPM 注册表和 LetsEncrypt。在我看来，如果你的插件部署只是独立于 Github，而没有解决对其他服务的依赖，那么这样做意义不大。
哦，你说得对，我漏掉了那部分。
这很合理，因为我开发了许多只负责小功能的小型插件，它们通常不需要更新。为了发布这些小型插件而去管理 GitHub 实在是大材小用，工作量也太大了。
在 GitHub 上发布插件只需不到一分钟。创建仓库，然后复制/粘贴它生成时输出的 shell 脚本，该脚本会执行 git init、git add 和 git push。这就是为什么你是第一个问这个问题的人。将你的插件纳入版本控制也是一个好主意，无论插件有多小。
你可以复制安装脚本并修改它，以便将你的插件目录直接复制到 Docker 镜像中。这假设你已经在本地有了插件代码。然而，我怀疑维护这个修改后的安装脚本以应对更新的工作量是原来的 10 倍。
我不是第一个提出这个问题的人（之前也有人问过），但讨论变得越来越复杂，最终你们却从未真正回答任何问题。
这种不允许灵活性的做法毫无理由。至少尝试一次 WordPress 或其他服务，你就会发现安装插件并不像在 Discourse 上那样令人头疼。
使用 GitHub 没问题，但想要在本地工作难道会被视为不妥吗？
澄清一下：我不为 Discourse.org 工作。我只是这里的一名用户，和你们一样。
在 Communiteq，我们开发了属于自己的控制面板，可以轻松安装/卸载插件。有趣的是：它并没有取代 GitHub，而是建立在 GitHub 之上。
如果你曾经 开发（而不是安装）过 WordPress 插件，你就绝不会这么说，因为现在 那才是真正的噩梦。
使用合适的版本控制将为您省去大量未来的麻烦和问题。它能确保您的插件在未来安全可靠，并有助于保留更新的操作记录。
它提供了一种模块化的方式来分离关注点，从而降低复杂性。
它允许您独立管理实例，使服务器迁移和重建变得更加简单。
这也是专业的做法。
我很好奇，你们在没有使用 GitHub 或其他类似的代码托管服务的情况下，是如何构建和测试一个“开发完善”的插件的？你们又是如何为 Discourse 开发“许多小型插件”的？
对试图帮助你的人采取对抗态度是行不通的。如果你确实如你所说之前开发过插件，那么你就会知道在 Discourse 上安装它们并非难事；使用代码仓库并编辑 app.yml 文件，对于有自托管经验且熟悉插件开发的人来说应该很简单。
我不确定在 Codeberg 上托管是否适用于 Discourse 插件。如果适用，那可能就是楼主想要的。
我同意对 GitHub 的使用提出质疑。他们移除了约 30 万个仓库（与 DMCA 相关），且事先未作沟通。卡内基梅隆大学（CMU）的研究方法——通过检查之前被观测到的仓库后来是否被删除——表明，通过内部执法手段移除的仓库数量可能高出整整一个数量级。
仅 CMU 的研究就发现，在一次虚假星标清理行动中删除了约 14,000 个仓库，而通过 DMCA 每年删除的仓库数量约为 2 万至 4.7 万个。由于这些仓库仅显示 404 错误，因此没有总体的统计数据。
我的意思是，Discourse 插件实际上并没有风险，但现在 Farble 已成为国家安全问题。我们不知道如果每篇人类帖子都需要通过Persona或类似工具进行 KYC（了解你的客户）验证，未来短期内会发生什么。
你是建议 Discourse 团队离开 GitHub 吗？
有几个替代方案，这没问题。如果你必须的话，可以使用它们，但如果你不愿意投入一点精力，我认为就不必运行 Discourse 了。
这就是你所谓的咄咄逼人吗？抱歉，但没人真的在争吵，你可能只是太敏感了。如果这话听起来有点咄咄逼人，我也很抱歉。
不管怎样，回答你的问题，我显然是用一个一次性 GitHub 账号做的。但这些项目非常小，所以我不需要花太多时间测试它们，也不需要写太多代码。
我已经用那个一次性账号安装并测试过它们能正常运行，但长远来看，我不想每次想修改时都得盯着这个仓库。我说它们非常小，可不是开玩笑的。比如，其中一个项目只是在首页的外部页面上添加一个按钮，仅此而已。
这就好比说你想要一辆车，却懒得去做每年的年检。
在公开网络上托管服务时，这就是经营业务的成本。
我相信如果你愿意，你可以想办法修改安装脚本，并从服务器上的某个位置创建符号链接（symlink）。但听你的语气，你似乎不想做任何工作，而且编写和维护这个解决方案的责任将完全在你身上。
如果你能把这简化为一个主题组件（Theme Component），你可以发挥你的创意（Heath Robinson式的方法），使用 discourse_theme 从你的本地机器将代码推送到服务器。但是，如果你的本地机器损坏、丢失或被盗，导致你无法找回代码（除非你再想办法从服务器获取一份实时副本），到时候可别哭。
如果您不想安装 discourse_theme gem，那就更简单了：主题可以以 zip 文件形式上传，您甚至可以直接在管理界面中构建大量功能。
再次强调，除非您正在使用 Ruby，否则根本不需要插件，因此您需要的很可能是一个主题……无需使用 Git。
好主意！不过 discourse_theme 的优势在于它能即时就地更新，因此您可以快速查看更改，而无需打包更新文件并重新上传。
听起来更像是想要开一辆车，却永远不去加油站。“我就用手把汽油舀进油箱里”。 
如果你使用 GitHub 来开发插件，那么将其作为安装源简直易如反掌。向仓库推送更改比手动将更新后的插件文件传输到服务器要省力得多。
听起来你更像是在试图绕过安装过程，以便在托管的 Discourse 实例上部署插件。