Okay, so if I already have a well-developed plugin in development mode, how do I move that plugin to production without relying on third-party services? Is there even a way to do that?
Yes, it’s explained in this doc
Are you serious? That whole tutorial relies on GitHub, and my question is about not relying on third parties.
Host it on GitHub or GitLab, clone as usual.
Discourse itself depends on quite a few external services like Github, Docker Hub, Rubygems, the NPM registry and LetsEncrypt. Just making your plugin deployment independent of Github does not make a lot of sense if you ask me.
Oh you’re right, missed that part. 
It makes sense because I have developed many small plugins that do small things and therefore won’t need updates, managing GitHub to put those small plugins up is overkill, it’s too much work.
Putting a plugin up on Github is less than one minute of work. Create repository and copy/paste the shell script it outputs upon creation that does git init, git add and git push. That is the reason why you’re the first one to ask this. Having your plugins under version control is a good idea as well, no matter how small the plugin is.
You could copy the install script and modify it so it copies your plugin directories into the docker image directly. That assumes you have the plugin code locally already. However, I suspect that maintaining the modified install script against the updates it gets is 10x more work.
I’m not the first to ask (others have asked before) but the discussion keeps getting more complicated, and in the end, you guys never actually answer anything.
There’s no justification for this approach that doesn’t allow for flexibility. At least try WordPress or another service once, and you’ll see that installing plugins isn’t the nightmare it is on Discourse.
Using GitHub is fine, but is wanting to work locally frowned upon?
Just to be clear: I do not work for Discourse.org. I’m just a user here, just like you.
At Communiteq we have developed our own control panel which allows for easy plugin installation/deinstallation. Fun fact: it does not replace Github, it built upon it.
If you ever built (not installed) a Wordpress plugin you would have never said that, because now that’s a nightmare.
Using proper source control will save you loads of heartache and issues down the line. It keeps your plugin safe for the future and helps keep an audit trail of updates.
It provides a modular way of separating concerns, reducing complexity.
It allows you to manage your instances independently, makes server migrations and rebuilds much simpler.
It’s also the professional approach.
i’m curious how you built and tested a “well-developed” plugin without using github or some other similar repository service? how did you develop “many small plugins” for discourse?
being combative with people trying to help you isn’t going to go far. if you have developed plugins before like you say you have, then you’ll know it is not a nightmare to install them on discourse; using a repo and editing an app.yml file should be easy for someone self-hosting and experienced in plugin development.
I don’t know if hosting on Codeberg should work on Discourse plugins. If it is, that’s probably what the OP is looking for.
I’m agree with questioning the use of Github. They removed ~300.000 repositories (DMCA related) with no prior communication and CMU study’s methodology — checking whether previously-observed repos were later deleted, suggests order-of-magnitude more repos have been removed via internal enforcement.
The CMU study alone found ~14,000 repos deleted in one fake-star sweep, vs. ~20k–47k annually via DMCA. There is no total metrics because those repositories shows only 404 errors.
I mean, there is no actual risk for Discourse plugins, but now Farble is a national security concern, and we did not know what could happen in the near future if every human post needs to be KYCed through Persona or something like that.
So you recommend Discourse team move away from GitHub?
There are several alternatives and that’s fine. Use them if you must, but if you aren’t prepared to put in a little work, don’t bother running Discourse imho.
Is that what you call combative? I’m sorry, but nobody’s been fighting, you’re probably just being too sensitive. And I’m sorry if that sounded combative.
Anyway, to answer your question, I obviously did it with a disposable GitHub account, but they’re so small that I don’t really have to test them too much or write much code.
I’ve already installed them using the disposable account and tested that they work, but in the long run, I don’t want to have to keep an eye on the repository every time I want to make a change. I’m not kidding when I say they’re very small. For example, one of them just adds a button to an external page on the home page, and that’s it.
It’s like saying you want a car, but can’t be bother getting the annual road-worthiness check.
It’s just the cost of doing business when hosting publicly on the open web.
I’m sure if you want to, you can work out a way to modify the install scripts and symlink them from somewhere on your server, but you don’t sound as if you want to do any work and it will be on you to write and support that solution.
If you can boil that down to a Theme Component you could go Heath Robinson and use discourse_theme to push from your local machine to your server, but don’t cry if your local machine dies, is lost or stolen and you can’t get your code back (without then working out how to get a live copy from your server)
Even simpler if you don’t want to install the discourse_theme gem, themes can be uploaded as a zip file and you could build quite a lot in the admin UI directly.
And to reiterate, unless you’re working with ruby you don’t need a plugin at all, so a theme is likely what you’re asking for… no git needed.
Good point! But the advantage of discourse_theme is the instant way it updates in place so you can quickly checkout changes without having to zip an update and re-upload.
Sounds more like wanting to drive a car but never visit a gas station. “I’ll just scoop the gas into the tank using my bare hands”. 
If you used GitHub to develop the plugins then using it as a source for installation is trivial. Pushing changes to a repo is less effort than transferring updated plugin files manually to a server.
It sounds more like you’re trying to bypass the installation process to deploy plugins on a Hosted Discourse installation.