Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Deploying a Static Proposal Page: S3 + CloudFront + Route53 for Ash Scattering Charter Services

Overview

This post documents the deployment of a new proposal page for a marine charter service. The page existed as a template but was never deployed to production. We created the missing HTML file, populated it with pricing options, regulatory compliance notes, and marketing content, then pushed it live via S3 and invalidated CloudFront caches to ensure immediate availability.

What Was Done

  • Created /Users/cb/Documents/repos/sites/queenofsandiego.com/proposals/jada-charter-proposal-sue.html with complete proposal content
  • Iterated through 25+ edits to refine messaging, pricing display, and form structure
  • Deployed to S3 bucket at root domain path s3://queenofsandiego.com/proposals/jada-charter-proposal-sue.html
  • Created CloudFront cache invalidation to force edge distribution refresh
  • Verified live deployment at https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html

File Structure & Content Architecture

The proposal page follows a component-based HTML structure:

/proposals/jada-charter-proposal-sue.html
├── Greeting section (personalized, single-recipient)
├── Title block (proposal-title class)
├── Pricing options (Option A: Captain-only, Option B: Full crew)
├── Legal compliance section (USCG, EPA/MPRSA ash scattering regulations)
├── Hollywood history context (marketing/differentiation)
├── Q&A form (bookings@queenofsandiego.com endpoint)
└── Footer

Design decision: Limited to two pricing tiers with explicit recommendation (Option A). This reduces decision fatigue for the recipient—a common friction point in charter booking flows. The template structure allows personalization via server-side rendering or manual variable substitution before sending.

Pricing & Business Logic

The page presents two clear options:

  • Option A (Recommended): 2-hour charter, Captain Sergio only — $750 flat rate
  • Option B: 3-hour charter, full crew — $1,575 flat rate

Both options include statutory compliance documentation (USCG licensing, EPA/MPRSA regulations for ash scattering ceremonies). This was critical because ash scattering at sea involves federal maritime law and environmental protection act requirements that must be clearly communicated upfront.

Infrastructure & Deployment Pipeline

S3 Configuration

The static site is hosted in S3 at bucket name queenofsandiego.com. The deployment workflow:

# Source environment variables (credentials stored in .secrets/)
set -a; source /Users/cb/Documents/repos/.secrets/repos.env; set +a

# Copy the file to S3
aws s3 cp proposals/jada-charter-proposal-sue.html \
  s3://queenofsandiego.com/proposals/jada-charter-proposal-sue.html \
  --region us-west-2

Why S3? Static HTML with no backend rendering. S3's built-in versioning, ACLs, and lifecycle policies handle our operational needs. No compute overhead; minimal latency via CloudFront distribution.

CloudFront Distribution & Cache Invalidation

The S3 bucket is behind a CloudFront distribution. After S3 upload, we must invalidate the cache to force edge nodes to fetch the latest version:

# Create invalidation for the proposal path
aws cloudfront create-invalidation \
  --distribution-id [DISTRIBUTION_ID] \
  --paths "/proposals/jada-charter-proposal-sue.html"

Checking invalidation status:

aws cloudfront get-invalidation \
  --distribution-id [DISTRIBUTION_ID] \
  --id [INVALIDATION_ID]

Why CloudFront? Edge caching reduces latency for geographically distributed users (sailors booking from multiple regions). TTL policies ensure old versions don't persist; invalidation forces immediate refresh. The distribution is tied to the S3 bucket origin via origin access identity (OAI), so direct S3 access is blocked—all traffic flows through CloudFront.

DNS & Route53

Domain routing for queenofsandiego.com is managed in Route53. No changes were required for this deployment—the apex domain already routes to the CloudFront distribution via a DNS alias record. The proposal page inherits this routing automatically.

Content & Personalization Strategy

The proposal includes a greeting section with a placeholder for the recipient's name (extracted from filename: "sue"). This enables:

  • Template reuse: create variants for each prospect by copying and editing the file
  • Personal touch: "Dear Sue, Thank you for your interest..."
  • Tracking: unique URLs per proposal make it easy to identify which variant converted

An alternative approach (not yet implemented) would be URL parameters: /proposals/jada-charter-proposal.html?name=sue with client-side template rendering. This trades URL clarity for reduced file duplication.

Regulatory & Legal Considerations

The page explicitly disclaims that this is not a bareboat charter. Under USCG regulations, a licensed captain must operate the vessel. Additionally, EPA and MPRSA (Marine Protection, Research, and Sanctuaries Act) govern ash scattering at sea—depth, distance from shore, and documentation requirements are strict. Including this upfront prevents legal exposure and sets proper expectations.

Marketing Context: Hollywood History Section

The proposal includes a brief Hollywood history section (Humphrey Bogart, Lauren Bacall, Errol Flynn, John Wayne references). This serves multiple purposes:

  • Differentiation: Positions the charter as a unique, storied experience, not commodity transportation
  • Tone: Elevates the offering from "boat rental" to "curated experience"
  • SEO/Shareability: Cultural references increase organic reach if prospects share the proposal

Deployment Verification & Testing

Post-deployment verification:

# Verify S3 object metadata
aws s3api head-object \
  --bucket queenofsandiego.com \
  --key proposals/jada-charter-proposal-sue.html

# Fetch and grep live page
curl -s "https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html" \
  | grep -E "proposal-title|Option A|Option B"

Both commands confirmed the page is live and properly formatted.

Key Decisions & Rationale

  • Static HTML over dynamic rendering: No database or backend service needed. Proposal content is fixed per recipient. HTML is trivial to version-control and easy to audit for legal compliance.
  • S3 + CloudFront over traditional web server: Lower operational overhead, better uptime (99.99% SLA), automatic scaling.