Re: cf restage and downtime

Dieu Cao <dcao@...>

Yes, we think that with the initial scope of work for the v3 cc api that
we'll have the primitives to be able to orchestrate a rolling deploy. In
v3, we've already separated out the staging step so that a new package can
be uploaded and staged without affecting the running app.


On Mon, Jul 6, 2015 at 9:00 PM, Mike Youngstrom <youngm(a)> wrote:

At one point Diego was slated to look at support for rolling
restart/restage. Is that still being considered in Diego's roadmap? Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.


On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)> wrote:

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.


On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)> wrote:


We use some user-provided services to provide some configurations to our
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,

cf-dev mailing list

cf-dev mailing list

cf-dev mailing list

Join to automatically receive all group messages.