The site is offline when installing the plugin

Hello, is it normal for the site to be offline when installing/updating themes and plugins?

1 Like

It is normal for the site to be offline when you do a rebuild.

Solutions are to use a two-container install, which lets you build a new container, so the downtime is less than a minute, or to contrive to have a “we’ll be right back” page display while the site is down, which doesn’t change down time, but then everyone knows that you’re aware that your site is down.

Everyone thinks that at least one of these solutions is too hard and totally not worth the trouble.


Just to add, unlike plugins, installing or updating themes and theme components wouldn’t need any offline time. :+1:


Is there any documentation about the method you mentioned? Also, it seems ironic considering that it is very suitable for SEO in terms of discourse, but there is an interruption during loading and Google bots cannot crawl the site.

How many times do you expect to install a new plugin? This is usually a very rare occurrence.

You can update plugins online with tiny interruption to service as containers swap over.


Thank you for the replies. :saluting_face:

1 Like

Take a look at Add an offline page to display when Discourse is rebuilding or starting up when you feel brave.


Hello :wave: I am not sure and maybe I am wrong (I didn’t try it yet) but this is now a core thing? There is a new template a few month in discourse/templates called offline-page.template.yml and inside it it trigger the GitHub - discourse/discourse-offline-page: offline page for discourse. Which is the static html site during Discourse loading. There is also a PR about it in discourse_docker FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub


Seems like that’d only hit half of it? It’d show up when starting, but not rebuilding, if I understand rebuilds right:

Add a template to pull and serve static HTML files from GitHub - discourse/discourse-offline-page: offline page for discourse when nginx is available, but rails is not.

^ The github PR


But a step in the right direction, thanks @Don (and @featheredtoast ! )

Yeah @Firepup650 I wondered why I hadn’t seen it, and I believe you’ve answered why!

Got some good :male_detective: :male_detective: in here! :slight_smile:

I wonder if this is a pre-step to a permanent standard two container setup, where an nginx container is built separately?!??! :thinking:


You caught me - there is some ongoing movement to making serving offline pages more widely possible - the commits and repos mentioned are groundwork for it to be available, but it isn’t (yet) in place now.


For some reason any of my users don’t see that under rebuilding. Well, on chat anyway and that’s why there has been some incidents where an user has lost just written message.

My opinion is that situation where we don’t inform at all downtime for already login users is the biggest single UX-issue in Discourse. Sure I can understand explanations where is comes from very nature of this app, and devs are kind of painted themselves at corner from the very beginning (similar situations like with drafts and few other things), but it doesn’t erase the problem itself.

We have few worksarounds. Using Nginx as reverse proxy fronf of Discourse showing tuned error page is one. And when an admin has problems the answer will be ”we support only standard one”. That was the actual reason why I dumped that one.

Two different containeirs is one solution. Or at least it keeps downtime very short. There is too many warnings on that, so I’m a bit scary taking that road.

Or we can upgrade only sometimes, inform users before it happends and shutdown public access. Yes, that is one solution, but… now is year 2024 and only banking system uses that in my environment :smirk:

Using staging server is something that should do. Well, that is corporate level solution, expensive and quite difficult way when done right, and loves own IT-team.

So new leaked plans :rofl: are real improvement indeed. Well, if it needs separate containers then there is time to dive in at the deep end I suppose.

1 Like

It’s exactly the same except rarely you also need to rebuild the data container.

1 Like

But downtime is much more shorter that type 20 mins, isn’t it?

1 Like

Chat may have things in it that are different than the regular site viewing as I believe it is more real time access vs being able to cache pages.

Agreed. Planned announced maintenance imho is best like in the days old of dos based dial up bbses. There was an option to to have a system message warning the planned maintenance shutdown was coming and would sign out users at the designated time. In those days it was typically for doing mail packets between networked bbses.

1 Like

Yes. Down time is usually under a minute, but you’ll need enough ram or swap to rebuild one container while the other builds.

1 Like