With atomic (zero-downtime) deployments, DeployHQ keeps each deploy in its own timestamped release directory and points a current symlink at the live one. Keeping a few previous releases on disk is what makes rolling back to any previous release possible — reverting a bad deploy is just re-pointing the symlink at the release before it. By default DeployHQ keeps 3 releases (the current one plus two previous), pruning older releases on a rolling basis during each deployment.
Setting atomic retention
A number of users asked to control that number themselves, so it's now a setting. Head to your server settings and you'll find an Atomic Retention option within the atomic settings section. It defaults to 3 and can be changed to any number.
DeployHQ server settings' />
Once saved, all future deployments use the new value.
How many releases should you keep?
It's a trade-off between rollback depth and disk space:
- More releases means you can roll back further — useful if a regression slips through and isn't caught until a few deploys later.
- Fewer releases saves disk. Each retained release is a full copy of your built application, so on a large codebase the difference adds up quickly — at the default of 3, budget roughly 3× your app size.
For most single-server setups, 3–5 is the sweet spot: enough history to recover from a bad release you didn't catch immediately, without carrying a stack of stale builds. If your server is disk-constrained, keep it low; if you deploy many times a day and want a wider rollback window, raise it.
Atomic retention is one piece of a zero-downtime setup — if you're still choosing a release strategy, see our guide to zero downtime deployment strategies.
Questions about atomic retention or zero-downtime deployments? Email support@deployhq.com or reach us on X at @deployhq.