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?

You probably also want to precompile assets

在拥有良好/就绪镜像的情况下无需重建进行升级？

产品支持

pfaffman (Jay Pfaffman) 2025 年12 月 13 日 11:26 6

您可能还想预编译资产

话题		回复	浏览量
Building the image without touching the database Self-hosting	13	2473	2023 年9 月 17 日
How do I upgrade Discourse in a multiple container configuration? Self-hosting	2	984	2020 年10 月 8 日
How Discourse deals with upgrades Product Support	3	1098	2020 年1 月 29 日
Improving pain points on bootstrap and rebuild Development	5	2058	2017 年7 月 21 日
Can you upgrade Discourse seamlessly if there is a breaking db change? Product Support	12	3179	2018 年9 月 28 日

在拥有良好/就绪镜像的情况下无需重建进行升级？

相关话题