Staging a Major Site Section Without Downtime: Zuniga Days Launch Strategy
This post documents the deployment strategy and infrastructure decisions made while adding a new "Zuniga Days" section to zunigashoals.com—a substantial addition (~212 lines of CSS, HTML, and JavaScript) that needed to be validated in staging before production merge.
What Was Done
We added a new event-promotion section to the Zuniga Shoals landing page with the following components:
- Sticky top ribbon announcing "Zuniga Days · the last free open anchorage in San Diego"
- Full-page section with event pillars (permit-free, free-to-anchor, no rules)
- Six activity tiles describing unsanctioned races, contests, and raftups
- Email capture form integrated with existing Google Apps Script (GAS) backend
- Call-to-action linking back to themed merchandise in the shop
All changes were deployed to a staging prefix on S3 without touching production, with a full snapshot preserved for rollback.
Technical Details: The Additive Deployment Pattern
File Organization & Staging Strategy
Rather than creating a separate staging site or branching the entire HTML structure, we used an S3 prefix-based staging approach:
Production (live):
s3://zunigashoals.com/index.html
Staging (isolated):
s3://zunigashoals.com/_staging/index.html
This strategy offers several advantages:
- Zero production impact: The prod file remains untouched and served via CloudFront
- Same domain/origin: Staging uses the same S3 bucket and CloudFront distribution, avoiding CORS issues or separate SSL certificates
- Easy rollback: If the staging version needs adjustments, we can iterate on `/_staging/` without affecting visitor traffic
- Cache isolation: The `/_staging/` prefix is not part of the default CloudFront cache rules, so staging changes are live immediately
Snapshot & Versioning
Before any modifications, we created a timestamped backup of production:
/tmp/zunigashoals.com__index.html__2026-05-26T17-31-10Z.prod-snapshot
This snapshot serves two purposes:
- Audit trail: Exact record of what was live before changes
- One-command rollback: If staging reveals issues, re-uploading this file restores the exact previous state
Content Assembly & Validation
The staging file was built by:
- Reading current prod `index.html` from S3
- Injecting new CSS rules into the `