```html

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:

  1. Reading current prod `index.html` from S3
  2. Injecting new CSS rules into the `