Rollback
Roll forward to a previous version when a deploy misbehaves. There is no historical rollback command in v3: rolling back means applying and deploying a previous manifest or image reference. Redeploying a mutable tag (for example latest) does not guarantee the previous image bytes; keep immutable versioned tags.
Roll Forward to a Previous Tag
The image tags are still in the registry. Point the app file at the last good tag, apply, deploy:
# 1. Edit blog.toml: image = "gordon.mydomain.com/myapp:v2.0.0"
gordon apps apply --file blog.toml --remote prod
gordon apps deploy blog --remote prod
A rollback deploy replaces services one at a time like any other deploy: a stateless TCP or HTTP service is replaced without downtime, while a service with a volume, bind, device, or UDP interface is replaced sequentially, may be briefly interrupted, and never has two generations running at once. If a sequential replacement fails after the old container was removed, Gordon does not recreate it and does not promise automatic data rollback.
Re-push the Previous Image as latest
When the app file tracks latest, re-tag and re-push, then deploy (deploy re-resolves mutable tags):
docker pull gordon.mydomain.com/myapp:v2.0.0
docker tag gordon.mydomain.com/myapp:v2.0.0 gordon.mydomain.com/myapp:latest
docker push gordon.mydomain.com/myapp:latest
gordon apps deploy blog --remote prod
Version Management
Keep Previous Versions
Always push versioned tags alongside latest:
VERSION=$(git describe --tags)
docker tag myapp gordon.mydomain.com/myapp:$VERSION
docker tag myapp gordon.mydomain.com/myapp:latest
docker push gordon.mydomain.com/myapp:$VERSION
docker push gordon.mydomain.com/myapp:latest
Semantic Versioning
Use semantic versions for clear recovery targets:
v2.1.0 ← Current (broken)
v2.0.0 ← Recovery target
v1.9.0 ← Older stable
Tag with commit SHA for precise recovery:
# Deploy
SHA=$(git rev-parse --short HEAD)
docker push gordon.mydomain.com/myapp:$SHA
Verifying Recovery
After re-deploying the previous version:
# Check the app's effective vs observed state
gordon apps status blog --remote prod
# Check application responds
curl -I https://app.mydomain.com
# Check logs
gordon apps logs blog --remote prod
Best Practices
- Always tag versions - Don't rely solely on
latest
- Keep N previous versions - Maintain recovery options
- Test before deploy - Reduce need for rollbacks
- Document known-good versions - Track stable releases
source
1# Rollback
2
3Roll forward to a previous version when a deploy misbehaves. There is no historical rollback command in v3: rolling back means applying and deploying a previous manifest or image reference. Redeploying a mutable tag (for example `latest`) does not guarantee the previous image bytes; keep immutable versioned tags.
4
5## Roll Forward to a Previous Tag
6
7The image tags are still in the registry. Point the app file at the last good tag, apply, deploy:
8
9```bash
10# 1. Edit blog.toml: image = "gordon.mydomain.com/myapp:v2.0.0"
11gordon apps apply --file blog.toml --remote prod
12gordon apps deploy blog --remote prod
13```
14
15A rollback deploy replaces services one at a time like any other deploy: a stateless TCP or HTTP service is replaced without downtime, while a service with a volume, bind, device, or UDP interface is replaced sequentially, may be briefly interrupted, and never has two generations running at once. If a sequential replacement fails after the old container was removed, Gordon does not recreate it and does not promise automatic data rollback.
16
17## Re-push the Previous Image as latest
18
19When the app file tracks `latest`, re-tag and re-push, then deploy (deploy re-resolves mutable tags):
20
21```bash
22docker pull gordon.mydomain.com/myapp:v2.0.0
23docker tag gordon.mydomain.com/myapp:v2.0.0 gordon.mydomain.com/myapp:latest
24docker push gordon.mydomain.com/myapp:latest
25gordon apps deploy blog --remote prod
26```
27
28## Version Management
29
30### Keep Previous Versions
31
32Always push versioned tags alongside `latest`:
33
34```bash
35VERSION=$(git describe --tags)
36docker tag myapp gordon.mydomain.com/myapp:$VERSION
37docker tag myapp gordon.mydomain.com/myapp:latest
38docker push gordon.mydomain.com/myapp:$VERSION
39docker push gordon.mydomain.com/myapp:latest
40```
41
42### Semantic Versioning
43
44Use semantic versions for clear recovery targets:
45
46```
47v2.1.0 ← Current (broken)
48v2.0.0 ← Recovery target
49v1.9.0 ← Older stable
50```
51
52### Git SHA Tags
53
54Tag with commit SHA for precise recovery:
55
56```bash
57# Deploy
58SHA=$(git rev-parse --short HEAD)
59docker push gordon.mydomain.com/myapp:$SHA
60```
61
62## Verifying Recovery
63
64After re-deploying the previous version:
65
66```bash
67# Check the app's effective vs observed state
68gordon apps status blog --remote prod
69
70# Check application responds
71curl -I https://app.mydomain.com
72
73# Check logs
74gordon apps logs blog --remote prod
75```
76
77## Best Practices
78
791. **Always tag versions** - Don't rely solely on `latest`
802. **Keep N previous versions** - Maintain recovery options
813. **Test before deploy** - Reduce need for rollbacks
824. **Document known-good versions** - Track stable releases
83
84## Related
85
86- [Deployment Overview](./index.md)
87- [GitHub Actions](./github-actions.md)
88- [Apps CLI](../cli/apps.md)