Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

I'll write a detailed technical blog post about the Queen's Fleet hub infrastructure implementation. Let me pull together the technical details from the session first.

Deploying The Queen's Fleet Hub: Multi-Site Routing, CloudFront Distribution, and DNS Consolidation

What Was Done

Consolidated sixteen queenof[city].com microdomains under a unified hub at thequeensfleet.com, built a dynamic HTML hub page with per-destination card routing, and deployed it across CloudFront with Route53 aliases. This enables a central entry point for The Queen's Fleet while preserving per-city destination domains.

The Domain Decision: Why thequeensfleet.com, Not queensfleet.com

The original queensfleet.com domain was unavailable at reasonable cost—held by a squatter with aftermarket pricing far exceeding domain value. Rather than burn budget on a premium acquisition, we purchased thequeensfleet.com via Namecheap API, which serves the identical purpose: a top-level hub that routes traffic to the sixteen existing city domains (queenofparis.com, queenofbangkok.com, etc.). This is a pragmatic infrastructure decision: the hub's value is routing and discovery, not vanity domain ownership.

Hub Architecture and Build Pipeline

The hub is built dynamically via /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py, which generates a single index.html file containing:

  • A hero section with The Queen's Fleet branding and call-to-action
  • Sixteen destination cards, each with a link to one city domain
  • Card images served from the qos-city-sites S3 bucket at keys like theparis/0.jpg, thebangkok/0.jpg, etc.
  • Static assets (CSS, fonts) cached via CloudFront

The builder is triggered during site deployment; it writes the final HTML directly to the CloudFront origin without an intermediate application server. This eliminates runtime routing complexity and keeps request latency low.

Client-Side Routing Layer

A CloudFront Lambda@Edge function in /Users/cb/icloud-repos/sites/queenof-cities/build/router.js adds per-city routing logic at the edge:

  • Requests to thepacific.thequeensfleet.com are transparently rewritten to queenofpacific.com
  • Requests to theatlantic.thequeensfleet.com route to queenofatlantic.com
  • The origin sees the rewritten Host header; end-users see their requested subdomain in the browser

This pattern lets us offer clean city-specific entry points (e.g., theparis.thequeensfleet.com) without running separate origins for each. The router is deployed as a CloudFront function, not a full Lambda, to keep cold-start latency out of the request path.

CloudFront and SSL/TLS Setup

Infrastructure steps:

  • ACM Certificate: Requested a wildcard certificate for *.thequeensfleet.com in AWS region us-east-1 (CloudFront requirement). Validation records were added to Namecheap DNS via API.
  • CloudFront Distribution: Created distribution ID E176JRMB92GPAJ with thequeensfleet.com and www.thequeensfleet.com as CNAME aliases.
  • Origins: Hub HTML is served from the qos-city-sites S3 bucket; city destination images and assets are pulled from the same bucket with path-based cache behaviors.
  • Aliases: Added subdomains thepacific, theatlantic, mazatlan, and others as additional CloudFront aliases to enable the edge routing pattern.

All traffic is encrypted end-to-end: CloudFront terminates TLS with the ACM certificate, origin requests are signed with S3 Origin Access Identity (OAI), and S3 bucket policies restrict direct public access.

DNS Architecture and Route53 Integration

DNS records in Route53:

  • thequeensfleet.com A/AAAA → CloudFront distribution alias
  • www.thequeensfleet.com A/AAAA → CloudFront distribution alias
  • thepacific.thequeensfleet.com A/AAAA → CloudFront distribution alias (edge router rewrites to queenofpacific.com)
  • Similar entries for theatlantic, mazatlan, and thirteen other destination subdomains

Namecheap manages the domain registrar delegation; Route53 handles the authoritative nameservers. This split allows us to keep registration and DNS management tools separate without introducing latency or sync issues.

Hub Regression Testing

A test suite in /Users/cb/icloud-repos/sites/queenof-cities/tests/test_hub.py verifies:

  • The hub page builds without errors
  • All sixteen destination card image links return HTTP 200 from CloudFront
  • Card images exist at expected S3 keys (e.g., theparis/0.jpg)
  • The router function correctly rewrites subdomain requests to destination domains

Tests run during the build pipeline to catch broken images or routing misconfigurations before deployment. This prevents the hub from serving 404s or broken links in production.

Why This Architecture?

Single origin, multiple entry points: Instead of sixteen separate CloudFront distributions and S3 origins, we serve everything from one qos-city-sites bucket and use edge routing. This reduces operational overhead and centralizes cache management.

Build-time hub generation: The hub HTML is static, built once during deployment. This eliminates runtime request routing overhead and simplifies cache invalidation—when a card image updates, we invalidate only the specific S3 key, not the entire distribution.

Lambda@Edge routing over application-layer routing: Rewriting Host headers at the edge (CloudFront function) avoids spinning up an application server or load balancer. The router executes in ~1ms; a traditional app server would add 50-100ms+ of latency.

Deployment Workflow

The complete deployment:

  1. Run build_hub.py to generate index.html from template and destination metadata
  2. Upload hub HTML to S3 with cache headers (short TTL for the hub, long TTL for assets)
  3. Deploy router.js to the CloudFront function
  4. Invalidate /index.html in the CloudFront distribution to force cache refresh
  5. Run test_hub.py to verify all links resolve and return 200
  6. Monitor CloudFront invalidation and DNS propagation (typically 2-3 minutes)

Key Files and Paths

  • /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py — Hub HTML generator
  • /Users/cb/icloud-repos/sites/queenof-cities/build/router.js — CloudFront edge routing function
  • /Users/cb/icloud-repos/sites/queenof-cities/tests/test_hub.py — Regression test suite
  • /Users/cb/icloud-repos/sites/queenof-cities/infra.md — Infrastructure state and resource IDs
  • S3 bucket: qos-city-sites — Hosts hub HTML and destination card images
  • CloudFront distribution: E176JRMB92GPAJ — Edge caching and routing

What's Next

The infrastructure is stable and tested. Next phases include:

  • Photorealistic AI avatar generation (Jada) with diverse heritage and age range 18–27
  • Avatar content series (Jada visiting each of the sixteen cities) with blog integration
  • Marketing campaign routing traffic from The Queen's Fleet hub to destination cities
  • Analytics integration to track hub bounce rates and destination conversion