I’d love to be able to roll-back to a previous version. Imagine a bug was pushed to production, and having to wait 15 min for the fix to be deployed seems too long. Can we have rollback to at least previous version, even just retained for 24 hours would be great.
Yeah I want this too. This is on our medium term list, we’re doing some architecture work first and then we can (hopefully) ship orchestration changes much quicker.
Is this still in progress? Or, is there a way to do this by specifying a docker image in the fly.toml file?
I’d also love to be able to specify a previous release number and roll back to it, something like
fly deploy --rollback=212
We, unfortunately, haven’t shipped this yet. We’re furiously replacing Nomad so we’ve gotten behind on quick fixes for now.
You can run
fly deploy -i <url> to deploy a specific Docker image. The only way to get that is to look at the logs during a deploy, though. We don’t have a simple way to show those from previous versions.
Interesting! Would love to see a blog post about this.
Sorry for an ‘any update’ post but… any update on this potential feature?
Would be awesome for closing the gap with our current platform (h*roku), even if only available in API (vs dashboard/flyctl).
+1 on ‘any update’. No rollback is kind of a non-starter for any app serving customers. Gotta be able to rollback quickly if a mistake happens. Thanks for any updates you can provide!
fly deploy rollback feature now …
While trying to setup an SSH server on our Fly VM, we managed to “break” it and the deployment failed so now nothing works …
Well, a specific rollback feature is one for Fly however in the meantime I think you can kind of make your own: run
fly releases --image to get a list of the releases. And in that table you can see the image/hash of each deployment. So if you want to rollback to a particular version, look for its image (right-hand column) and deploy that image e.g
fly deploy -i registry.fly.io/your-app-name@sha256-long-hash-here-from-that-table.
I’m not sure how long Fly stores images for, however I assume all the ones listed are available to deploy.
Is this still the only way - a command in the fly cli would be nice.
A caveat: This won’t rollback secrets and other Fly-specific changes (like app config), just the code (ie, deploys a previously built docker image).
@ignoramous That’s a good point. I was thinking someone would use a rollback within minutes of a prior deploy and so that would be less of an issue. But you are right to highlight it. That’s why this is kind of improvised. I would guess any future official rollback feature would include both the code and config (the state). This approach doesn’t.
I would love to have the rollback feature too. My site just crashes after deployment and I have no idea how to recover it. It took me 20mins to figure out what happened and try to redeploy the app.
Ref: Add "fly app rollback 731" command · Issue #579 · superfly/flyctl · GitHub I imagine this feature won’t be easy for Fly to implement.
The way we do it is, deploy to two Fly apps. One runs last known good deployment but with only one or two VMs (I call this env,
lgtm-box), typically a release behind. The other is a proper prod environment, which means, it is also our test environment
If something goes wrong, I scale up the
lgtm-box and flip the DNS entries to point to it, while I figure out just what went wrong when testing in prod…
This means, if you’ve a database layer or any external state, it must at all times work with code running in the