The discussion revolves around the ability to install and uninstall plugins directly from the Discourse Admin GUI. Faizan_Zahid expresses the need for this feature to minimize downtime when updating plugins on a high-traffic forum.
However, merefield and Stephen point out that this is not possible due to the way plugins are integrated into the app’s resources, requiring a rebuild. They suggest mitigations such as using Theme Components, sticking to a set of plugins, and scheduling updates.
michaeld suggests that rebuilding one web container at a time can avoid downtime with multiple web containers. Mevo agrees that minimizing downtime is a better approach and suggests creating a tutorial on setting up a 2-web-container install.
Heliosurge mentions Procourse Installer as a possible solution, but michaeld and Stephen point out that it requires a rebuild and is no longer maintained. Heliosurge suggests that the developers should consider building this feature into Discourse, even as a switchable option.
Stephen explains that the challenges are more fundamental, particularly with multisite installations and incompatible plugins. Heliosurge suggests that the feature could be implemented for single-site containers, but Stephen emphasizes the difficulties in troubleshooting plugin compatibility issues.
Ultimately, the discussion concludes that installing and uninstalling plugins directly from the Admin GUI is not currently possible, and the focus should be on minimizing downtime and creating tutorials for advanced setups.
It would be super nice to have this..
For big forums, which have high traffic and its not good that forum goes down as i have to do
./launcher rebuild app
Each time i install/uninstall a plugin, this causes my forum to go down for a while and users get frustrated.
It would be nice to have the ability to install/unintsall and rebuild/restart discourse directly from admin GUI.
I do not believe this is possible because of the way plugins are integrated into the resources of the app which needs to be done at build time, especially because some of the plugin elements impact the back end.
Several mitigations:
Customise with Theme Components as much as possible. These can be swapped out and updated online.
Decide on a set of plugins and stick to that list. Why do you need to change the set-up so often?
If you just need to update a plugin use the online upgrade tool.
Schedule the addition of new plugins to when you are forced to do a rebuild because of other fundamental changes in the core app.
The only real recommendation we can give here is to plan in advance. There’s just no substitute for it.
Use a small instance to test and approve any plugin changes you want to make, then schedule a window each week or month to roll up all those changes on your live site.
That way your users won’t be significantly impacted by such activities, and you will significantly reduce the risk of additional downtime due to compatibility issues.
With a setup having multiple web containers, downtime during a rebuild can certainly be avoided by rebuilding / deploying one web container at a time.
I’m sorry @Faizan_Zahid , but you could really do better on that title. Maybe you meant “plugins” and not “Discourse”. Here I was expecting someone who was asking for a feature to remove Discourse from a server 
You want to be able to install/uninstall plugins without having to rebuild. Seems it’s not possible, unfortunately 
You would then want to minimize downtime when you need to rebuild. This has already been a subject lately: Help with “zero downtime” setup (which didn’t really go where it probably should have).
What we may need here, is a nice tutorial on how to setup a 2 web-container install and how to use it. This seems the most efficient setup (and also probably the most complicated one). I don’t have enough knowledge to do such a tutorial, or I would. Is there someone willing to ?
I plan on taking up the chore of making easy guides for a variety of advanced use cases including the above. It’s on the backlog 
If your discourse is using Docker then you could use Procourse installer.
That does a rebuild as well.
While it still works today, AFAIK Procourse has stopped serving customers. I would be very hesitant to recommend it without a clear maintenance roadmap.
I Wasn’t aware of that. Though as long as nothing significantly changes in Discourse structure it should continue to work. Emphasis on should. Wonder if author would allow another to take over the project if he has moved on.
Over time all plugins need to be updated. Even small changes occasionally cause problems for actively developed Discourse plugins. It’s just not possible to predict and definitely not something any of us can rely on.
A plugin which itself manages the installation of plugins that isn’t being maintained is a very risky proposition. Relying on optimism to continue using it feels like a very bad idea.
I’ve only worked with two clients who expressed interest in using it. Once it became clear that Procourse was no more both were keen to migrate away.
This comes down to that the DeVs should consider bringing this kind of feature built into Discourse even if made a switchable option in the comandline if security could be a concern.
AFAIK the challenges are more fundamental than that. As-is the approach doesn’t work with multisite at all.
You also can’t directly uninstall plugins if you inadvertently install something which turns out to be incompatible. It requires ssh access.
I have read the issue of multi site. It could simply use a check and only allow if not a multi site that is using Docker.
So yes it might take a bit of tweaking to do. However it is something they should look into for non multisite installs.
Even if adopted as an official plugin for single site containers.
If you read further down the topic you can see how much harder basic troubleshooting of plugin compatibility issues becomes.
Just something that needs to be in the roadmap. Not too different at times with using a gui in linux to install vs comandline; however there are some that have made this work well.
Anytime you use non official installs there is risk of breakage. So for example the ability to toggle a plugin on or off like a theme or theme component is idea.
Recently had a problem where it seems that Category icons broke things. Even when on a basic theme with no other css mods or components. Took a bit to track it down.
The odd part is it works on our seperate testing install that runs latest discourse beta