# Upgrade without rebuilding having a good/ready image?

**URL:** https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235
**Category:** Support
**Created:** [November 20, 2025, 3:03pm UTC](https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235 "2025-11-20T15:03:57Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![lejeczek](https://avatars.discourse-cdn.com/v4/letter/l/edb3f5/32.png) [@lejeczek](https://meta.discourse.org/u/lejeczek)
#### Post date: [November 20, 2025, 3:03pm UTC](https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235/1 "2025-11-20T15:03:57Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [November 20, 2025, 3:15pm UTC](https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235/2 "2025-11-20T15:15:24Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![lejeczek](https://avatars.discourse-cdn.com/v4/letter/l/edb3f5/32.png) [@lejeczek](https://meta.discourse.org/u/lejeczek)
#### Post date: [November 20, 2025, 4:07pm UTC](https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235/3 "2025-11-20T16:07:15Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [November 20, 2025, 6:52pm UTC](https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235/4 "2025-11-20T18:52:53Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![lejeczek](https://avatars.discourse-cdn.com/v4/letter/l/edb3f5/32.png) [@lejeczek](https://meta.discourse.org/u/lejeczek)
#### Post date: [December 13, 2025, 8:39am UTC](https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235/5 "2025-12-13T08:39:13Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [December 13, 2025, 11:26am UTC](https://meta.discourse.org/t/upgrade-without-rebuilding-having-a-good-ready-image/389235/6 "2025-12-13T11:26:22Z")

</div>

You probably also want to precompile assets
