Infrastructure Rollback Strategies

By Kokil Thapa | Last reviewed: September 2026

A bad deploy at 11 PM should not mean rebuilding servers from scratch. Infrastructure rollback strategies define how you undo application releases, server config, and cloud resources without guessing under pressure. On production Linux VPS and EC2 stacks I maintain with Deployer 7 and GitLab CI, rollback is a first-class step—not a panic button. This guide covers the patterns that actually work for Laravel 12/13 apps, Terraform-managed cloud, and small teams running business-critical sites in Nepal and abroad.

How do infrastructure rollback strategies differ from application rollbacks?

Application rollback usually means reverting code. Infrastructure rollback covers everything the app runs on: web server config, PHP-FPM pools, DNS, firewall rules, database schema, and cloud networking. A Laravel deploy can succeed while Nginx still points at the wrong socket.

Think in layers. Each layer needs its own undo path and its own time limit. Mixing them causes the classic failure: code rolls back but migrations do not, and the site white-screens.

Immutable infrastructure—new servers from golden images—changes the model. You do not patch a broken box; you replace it with the last known-good image. That trades speed for predictability. See immutable vs mutable infrastructure for when each fits.

Rollback speed vs blast radius

Your runbook should name the layer first. Teams that jump straight to database restore often overwrite good data while the real bug was a stale opcache after deploy.

What rollback patterns work best for Laravel deployments on Linux?

For Laravel 12 or 13 on Ubuntu 22/24, symlink-based releases remain the most reliable pattern I use in production. Deployer 7 keeps the last five releases under releases/ and swaps the current symlink. Rollback is one command—not a re-clone from Git.

Sister legal-tech sites on shared EC2—Notary Kathmandu, Court Marriage In Nepal, Translation Nepal—share this pipeline. The same GitLab CI job that deploys can trigger rollback when smoke tests fail.

Deployer rollback commands

# Roll back to previous release on production host
dep rollback production

# List available releases before choosing
dep releases production

# After symlink swap, reload PHP-FPM (opcache stale code is common)
sudo systemctl reload php8.4-fpm

Keep shared/.env and shared/storage outside releases. Rolling back code must not roll back uploaded documents on a client portal. That pattern appears on projects like Mijar Law Associates where file integrity matters.

Laravel-specific rollback checklist

1. Confirm whether migrations ran in the failed release. Forward-only migrations need a compensating migration, not just dep rollback.
2. Restart queue workers after symlink swap. Old workers still hold old autoload paths in memory.
3. Verify cron entries point at current/artisan, not a stale release path. I have seen scheduled jobs silently stop after rollback.
4. Clear config and route cache if you deploy with config:cache and route:cache.
5. Run a smoke test against login, checkout, or booking—whatever path pays the bills.

Pair this with Ubuntu server backup strategies so rollback covers files and database, not only PHP code.

How do you roll back Terraform infrastructure safely?

Cloud rollback through Terraform is git revert plus plan, not a magic undo button. Terraform tracks desired state. Rolling back means re-applying an older commit that described working infrastructure.

State file integrity is the constraint. Without remote state in S3 or Terraform Cloud, two engineers applying different commits will corrupt rollback paths. Locking and versioning are non-negotiable for production.

Safe Terraform rollback workflow

# 1. Identify last good commit on main
git log --oneline infrastructure/

# 2. Revert the bad commit (prefer revert over reset on shared branches)
git revert abc1234

# 3. Plan before apply — read every destroy/create line
terraform plan -out=rollback.tfplan

# 4. Apply only after human review
terraform apply rollback.tfplan

Some resources cannot roll back cleanly. RDS instance class downsizing may force replacement. DNS TTL delays propagation. Security group changes can drop active connections. That is why zero-downtime Terraform updates and drift detection belong in the same pipeline as rollback planning.

Official guidance from HashiCorp on Terraform state stresses that state is the source of truth for what exists in the cloud. Treat state backups like database backups.

When Terraform rollback is the wrong move

• Destructive changes already deleted data-bearing resources.
• Manual console edits created drift Terraform will fight on apply.
• Cross-stack dependencies mean reverting one module breaks another.

In those cases, forward-fix from a known-good plan or restore from snapshot. Infrastructure as Code does not remove judgment—it documents it.

When should you restore from backup instead of rolling back a release?

Release rollback fixes bad code. It does not fix corrupted data, ransomware, or a migration that dropped a column. Backup restore is the infrastructure rollback strategy of last resort—and the one you must rehearse.

On small MySQL 9.7 or MariaDB 12.3 VPS hosts, I keep nightly logical dumps plus binlogs where budget allows. Restore time beats backup frequency every time. A hourly dump you cannot restore in under an hour is theatre.

Read design a backup strategy that works and database backup strategies for small servers before you need them. Validate dumps monthly with a restore to a staging schema—use the JSON formatter to inspect API health responses during restore tests if your app exposes structured status endpoints.

Point-in-time recovery basics

# Restore logical dump to staging (never test on production first)
mysql -u root -p staging_db < /backups/nightly_2026-09-11.sql

# Verify row counts and critical business rows
mysql -u root -p staging_db -e "SELECT COUNT(*) FROM orders WHERE created_at > CURDATE() - INTERVAL 1 DAY;"

For eCommerce stacks like Quick And Easy Nepalese Grocery, order and payment tables define whether rollback or restore is safer. Never restore a full dump over production without a written decision and a maintenance window.

How do you test rollback procedures before production fails?

Untested rollback is wishful thinking. Schedule a quarterly rollback drill on staging that mirrors production: same Deployer recipe, same PHP-FPM version, same queue driver. Document actual minutes, not estimates.

GitOps-style pipelines add promotion gates. A failed smoke test should block traffic shift automatically. Compare approaches in GitOps for infrastructure vs application GitOps.

Minimum runbook fields

• Trigger: error rate, failed health check, payment webhook failures.
• Owner: who executes rollback and who approves database restore.
• Steps: exact commands, hostnames, no placeholders.
• Verification: URLs, SQL checks, queue depth normal.
• Comms: status page or client email template for Nepal business hours.
• RTO target: e.g. 15 minutes for symlink, 4 hours for full DB restore.

Store runbooks in Git beside infrastructure code. Declarative vs imperative infrastructure debates matter less than whether the on-call engineer can follow steps at 2 AM.

For booking platforms such as Adventure Third Pole Trek, rollback drills should include Livewire session behaviour and supplier notification queues. A silent queue stall hurts revenue even when the homepage loads.

What common mistakes break infrastructure rollback strategies?

Teams often optimize deploy speed and treat rollback as an appendix. These failures recur on client projects and my own maintained servers.

Mutable server drift

SSH fixes applied directly on production are invisible to Deployer and Terraform. Rollback restores code but leaves manual Nginx edits. Prefer config in Git and documented maintenance windows.

Non-reversible migrations

Laravel migrations without down() methods—or destructive down() on large tables—block clean release rollback. Ship backward-compatible migrations first; drop columns in a later release after rollback is no longer needed.

Single copy of Terraform state

Local terraform.tfstate on a laptop cannot support team rollback. Use remote backend with versioning per HashiCorp S3 backend documentation.

Ignoring opcache and workers

PHP 8.4 opcache can serve old bytecode after symlink swap until FPM reload. Horizon and queue:work processes need restart too. This is the top “rollback did not work” report I see on Laravel hosts.

Container teams face parallel issues: rolling back an image tag while Kubernetes still runs old pods with imagePullPolicy: IfNotPresent. Tag immutability and explicit rollouts matter—see Docker image tagging strategies.

Key Takeaways

• Map rollback per layer: release, config, IaC, and data each need a distinct undo path and time budget.
• Use symlink releases with Deployer 7 for Laravel on VPS; run dep rollback then reload PHP-FPM and restart queues.
• Revert Terraform via Git and reviewed terraform plan; never apply blind after infrastructure changes.
• Restore from backup when data is corrupt—not when only application code is wrong.
• Run quarterly rollback drills with timed runbooks; automate rollback on failed smoke tests in CI.
• Keep migrations backward-compatible until you are sure the release will not be rolled back.

People Also Ask

What is the difference between rollback and failover?

Rollback returns a system to a previous known-good version on the same infrastructure. Failover shifts traffic to standby servers or another region. Rollback fixes bad changes; failover handles total site loss. Multi-region failover adds cost and complexity most SMB Laravel VPS setups do not need until uptime SLAs demand it.

How many old releases should you keep for rollback?

Deployer’s default of five releases is a sensible minimum for PHP apps. Keep enough disk for at least three full releases plus shared storage. For container registries, retain the last ten immutable tags and delete untagged layers on a schedule.

Can you roll back a database migration automatically?

Laravel supports php artisan migrate:rollback, but automatic migration rollback in production is risky on large tables. Prefer forward-fix migrations unless the schema change is trivial and tested. Always take a pre-deploy dump when migrations touch production data.

Does blue-green deployment eliminate rollback?

Blue-green reduces downtime by switching traffic between two environments. You still need a rollback strategy—switch traffic back to blue if green fails smoke tests. The idle environment is your rollback target, not a substitute for backups or tested runbooks.

Build rollback into your next deploy

Strong infrastructure rollback strategies cost little upfront and save hours when a payment gateway webhook or migration misfires. Start with symlink releases, remote Terraform state, verified backups, and a one-page runbook your team has actually executed once. If you want help wiring Deployer, GitLab CI, or backup drills into a production Laravel or legal-tech stack, contact us or explore enterprise application development and full-stack delivery from Kathmandu. Related reading: cloud backup and disaster recovery, infrastructure promotion pipelines, and testing infrastructure code.