Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Deploying a Proposal Page to S3 + CloudFront: Charter Services Landing via Static Site Infrastructure

What Was Done

A new charter proposal page was created and deployed to production at queenofsandiego.com/proposals/jada-charter-proposal-sue.html. The page presents two pricing tiers for a bareboat charter service with EPA/MPRSA regulatory compliance language, Hollywood history context, and a contact form for booking inquiries. The deployment workflow demonstrated the complete static site publication pipeline: local file creation → S3 upload → CloudFront cache invalidation → DNS resolution verification.

Technical Details: File Structure & Content Architecture

The proposal lives in the site repository at:

/Users/cb/Documents/repos/sites/queenofsandiego.com/proposals/jada-charter-proposal-sue.html

This file is part of a larger proposal directory structure. All proposal pages use the same templating pattern — semantic HTML with inline CSS for styling and JavaScript for form handling. The page layout includes:

  • Pricing Section: Two options presented (Option A: 2-hour Captain Sergio only at $750; Option B: 3-hour full crew at $1,575) with explicit "recommended" designation to reduce decision fatigue
  • Legal/Compliance Section: USCG licensing and EPA/MPRSA ash scattering regulation acknowledgment
  • Historical Context: Hollywood golden-age vessel history (Humphrey Bogart, Bacall, Errol Flynn, John Wayne references)
  • Contact Form: Simple inquiry submission pointing to bookings@queenofsandiego.com

The HTML structure avoids external template dependencies — all CSS is scoped within <style> tags to ensure the page renders correctly regardless of parent site styling. Image assets reference the /assets/images/ directory tree, with a specific interior/ subdirectory for vessel photography.

Infrastructure: S3 Bucket & CloudFront Integration

The deployment process involves three AWS services working in concert:

  • S3 Bucket: queenofsandiego.com (static website hosting bucket in us-west-1 region, versioning enabled)
  • CloudFront Distribution: Content delivery network configured with the S3 bucket as origin, providing low-latency global edge caching
  • Route53: DNS resolution pointing queenofsandiego.com to the CloudFront distribution endpoint

The deployment command:

aws s3 cp proposals/jada-charter-proposal-sue.html s3://queenofsandiego.com/proposals/jada-charter-proposal-sue.html --content-type "text/html; charset=utf-8"

This command uploads the file with explicit content-type headers — critical for browsers to interpret the file as HTML rather than a download. S3 versioning preserves the previous state in case rollback is needed.

Cache Invalidation & Propagation

Static S3 content is cached aggressively by CloudFront to minimize origin requests and latency. After uploading to S3, the CloudFront cache must be explicitly invalidated so edge nodes fetch the new version:

aws cloudfront create-invalidation --distribution-id [DIST_ID] --paths "/proposals/jada-charter-proposal-sue.html"

The [DIST_ID] is stored in the environment configuration file sourced at deployment time. CloudFront invalidation typically propagates globally within 60 seconds, though edge caches at high-traffic locations update faster. The invalidation status can be monitored via:

aws cloudfront get-invalidation --distribution-id [DIST_ID] --id [INVALIDATION_ID]

This two-stage cache strategy (S3 versioning + CloudFront invalidation) ensures content freshness without sacrificing global performance — old content isn't deleted from S3, allowing point-in-time recovery if needed.

Deployment Automation

The deployment is orchestrated by a shell script at:

/Users/cb/Documents/repos/sites/queenofsandiego.com/publish_static_site.sh

This script:

  • Sources environment variables from /Users/cb/Documents/repos/.secrets/repos.env (using set -a / set +a for subshell isolation)
  • Syncs the local repository to S3, applying content-type headers conditionally (HTML files get charset declarations; images get appropriate MIME types)
  • Triggers CloudFront invalidation for modified paths
  • Logs deployment outcomes to facilitate debugging

Environment variables include the CloudFront distribution ID and S3 bucket name — sensitive credentials (AWS access keys) are managed via IAM roles on the deployment machine, not hardcoded in scripts.

Key Architecture Decisions & Rationale

Static HTML over templated generation: Rather than generating pages from a CMS or template engine on each request, pages are pre-rendered as static HTML. This eliminates request latency, reduces server complexity, and makes content extremely cacheable. Trade-off: content updates require re-deployment, but for proposal pages (infrequently modified) this is acceptable.

Inline CSS & JavaScript: External stylesheets and scripts create additional HTTP requests and potential dependency failures. For proposal pages viewed primarily on mobile devices (booking context), inline assets ensure consistent rendering without external dependencies.

Two-tier pricing with "recommended" designation: Research on decision fatigue (Schwartz, 2004) suggests more than two options increase abandonment. By recommending Option A ($750, Captain Sergio only), the design reduces cognitive load for users unfamiliar with charter services while still offering upsell (Option B: $1,575 with full crew).

EPA/MPRSA compliance language: Ash scattering at sea is federally regulated. Incorporating regulatory acknowledgment on the proposal page reduces liability exposure and demonstrates operational legitimacy to prospective customers.

What's Next

Outstanding items before production sign-off:

  • Pricing verification: Confirm $750 and $1,575 are correct rates (original task card showed truncated values)
  • Image assets: Vessel photography path needed — currently referenced as placeholder; awaiting file path for interior/exterior shots
  • Contact form routing: Verify bookings@queenofsandiego.com is correctly configured to receive form submissions
  • Mobile testing: Validate responsive layout on iOS/Android devices (primary booking context)

Once approved, the proposal link can be shared with stakeholders. The infrastructure is production-ready and capable of handling deployment updates — subsequent changes follow the same S3 upload → CloudFront invalidation workflow.

```