rollback.md Raw History Folder

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 short service interruption is possible, and Gordon never runs two generations of the same service at the same time. If the 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

Git SHA Tags

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 short service interruption is possible, and Gordon never runs two generations of the same service at the same time. If the 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)

rollback.md RawHistoryFolder