Hi guys. Is it possible to update to newer version without rebuilding the whole thing? I’m thinking of a scenario where two discourse apps are virtually identical and once I have a new image ready - off any one of the two - I could use it to deploy second discourse, having all the config/params for container. I guess left only to take care of for such container would be pg db migration? Does that make sense and if possible, how to do it, ideally without hacking any source code? many thanks, L.

You can build an image, push it to a repo, and then start it up using ./launcher start-cmd app to get the docker command to start up the container (but you’ll substitute your container repo for the local one). And yet, then you need to migrate the database, precompile assets, and so on. If it’s downtime that you want to avoid, the two-container setup lets you build a new container while the old one continues to run and then it handles the migrations and such. If you want to be extra careful you can set SKIP_POST_DEPLOYMENT_MIGRATIONS in your app.yml and then do rake db:ensure_post_migrations db:migrate after the new container is started. Not doing so can migrate the database such that the old container can no longer use it. It’s not often a problem, and then, not for very long.

Downtime is not an issue for me. Two apps I think of, would be - virtually identical - but not the same. Two apps would be different sites, meaning, different dbs, volumes, ports, names… but they would have the same - so to speak - base discourse (+ same plugins, same whatever might critical to that core/base). In ideal world of Discourse - if such does not exit yet - for such scenario, such new image once build first/one time, could be used even with docker tools directly - and DB or anything what would have to be “migrated” to such new image/discourse version, start/boot process of such “secondary” container would - perhaps with help of env vars - decide to check/carry out necessary migrations of dbs. Main advantage - which many must have thought already of - is a single image for both (or many more if some people do that) containers/apps.

You can do that as I described. There’s also a new scheme in the works that makes it possible to use a single image and not rebuild. It’s not supported, so you’ll need to search well here or in github.

Hi & thanks. That seems to work, loading a new image and then running rake db:ensure_post_migrations db:migrate seemed to resulted in a fine & healthy new version of container without luncher rebuild - at least for 3.5.0.beta7 to 2025.11.0. That makes me - certainly not just me - thinking…. would it be possible to make such(& anything else need for healthy upgrade) rake part of boot/start of a given, custom container and… would that make sense?

Upgrade without rebuilding having a good/ready image?

Product Support

pfaffman (Jay Pfaffman) December 13, 2025, 11:26am 6

You probably also want to precompile assets

Topic		Replies	Views
Building the image without touching the database Self-hosting	13	2458	September 17, 2023
How do I upgrade Discourse in a multiple container configuration? Self-hosting	2	980	October 8, 2020
How Discourse deals with upgrades Product Support	3	1092	January 29, 2020
Improving pain points on bootstrap and rebuild Development	5	2055	July 21, 2017
Can you upgrade Discourse seamlessly if there is a breaking db change? Product Support	12	3164	September 28, 2018

Upgrade without rebuilding having a good/ready image?

Related topics