Read-only mode please!

Having a read-only mode would be great in a few situations:

  • failover to standby read-only database
  • migrations (set read-only, slurp data, restore, switch DNS)
  • upgrades (could upgrade and leave the old thins up and running safely)

Please add! I’ll love you forever.


I’m trying to find where one of the team said that this was needed/coming, but I just can’t find it!

But yes, a “manual site maintenance” mode is essential. Even if upgrades happen transparently almost all of the time with the /admin/docker page.

We haven’t said we need it in public yet, but we definitely do… no question.


I made this one for you @supermathie.

Now you can go to: Admin > Backups and click on the button :wink:


Awesome! How do I do it from a rake task (or CLI)? Where is it saved? Postgres or redis?

Presumably this only affects a single site in a multisite setup, so how can I toggle it for all sites on a host?

With Discourse.enable_readonly_mode and Discourse.disable_readonly_mode, which set a flag in Redis and publish a message on the MessageBus.

  def self.enable_readonly_mode
    $redis.set readonly_mode_key, 1
    MessageBus.publish(readonly_channel, true) # "/site/read-only"

  def self.disable_readonly_mode
    $redis.del readonly_mode_key
    MessageBus.publish(readonly_channel, false)

You can now run script/discourse enable_readonly or script/discourse disable_readonly to enable/disable the readonly mode.

As @riking said, it’s saved in redis right now. Would not make sense to save it in a read-only database :smile:

Not implemented yet. This was mostly made for a site’s admin. Not a super-admin.

1 Like

Speaking of, what happens if Discourse notices that the postgres to which it’s connected is operating in read-only mode? Will it set readonly? Will it behave nicely? Or is that FINR? :smile:

So for sites in a multisite setup, I’ll need to iterate over each site and disable it for each? OK, can do.

Topics load, mostly. Most requests (notifications, etc) puke and die with a 500.

Unfortunately yes.

Read-only mode needs LOTS of polish on the client-side. We need to refactor and normalize how we deal with errors server-side first.

1 Like

I got stuck in read only mode and I’m logged out, I tried just running script/discourse disable_readonly but I believe I’m doing it wrong. Where do I type the command?

I hate to bump this but I can’t access my website.

In the root of your discourse install, you should be able to run script/discourse and get a help menu.

For docker installs, that means cd /var/docker ./launcher ssh app cd /var/www/discourse script/discourse.

Yep, I did that and I’m getting this error message

/usr/local/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- thor (LoadError)
        from /usr/local/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
        from script/discourse:3:in `<main>'
1 Like

Just FYI this is what it looks like, a banner at the top of every page:

An administrator has enabled read-only mode. You can continue to browse the site, but interactions won’t work properly.

1 Like

Have you updated to the latest? Are you running as the right user (discourse)?

Yeah I’m running latest on Docker, as discourse user.

I just ran the command manually, but script/discourse still gives me that error.

Can you access the rails console?

cd /var/docker
./launcher ssh app

to ssh into the docker container.

cd /var/www/discourse
RAILS_ENV=production bundle exec rails c

to launch the console.


to disable the readonly mode.


You can also gem install thor temporarily (until the next bootstrap); and the script will run. At least, it did for me.

1 Like

This is how I ended up doing it, thanks.

One piece of client-side behavior that might be a little more vital than “polish:”

Here on meta last night I noticed that I cannot log out when the site is set to read-only. The logged in session persisted between browser restarts. This did not inconvenience me, as I was using my own device and internet connection, however not all forum users will be in that position.

If we assume that a user is at a public internet kiosk of some sort, (Public library, Internet cafe, etc.) The only way to prevent the user’s account from being compromised if he needs to leave is:

  • Hope the user is savvy enough to clear his cookie cache before leaving.
  • Hope the access point automatically does so between users.

In an ideal world, both of these would be true. In our world…

If you are already aware of this, sorry for the duplication. Just thought it might be worth mentioning.