# How to develop/manage with rancher? **URL:** \ **Category:** Rancher 1.x\ **Created:** [September 29, 2015, 3:28pm UTC](https://forums.suse.com/t/how-to-develop-manage-with-rancher/585 "2015-09-29T15:28:34Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ronag](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/ronag/32/294_2.png) [@ronag](https://forums.suse.com/u/ronag)\ **Post date:** [September 29, 2015, 3:28pm UTC](https://forums.suse.com/t/how-to-develop-manage-with-rancher/585/1 "2015-09-29T15:28:35Z")
How do I manage updates of containers? We’re currently in a development phase an every time we need to update a container we need to do the following: - Push the new image to docker hub. - Delete the entire stack in rancher. - SSH into the host and run `docker-pull`. - Run `rancher-compose up` with the correct configuration files. This seems a little bit tedious to say the least. What is the correct procedure for this? ---
**Author:** ![denise](https://avatars.discourse-cdn.com/v4/letter/d/82dd89/32.png) [@denise](https://forums.suse.com/u/denise)\ **Post date:** [September 29, 2015, 5:03pm UTC](https://forums.suse.com/t/how-to-develop-manage-with-rancher/585/2 "2015-09-29T17:03:27Z")
In v0.39.0 of rancher and v0.4.0 of rancher-compose, we have `rancher-compose pull` that allows you to pull new images to the hosts. After you’ve pulled the new images, you can use `rancher-compose upgrade` to deploy a new service using the new images. [http://docs.rancher.com/rancher/rancher-compose/upgrading/](http://docs.rancher.com/rancher/rancher-compose/upgrading/) Also, we have a in-service upgrade that will be coming out in an upcoming release. [https://github.com/rancher/rancher/issues/1874](https://github.com/rancher/rancher/issues/1874) ---
**Author:** ![ronag](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/ronag/32/294_2.png) [@ronag](https://forums.suse.com/u/ronag)\ **Post date:** [September 29, 2015, 5:08pm UTC](https://forums.suse.com/t/how-to-develop-manage-with-rancher/585/3 "2015-09-29T17:08:43Z")
Modifying the compose file for a upgrade is a no no, I’m surprised anyone is using that. Wouldn’t that also break any service links? ---
**Author:** ![denise](https://avatars.discourse-cdn.com/v4/letter/d/82dd89/32.png) [@denise](https://forums.suse.com/u/denise)\ **Post date:** [September 29, 2015, 5:43pm UTC](https://forums.suse.com/t/how-to-develop-manage-with-rancher/585/4 "2015-09-29T17:43:42Z")
Links to other services are re-established, but links from other services would need to manually be done. The `rancher-compose upgrade` is for people who are more likely to use the different tags to differentiate versions so that they could try upgrading and if it doesn’t work, they’d be able to have the existing service to use to rollback to if needed. ---
**Author:** ![ronag](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/ronag/32/294_2.png) [@ronag](https://forums.suse.com/u/ronag)\ **Post date:** [September 29, 2015, 8:30pm UTC](https://forums.suse.com/t/how-to-develop-manage-with-rancher/585/5 "2015-09-29T20:30:29Z")
> Links to other services are re-established, but links from other services would need to manually be done. Not good enough. Again, I can’t imagine a scenario where this would be useful. We keep all our configurations in github version control and changing the names of services when upgrading stuff would lead to total confusion and broken services. Especially as the links would be broken and going through every other service every time and change the links would not work in practice. > The rancher-compose upgrade is for people who are more likely to use the different tags to differentiate versions so that they could try upgrading and if it doesn’t work, they’d be able to have the existing service to use to rollback to if needed. We want to be able to upgrade, test and possibly rollback without having to make up new service names and breaking the configuration. This is the main issue holding us back from adopting Rancher. We would prefer a much better service upgrade story, both for development and testing as well as for production. If we need to do a hotfix for a client we need to be able to update a service in 1 minute and have everything up and running and in worst case simply rollback. We can’t run around changing multiple configurations in several steps just to make a simple hotfix. We would be very much interested in either a better description and motivation for `rancher-compose upgrade` or an alternative method.