Certo, se eu já tenho um plugin bem desenvolvido em modo de desenvolvimento, como faço para movê-lo para produção sem depender de serviços de terceiros? Existe alguma maneira de fazer isso?
Sim, isso está explicado neste documento
Você está brincando? Esse tutorial inteiro depende do GitHub, e minha pergunta é sobre não depender de terceiros.
Hospede no GitHub ou GitLab e clone como de costume.
O próprio Discourse depende de vários serviços externos, como Github, Docker Hub, Rubygems, o registro NPM e o LetsEncrypt. Apenas tornar a implantação do seu plugin independente do Github não faz muito sentido, na minha opinião.
Ah, você tem razão, perdi essa parte. 
Faz sentido, pois desenvolvi muitos plugins pequenos que fazem coisas simples e, portanto, não precisarão de atualizações. Gerenciar o GitHub para publicar esses plugins pequenos é exagero, é muito trabalho.
Colocar um plugin no GitHub leva menos de um minuto. Crie um repositório e copie/cole o script de shell que ele gera após a criação, que executa git init, git add e git push. É por isso que você é o primeiro a fazer essa pergunta. Manter seus plugins sob controle de versão também é uma boa ideia, não importa quão pequeno seja o plugin.
Você pode copiar o script de instalação e modificá-lo para que copie seus diretórios de plugin diretamente para a imagem do Docker. Isso pressupõe que você já tenha o código do plugin localmente. No entanto, suspeito que manter o script de instalação modificado em sincronia com as atualizações dele seja dez vezes mais trabalhoso.
Não sou o primeiro a perguntar (outros já perguntaram antes), mas a discussão só fica mais complicada e, no final, vocês nunca respondem nada de fato.
Não há justificativa para essa abordagem que não permite flexibilidade. Pelo menos tentem usar o WordPress ou outro serviço uma vez, e verão que instalar plugins não é o pesadelo que é no Discourse.
Usar o GitHub é ótimo, mas querer trabalhar localmente é malvisto?"
Só para deixar claro: eu não trabalho para a Discourse.org. Sou apenas um usuário aqui, assim como vocês.
Na Communiteq, desenvolvemos nosso próprio painel de controle que permite a instalação/desinstalação fácil de plugins. Curiosidade: ele não substitui o Github, ele é construído sobre ele.
Se vocês já criaram (não instalaram) um plugin para WordPress, nunca teriam dito isso, porque agora isso sim é um pesadelo.
Usar controle de versão adequado poupará você de muitos problemas e dores de cabeça no futuro. Isso mantém seu plugin seguro para o futuro e ajuda a manter um histórico de auditoria das atualizações.
Ele oferece uma maneira modular de separar responsabilidades, reduzindo a complexidade.
Permite gerenciar suas instâncias de forma independente, tornando as migrações e reconstruções de servidores muito mais simples.
Também é a abordagem profissional.
Tenho curiosidade sobre como você construiu e testou um plugin “bem desenvolvido” sem usar o GitHub ou algum outro serviço de repositório semelhante. Como você desenvolveu “muitos plugins pequenos” para o Discourse?
Ser confrontador com pessoas que estão tentando ajudar não vai levar a lugar nenhum. Se você já desenvolveu plugins antes, como diz ter feito, então saberá que não é um pesadelo instalá-los no Discourse; usar um repositório e editar um arquivo app.yml deve ser fácil para alguém que faz auto-hospedagem e tem experiência em desenvolvimento de plugins.
Não sei se hospedar no Codeberg funcionaria com os plugins do Discourse. Se funcionar, provavelmente é isso que o autor do tópico está procurando.
Concordo em questionar o uso do GitHub. Eles removeram cerca de 300.000 repositórios (relacionados a DMCA) sem comunicação prévia, e a metodologia do estudo da CMU — que verifica se repositórios anteriormente observados foram posteriormente excluídos — sugere que uma ordem de magnitude maior de repositórios foi removida por meio de aplicação interna.
Só o estudo da CMU encontrou cerca de 14.000 repositórios excluídos em uma única varredura de fake-star, em comparação com cerca de 20.000 a 47.000 anualmente por meio de DMCA. Não há métricas totais porque esses repositórios retornam apenas erros 404.
Quer dizer, não há risco real para os plugins do Discourse, mas agora o Farble é uma preocupação de segurança nacional, e não sabemos o que pode acontecer no futuro próximo se cada postagem de um humano precisar ser verificada por meio do Persona ou algo semelhante.
Então você recomenda que a equipe do Discourse saia do GitHub?
Existem várias alternativas e tudo bem. Use-as se precisar, mas se você não estiver disposto a dedicar um pouco de trabalho, não se incomode em executar o Discourse, na minha opinião.
É isso que você chama de combativo? Sinto muito, mas ninguém está brigando; você provavelmente está apenas sendo muito sensível. E peço desculpas se isso soou combativo.
De qualquer forma, para responder à sua pergunta, obviamente fiz isso com uma conta descartável do GitHub, mas elas são tão pequenas que não preciso testá-las muito nem escrever muito código.
Já as instalei usando a conta descartável e testei que funcionam, mas, a longo prazo, não quero ter que ficar de olho no repositório toda vez que quiser fazer uma alteração. Não estou brincando quando digo que são muito pequenas. Por exemplo, uma delas apenas adiciona um botão a uma página externa na página inicial, e é só isso.
É como dizer que você quer um carro, mas não se dá ao trabalho de fazer a vistoria anual de segurança veicular.
É apenas o custo de fazer negócios ao hospedar publicamente na web aberta.
Tenho certeza de que, se quiser, você pode encontrar uma maneira de modificar os scripts de instalação e criar links simbólicos para eles a partir de algum lugar no seu servidor, mas você não parece querer fazer nenhum trabalho, e a responsabilidade de criar e manter essa solução será sua.
Se você conseguir resumir isso a um Componente de Tema, pode recorrer a uma solução estilo Heath Robinson e usar discourse_theme para enviar do seu computador local para o servidor, mas não chore se o seu computador local falhar, for perdido ou roubado e você não conseguir recuperar seu código (sem antes descobrir como obter uma cópia ativa do servidor).
Ainda mais simples: se você não quiser instalar o gem discourse_theme, os temas podem ser enviados como um arquivo zip e você pode criar bastante coisa diretamente na interface de administração.
E para reforçar: a menos que você esteja trabalhando com Ruby, não precisa de nenhum plugin, então provavelmente o que você está procurando é um tema… sem necessidade de git.
Ótimo ponto! Mas a vantagem do discourse_theme é a forma instantânea como ele atualiza no local, permitindo que você verifique rapidamente as alterações sem precisar compactar uma atualização e reenviá-la.
Parece mais com querer dirigir um carro, mas nunca visitar um posto de gasolina. “Vou apenas encher o tanque com as próprias mãos”. 
Se você usou o GitHub para desenvolver os plugins, então usá-lo como fonte de instalação é trivial. Enviar alterações para um repositório exige menos esforço do que transferir manualmente os arquivos de plugin atualizados para um servidor.
Parece mais que você está tentando contornar o processo de instalação para implantar plugins em uma instalação do Discourse hospedada.