Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

I'll read the key documentation files to pull exact technical details for the blog post. /Users/cb/icloud-jada-ops/queens-fleet/AVATAR-PLAN-2026-07-04.md /Users/cb/icloud-jada-ops/decisions/queens-fleet-avatar-and-hub.md /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py /Users/cb/icloud-repos/sites/queenof-cities/build/router.js /Users/cb/icloud-repos/sites/queenof-cities/tests/test_hub.py /Users/cb/icloud-repos/sites/queenof-cities/infra.md

Building a Hub + Spoke Architecture for The Queen's Fleet: Domain Registration, CloudFront Distribution, and Centralized Routing

What Was Done

The Queen's Fleet infrastructure was restructured from independent city-specific domains (queenof[city].com) into a centralized hub-and-spoke topology. A new umbrella domain, thequeensfleet.com, was registered and wired as the primary hub, with an AWS CloudFront distribution serving as the edge router. A shared hub page was deployed to S3 and fronted by CloudFront, complete with a Lambda@Edge function that routes traffic from the apex and all subdomains to their respective city sites. This establishes a single point of presence and brand identity while maintaining the independence of individual city domains.

Domain Strategy: Why thequeensfleet.com?

The target domain queensfleet.com was squatted and listed on the aftermarket at a premium asking price, making acquisition economically unfeasible in the short term. Instead, thequeensfleet.com was registered via Namecheap using existing domain contacts already on file. This semantic variant carries strong brand intent (the article "the" emphasizes the unified fleet concept) and avoids the friction of negotiating with a speculator. The domain was provisioned with immediate DNS records and ACM certificate validation to enable rapid infrastructure deployment.

Infrastructure Decisions

Why CloudFront for the hub? The fleet needed a single, scalable edge that could handle brand-building traffic spikes (influencer launches, social media campaigns) while routing to internal origins—some city sites on S3, others potentially on custom backends. CloudFront offers:

  • Global edge caching and sub-100ms latency to end users
  • Native support for Lambda@Edge functions for request-time routing logic (no separate app server needed)
  • Automatic HTTPS termination with ACM certificate integration
  • Cache invalidation and versioning for instant content updates

Hub page design: Rather than a JavaScript-heavy SPA, the hub is a static HTML page served from S3 (s3://queenof-cities-hub/index.html) and cached aggressively at CloudFront edge. This minimizes latency and reduces potential attack surface. The page is rebuilt automatically during deployments and tagged with ETags to ensure browser-side cache invalidation.

Technical Implementation

ACM Certificate Setup

An ACM certificate for thequeensfleet.com was requested in the us-east-1 region (required for CloudFront). Domain validation used CNAME records inserted into Namecheap DNS via API:

aws acm request-certificate \
  --domain-name thequeensfleet.com \
  --subject-alternative-names www.thequeensfleet.com \
  --validation-method DNS \
  --region us-east-1

Once ACM completed validation, the certificate ARN was bound to the CloudFront distribution.

Hub Builder: build_hub.py

The hub generation script at /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py reads a registry of all city domains from site-registry.yaml, generates HTML tiles for each city, and outputs a static page with embedded navigation. The script runs during CI/CD and produces hub/index.html with hardcoded links to each city's canonical domain. This ensures the hub is always in sync with the registry.

python3 build/build_hub.py --output hub/index.html --registry site-registry.yaml

Router Function: Lambda@Edge

A CloudFront function named qos-city-router was deployed to the distribution's viewer-request stage. This function intercepts all incoming requests and applies routing logic:

// In router.js (deployed to CloudFront)
if (request.uri === '/') {
  request.origin = { s3: { domainName: 's3.amazonaws.com', path: '/queenof-cities-hub' } };
}
// Other routing rules redirect to city origins or cache based on hostname

The function runs at CloudFront edge (no origin latency) and eliminates the need for a separate app-layer router. Deploy is instant and cached globally within seconds.

S3 Origin Configuration

The hub content is stored in a bucket named queenof-cities-hub with static website hosting disabled (CloudFront acts as the single cache layer). The bucket policy restricts access to CloudFront's origin access identity (OAI), preventing direct S3 requests from the internet.

CloudFront Distribution Setup

Distribution ID: E12G09B4XHLS8Y

Configuration:

  • Domains: thequeensfleet.com, www.thequeensfleet.com, and legacy qos-city-router.queenof-cities.internal (for testing)
  • Viewer Protocol Policy: Redirect HTTP to HTTPS
  • Cache Behaviors:
    • Root path (/) → S3 hub origin, 1-hour cache, compressed
    • City subdomains (e.g., san-diego.thequeensfleet.com) → Route to queenof-sandiego.com origin
  • Lambda@Edge Function: qos-city-router attached to viewer-request stage for request-time routing

DNS Propagation

Nameserver records for thequeensfleet.com were updated via Namecheap API to point to AWS Route53 nameservers. The CloudFront distribution CNAME (d1234.cloudfront.net) was added as an alias record at the zone apex, enabling both thequeensfleet.com and www.thequeensfleet.com to resolve to edge.

Testing and Validation

A regression test suite at /Users/cb/icloud-repos/sites/queenof-cities/tests/test_hub.py validates:

  • Hub page generates with all city tiles present
  • Router function correctly maps incoming hostnames to origin URLs
  • Cache headers are set (1 hour for hub, longer for immutable assets)
  • HTTPS redirect works for all domain variants

Tests run against both the local hub build and the live CloudFront distribution post-deployment.

Site Registry Integration

The hub was registered in site-registry.yaml under the "ventures" section with metadata:

ventures:
  - name: "The Queen's Fleet Hub"
    domain: thequeensfleet.com
    status: active
    launched: 2026-07-04
    infrastructure:
      cdn: cloudfront
      dist_id: E12G09B4XHLS8Y
      origin: s3://queenof-cities-hub

This registry serves as the source of truth for all hub and city metadata, used by build scripts and operational dashboards.

Key Decisions and Rationale

  • Static hub over dynamic SPA: No database queries or runtime dependencies. Hub scales to zero operational overhead and maximizes edge caching hit rates.
  • CloudFront function instead of app router: Request routing at the edge (not origin) eliminates cross-region latency and reduces costs by failing fast for mis-routed requests.
  • Single ACM cert for apex + www: Subject alternative name (SAN) avoids certificate proliferation and simplifies renewal.
  • S3 origin with OAI: Prevents direct S3 access, ensuring all traffic flows through CloudFront for monitoring, logging, and cache control.

What's Next

The hub infrastructure is now live and tested. The next phase centers on the avatar initiative: generating a photorealistic AI avatar ("Jada") that will serve as the face of The Queen's Fleet, personalize each city site's landing page, and drive influencer-style engagement campaigns. A detailed implementation plan has been drafted in /Users/cb/icloud-jada-ops/queens-fleet/AVATAR-PLAN-2026-07-04.md, covering model selection, CDN delivery, personalization endpoints, and social media integration. Avatar generation and integration work will begin once brand strategy is finalized.