# Looking up available upgrades via CLI
**URL:** https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330
**Category:** Self-hosting
**Tags:** hosting
**Created:** [August 18, 2017, 6:05pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330 "2017-08-18T18:05:04Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@simonclausen](https://meta.discourse.org/u/simonclausen)
#### Post date: [August 18, 2017, 6:05pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/1 "2017-08-18T18:05:05Z")
I’m looking at automating upgrades of discourse. This is for the most basic single container install. Trying to keep things simple.
The most basic would be to setup up this to run via cron:
```plaintext
cd /var/discourse
git pull
./launcher rebuild app
```
Problem is you take the service offline for the rebuild even if there are no updates.
I’d preferebly like to do something like this:
```plaintext
if ./update_available.sh; then
cd /var/discourse
git pull
./launcher rebuild app
fi
```
(assuming the script exits with true if updates are available)
Anyone know of any easy methods to get this info on the host?
Thanks!
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [August 18, 2017, 6:22pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/2 "2017-08-18T18:22:35Z")
I’d suggest looking into how [GitHub - discourse/docker\_manager: Plugin for use with discourse docker image · GitHub](https://github.com/discourse/docker_manager) works. It compares the running version to GitHub, and updates with close to no downtime. Perhaps you can automate that instead of doing a full rebuild each time?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [August 18, 2017, 6:44pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/3 "2017-08-18T18:44:37Z")
You might check out having separate data and web containers. That way you don’t need to take the site down to build a new image.
---
### Author:  [@simonclausen](https://meta.discourse.org/u/simonclausen)
#### Post date: [August 18, 2017, 9:18pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/4 "2017-08-18T21:18:40Z")
Thanks for the suggestion. Interesting path, definitely.
I’ve found what looks to be the function that initiates the update:
>
But that can only be kicked off when I have detected the local git version, the version available and compared the two. So I would need to take care of that to mimic the user interaction with the interface, which is starting to look a bit complex.
It would, as you point out, be a faster upgrade compared to rebuild. But if I already have local and remote git commit, I would be okay with using that in bash and just having the upgrade take a bit longer over poking this deep into discourse.
---
### Author:  [@simonclausen](https://meta.discourse.org/u/simonclausen)
#### Post date: [August 18, 2017, 9:22pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/5 "2017-08-18T21:22:42Z")
Thanks for the suggestion.
I may need to dive into the documentation a bit more to understand fully.
Is my understanding right that you are suggesting that I just build a new web container and then switch traffic over to the new one and pull down the old when done? I.e. “containers/web1.yml” and “containers/web2.yml”.
I would need a load balancer or traffic forwarder of sorts in front of the containers, right?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [August 18, 2017, 9:27pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/6 "2017-08-18T21:27:47Z")
See [Move from standalone container to separate web and data containers](https://meta.discourse.org/t/how-to-move-from-standalone-container-to-separate-web-and-data-containers/29413)
---
### Author:  [@simonclausen](https://meta.discourse.org/u/simonclausen)
#### Post date: [August 18, 2017, 9:44pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/7 "2017-08-18T21:44:23Z")
Thanks for the link. Reading that thread and [this post](https://meta.discourse.org/t/faster-rebuilds/40341/13) made it clear.
The new web container can be build behind the scenes and then switched over. So I would end up with:
```plaintext
cd /var/discourse
git pull
./launcher bootstrap web_only
./launcher destroy web_only
./launcher start web_only
```
Over
```plaintext
cd /var/discourse
git pull
./launcher rebuild app
```
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [August 18, 2017, 9:45pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/8 "2017-08-18T21:45:56Z")
> [@simonclausen](#):
>
> ./launcher bootstrap web\_only
> ./launcher destroy web\_only
> ./launcher start web\_only
or
```plaintext
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only
```
That way, if the bootstrap fails, you won’t kill your working server.
---
### Author:  [@simonclausen](https://meta.discourse.org/u/simonclausen)
#### Post date: [August 18, 2017, 9:50pm UTC](https://meta.discourse.org/t/looking-up-available-upgrades-via-cli/68330/9 "2017-08-18T21:50:12Z")
Yes, very good point. Thank you!