Even with automated deployment, having a reliable way to roll back a bad static site deployment quickly is important — this guide covers versioning strategies for static site deployments.
Why Static Sites Need Rollback Planning Too
A "bad deployment" for a static site might mean broken content, a failed build that partially deployed, or a regression a user reports — having a quick rollback path avoids extended exposure to a broken live site while you diagnose and fix the underlying issue properly.
Approach 1: Versioned Deployment Directories
/var/www/mysite/releases/2026-08-28-1200/
/var/www/mysite/releases/2026-08-29-0900/
/var/www/mysite/current -> releases/2026-08-29-0900/Deploy each build to a new timestamped directory, with a symlink (current) pointing to the active version — rollback becomes as simple as repointing the symlink to a previous release directory, near-instant with no rebuild needed.
Nginx Configuration Using the Symlink
root /var/www/mysite/current;Rolling Back with This Approach
ln -sfn /var/www/mysite/releases/2026-08-28-1200 /var/www/mysite/current
sudo systemctl reload nginxInstant rollback — no rebuild, no redeployment, just repointing the symlink and reloading Nginx to pick it up.
Approach 2: Keeping Previous Build Artifacts in CI/CD
See How to Set Up Continuous Deployment for a Static Site with GitHub Actions — retain build artifacts from recent successful deployments (most CI platforms support this), letting you redeploy a known-good previous build without rebuilding from source.
Approach 3: Git-Based Rollback (Rebuild from a Previous Commit)
git revert HEAD
git pushSimplest conceptually — revert the problematic commit and let your normal CI/CD pipeline rebuild and redeploy; slower than the symlink approach (requires a full build cycle) but requires no special deployment infrastructure beyond what you already have.
Cleaning Up Old Release Directories
find /var/www/mysite/releases -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;If using versioned directories, periodically clean up old releases to avoid unbounded disk usage growth — retain enough history for reasonable rollback needs (perhaps the last 5-10 releases) without keeping everything indefinitely.
Testing Your Rollback Process
Similar to How to Test a Full Disaster Recovery Scenario (Fire Drill) — actually test your rollback mechanism works as expected before you need it during a genuine incident; a rollback process that's never been tested may have gaps discovered at the worst possible time.
Documenting the Rollback Procedure
Ensure whoever might need to perform a rollback (not just the original implementer) has clear documentation of exactly how to do it — similar principle to How to Document a Disaster Recovery Runbook, applied at a smaller scale.
Combining with Health Monitoring
See How to Monitor Deployment Health and Auto-Rollback on Failure — for a static site with meaningful traffic, consider whether automated health checking after deployment (even something simple, like verifying key pages return 200 status) is worth implementing alongside manual rollback capability.
Common Errors
Rollback via symlink doesn't take effect immediately — verify Nginx was actually reloaded after the symlink change; some caching layers (browser cache, CDN cache) may also need consideration if the "broken" version was already cached by visitors/edge nodes.
Continue Reading
- How to Set Up Continuous Deployment for a Static Site with GitHub Actions
- How to Roll Back a Bad Deployment Quickly
- How to Monitor Deployment Health and Auto-Rollback on Failure
Browse more articles in Static Site Hosting & Frontend Deployment.
