De acuerdo, si ya tengo un plugin bien desarrollado en modo de desarrollo, ¿cómo puedo mover ese plugin a producción sin depender de servicios de terceros? ¿Hay alguna manera de hacerlo?
Sí, está explicado en este documento
¿En serio? Todo ese tutorial depende de GitHub, y mi pregunta es sobre cómo no depender de terceros.
Aloja el proyecto en GitHub o GitLab y clónalo como de costumbre.
El propio Discourse depende de varios servicios externos como Github, Docker Hub, Rubygems, el registro de NPM y LetsEncrypt. A mi juicio, no tiene mucho sentido hacer que la implementación de tu plugin sea independiente de Github si el resto del sistema sigue dependiendo de otros servicios externos.
Oh, tienes razón, me perdí esa parte. 
Tiene sentido porque he desarrollado muchos pequeños complementos que realizan tareas mínimas y, por lo tanto, no necesitarán actualizaciones; gestionar GitHub para subir esos pequeños complementos es excesivo, es demasiado trabajo.
Publicar un plugin en Github lleva menos de un minuto. Crea un repositorio y copia/pega el script de shell que genera al crearlo, el cual ejecuta git init, git add y git push. Esa es la razón por la que tú eres el primero en hacer esta pregunta. También es una buena idea tener tus plugins bajo control de versiones, sin importar lo pequeño que sea el plugin.
Podrías copiar el script de instalación y modificarlo para que copie tus directorios de plugins directamente en la imagen de Docker. Esto asume que ya tienes el código del plugin localmente. Sin embargo, sospecho que mantener el script de instalación modificado frente a las actualizaciones que recibe es 10 veces más trabajo.
No soy el primero en preguntar (otros ya lo han hecho antes), pero la discusión se vuelve cada vez más complicada y, al final, ustedes nunca responden realmente nada.
No hay justificación para este enfoque que no permita flexibilidad. Al menos prueben WordPress u otro servicio una vez, y verán que instalar complementos no es la pesadilla que es en Discourse.
Usar GitHub está bien, pero ¿es mal visto querer trabajar localmente?
Para dejarlo claro: no trabajo para Discourse.org. Soy simplemente un usuario aquí, igual que ustedes.
En Communiteq hemos desarrollado nuestro propio panel de control que permite la instalación y desinstalación fácil de plugins. Dato curioso: no reemplaza a GitHub, se basa en él.
Si alguna vez han desarrollado (no instalado) un plugin de WordPress, nunca habrían dicho eso, porque ahora sí que es una pesadilla.
Usar un control de versiones adecuado te ahorrará muchos dolores de cabeza y problemas a futuro. Mantiene tu plugin seguro para el futuro y ayuda a conservar un registro de auditoría de las actualizaciones.
Proporciona una forma modular de separar responsabilidades, reduciendo la complejidad.
Te permite gestionar tus instancias de forma independiente, haciendo que las migraciones y reconstrucciones de servidores sean mucho más sencillas.
También es el enfoque profesional.
Me da curiosidad cómo construiste y probaste un plugin “bien desarrollado” sin usar GitHub ni algún otro servicio de repositorio similar. ¿Cómo desarrollaste “muchos plugins pequeños” para Discourse?
Ser agresivo con las personas que intentan ayudarte no te llevará a ningún lado. Si has desarrollado plugins antes, como dices que lo has hecho, entonces sabrás que no es una pesadilla instalarlos en Discourse; usar un repositorio y editar un archivo app.yml debería ser sencillo para alguien que hace autoalojamiento y tiene experiencia en el desarrollo de plugins.
No sé si alojar en Codeberg debería funcionar con los complementos de Discourse. Si es así, probablemente eso es lo que busca el autor original.
Estoy de acuerdo en cuestionar el uso de GitHub. Eliminaron ~300.000 repositorios (relacionados con DMCA) sin comunicación previa, y la metodología del estudio de la CMU —que consiste en verificar si los repositorios observados anteriormente fueron eliminados posteriormente— sugiere que el número de repositorios eliminados mediante medidas internas es de un orden de magnitud mayor.
Solo el estudio de la CMU encontró ~14.000 repositorios eliminados en una sola limpieza de estrellas falsas, frente a ~20.000–47.000 anuales por DMCA. No hay métricas totales porque esos repositorios muestran errores 404.
Quiero decir, no hay ningún riesgo real para los complementos de Discourse, pero ahora Farble es una preocupación de seguridad nacional, y no sabíamos qué podría ocurrir en el futuro cercano si cada publicación humana necesita ser verificada mediante Persona o algo similar.
¿Entonces recomiendas que el equipo de Discourse se aleje de GitHub?
Hay varias alternativas y eso está bien. Úsalas si es necesario, pero si no estás dispuesto a dedicar un poco de trabajo, no te molestes en ejecutar Discourse, en mi opinión.
¿Es eso lo que llamas combativo? Lo siento, pero nadie ha estado peleando; probablemente solo estás siendo demasiado sensible. Y lo siento si eso sonó combativo.
De todos modos, para responder a tu pregunta, obviamente lo hice con una cuenta de GitHub desechable, pero son tan pequeñas que realmente no necesito probarlas demasiado ni escribir mucho código.
Ya las instalé usando la cuenta desechable y confirmé que funcionan, pero a largo plazo no quiero tener que vigilar el repositorio cada vez que quiera hacer un cambio. No estoy bromeando cuando digo que son muy pequeñas. Por ejemplo, una de ellas simplemente agrega un botón a una página externa en la página de inicio, y eso es todo.
Es como decir que quieres un coche, pero no te molestas en hacer la revisión técnica anual.
Es simplemente el coste de hacer negocios cuando se aloja públicamente en la web abierta.
Estoy seguro de que, si quieres, puedes buscar una forma de modificar los scripts de instalación y crear enlaces simbólicos desde algún lugar de tu servidor, pero no suenas como si quisieras hacer ningún trabajo, y te corresponderá a ti escribir y mantener esa solución.
Si puedes resumirlo en un Tema Componente, podrías ir por la vía Heath Robinson y usar discourse_theme para enviar desde tu máquina local a tu servidor, pero no llores si tu máquina local se muere, se pierde o te la roban y no puedes recuperar tu código (sin tener que averiguar luego cómo obtener una copia en vivo desde tu servidor).
Aún más sencillo si no deseas instalar el gem discourse_theme: los temas se pueden subir como un archivo ZIP y puedes construir bastante directamente desde la interfaz de administración.
Y para reiterar, a menos que estés trabajando con Ruby, no necesitas ningún plugin en absoluto, por lo que probablemente lo que buscas es un tema… sin necesidad de Git.
¡Buena observación! Pero la ventaja de discourse_theme es la forma instantánea en que se actualiza en el mismo lugar, por lo que puedes revisar rápidamente los cambios sin tener que comprimir una actualización y volver a subirla.
Suena más a que quieres conducir un coche pero nunca vas a una gasolinera. “Solo voy a meter la gasolina en el depósito con las manos”. 
Si usaste GitHub para desarrollar los complementos, entonces usarlo como fuente de instalación es trivial. Enviar cambios a un repositorio requiere menos esfuerzo que transferir manualmente los archivos de complementos actualizados a un servidor.
Suena más a que estás intentando eludir el proceso de instalación para desplegar complementos en una instalación de Discourse alojada.