# Improving pain points on bootstrap and rebuild
**URL:** https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674
**Category:** Development
**Created:** [31 Maggio 2017, 4:53pm UTC](https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674 "2017-05-31T16:53:31Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [31 Maggio 2017, 4:53pm UTC](https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674/1 "2017-05-31T16:53:32Z")
Continuing the discussion from [Can Discourse ship frequent Docker images that do not need to be bootstrapped?](https://meta.discourse.org/t/can-discourse-ship-frequent-docker-images-that-do-not-need-to-be-bootstrapped/33205/114):
> [@Can Discourse ship frequent Docker images that do not need to be bootstrapped?](https://meta.discourse.org/t/can-discourse-ship-frequent-docker-images-that-do-not-need-to-be-bootstrapped/33205/114):
>
> Pain points I am interested in solving long term are
>
> - Faster bootstrap
> - Easier and more frequent base image updates
> - More consistent update process from web upgrader vs a full rebuild
> - Probably move default setup to 2 containers vs 1 container
Well, it took me two years, but I finally bothered to learn how to create a separate data container and rebuild/upgrade the site with a minute rather than a quarter hour of downtime. Just yesterday I started thinking about creating a `./discourse-setup` that would create two containers (based on `data.yml` and `web_only.yml`) rather than one.
I hadn’t started looking at launcher’s exit codes to see if I could safely script
```bash
./launcher bootstrap web
./launcher destroy web
./launcher start web
```
to avoid destroying the container if the new one didn’t get created.
Since the site isn’t down during a rebuild, reducing the build time is less critical.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [1 Giugno 2017, 12:05am UTC](https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674/2 "2017-06-01T00:05:51Z")
If the server is fast enough, the rebuild is [more like 3 minutes](https://meta.discourse.org/t/how-much-is-discourse-affected-by-a-faster-cpu/58407/12). So there’s another way to solve rebuild times 😉
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1 Giugno 2017, 12:24am UTC](https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674/3 "2017-06-01T00:24:01Z")
Yes, well. Moving off digital ocean isn’t an option for lots of people. Heck. Once someone offered to subsidize my getting such a server, but couldn’t justify it with my current business model. 😂 I’m getting closer now, but I’m still a ways off from that making fiscal sense.
Even with a fast Server, though the two container model reduces downtime dramatically.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [21 Luglio 2017, 9:00pm UTC](https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674/4 "2017-07-21T21:00:14Z")
So been trying to find an answer to this question which led me here.
1. What’s the difference between doing site/admin/upgrade via the button and doing a stop/rebuild from the CLI?
2. If I can do the former (which is practically no down time), why would I want to do the latter?
3. Can I automate the former? (I guess the latter can be automated using a bash script with some delays in between the commands and cron scheduler)
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [21 Luglio 2017, 9:12pm UTC](https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674/5 "2017-07-21T21:12:04Z")
> [@RBoy](#):
>
> What’s the difference between doing site/admin/upgrade via the button and doing a stop/rebuild from the CLI?
One click updates Discourse, the software, but not the underlying docker image and all it’s software, like PostgreSQL, Ruby, etc.
> [@RBoy](#):
>
> If I can do the former (which is practically no down time), why would I want to do the latter?
Sometimes a rebuild is needed, when we update minimum requirements, like a new Ruby version.
> [@RBoy](#):
>
> Can I automate the former?
That’s something that could probably already work, but not on the current backlog.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [21 Luglio 2017, 9:14pm UTC](https://meta.discourse.org/t/improving-pain-points-on-bootstrap-and-rebuild/63674/6 "2017-07-21T21:14:53Z")
> [@Falco](#):
>
> Sometimes a rebuild is needed, when we update minimum requirements, like a new Ruby version.
>
> RBoy:
So I’m assuming that the one click upgrade will not work when an underlying component needs an upgrade right?
I’m trying to figure out if I can’t automate the upgrades and “forget” to upgrade for a few months or year or more and suddenly decide to upgrade - will I be able to?
It would be really cool if during setup discourse could setup an automatic upgrade script to run every X days or weeks or months. Maybe pick a day and time of a week or month to run the upgrade in the background essentially making it even (awesome) hands free to maintain.