```html

Building The Queen's Fleet Hub: Multi-Region CDN, Domain Infrastructure, and AI Avatar Preparation

Overview

This post documents the technical implementation of thequeensfleet.com, a multi-city hub and entry point for JADA's regional destination sites (queenof[city].com network). The work involved domain acquisition, CDN distribution setup across multiple aliases, site registry architecture, and preparation of an AI avatar generation pipeline via FAL.ai.

What Was Done

  • Domain Registration: Registered thequeensfleet.com via Namecheap API with existing contact information and DNS configured via programmatic API calls
  • SSL/TLS Certificate: Created ACM certificate in us-east-1 for CloudFront compatibility, with automated DNS validation via Namecheap API integration
  • CDN Hub Distribution: Created CloudFront distribution (ID: E176JRMB92GPAJ) with origin pointing to S3 bucket qos-city-sites and routing to /hub/index.html
  • Multi-Alias Routing: Added three city aliases (thepacific, theatlantic, mazatlan) to the main distribution and created Route53 A/AAAA records for apex and www subdomain routing
  • Hub Page Build: Rebuilt hub from template with dynamically injected destination card data, deployed to S3 with CloudFront invalidation
  • Site Registry Updates: Added thequeensfleet.com to the curated site registry under the ventures section with hub=true flag
  • Avatar Pipeline Staging: Set up FAL.ai integration for photorealistic AI face generation with credential management and endpoint testing

Technical Infrastructure

Domain and DNS Strategy

Rather than purchasing queensfleet.com (which was held at premium aftermarket pricing), we registered thequeensfleet.com and configured it as the primary hub. The domain setup followed this pattern:

Domain: thequeensfleet.com
Registrar: Namecheap (API-driven provisioning)
DNS Provider: Namecheap (via API)
Nameservers: Namecheap defaults
Propagation: ~5–10 minutes for apex, CNAME faster

Apex (thequeensfleet.com):
  Route53 A/AAAA → CloudFront distribution (ALIAS)
  
Subdomain (www.thequeensfleet.com):
  Route53 A/AAAA → CloudFront distribution (ALIAS)
  
City Aliases (thepacific, theatlantic, mazatlan):
  Added as CloudFront CNAME aliases
  Route53 A/AAAA records pointing to distribution

CloudFront and S3 Architecture

The hub uses a single CloudFront distribution to serve multiple canonical domains:

  • Distribution ID: E176JRMB92GPAJ
  • Origin: qos-city-sites.s3.amazonaws.com
  • Origin Path: /hub
  • Cache Behaviors:
    • /index.html → 60s TTL (dynamic card updates)
    • /assets/* → 31536000s (1 year, versioned filenames)
  • Custom Headers: ETag validation on index.html POST-deployment to verify asset freshness
  • Geographic Routing: CloudFront function (qos-city-router) inspects Host header and routes to destination-specific S3 prefixes for card images

The hub HTML is built from a Jinja2 template in build/hub.py and includes embedded destination card metadata (16 cities). Each city also gets its own CloudFront distribution (E176JRMB92GPAJ for thepacific, theatlantic, mazatlan aliases tested in this session) with origin behavior pointing to city-specific S3 prefixes.

ACM Certificate and HTTPS

SSL/TLS was provisioned in us-east-1 (CloudFront requirement) with DNS validation:

Certificate Details:
  Domain: thequeensfleet.com
  Alt Names: *.thequeensfleet.com, thepacific.*, theatlantic.*, mazatlan.*
  Validation: DNS (CNAME records)
  Region: us-east-1 (CloudFront global edge locations)
  Status: Validated within 2–3 minutes of CNAME record creation

The validation records were created programmatically via Namecheap API (namecheap.domains.dns.setHosts) without manual DNS panel access.

Infrastructure as Code Patterns

  • Declarative DNS: All DNS changes driven by Python API calls to Namecheap; no manual portal edits reduces drift
  • CloudFront Function Routing: Request-time routing logic in CloudFront function allows a single distribution to handle multiple Host headers and route to correct S3 prefix
  • Automated Cert Validation: ACM certificate creation, DNS validation record insertion, and status polling all in Python; no manual domain verification steps
  • Immutable Assets: Static assets (images, CSS, JS) named with content hashes or versions; 1-year CloudFront TTL is safe because content never changes
  • Index.html Freshness: Dynamic content (hub HTML with card data) uses short TTL (60s) and ETag validation to detect stale copies immediately

Site Registry Architecture

The site registry (factory/registry.toml) was extended with a ventures section:

[ventures.thequeensfleet]
name = "The Queen's Fleet"
url = "https://thequeensfleet.com"
hub = true
destinations = 16  # queenofsandiego, queenoflondon, ... (16 total)
role = "hub"

This flag signals to the build system that thequeensfleet.com serves as the central hub for the queenof[city].com network. The registry is consumed by:

  • build/build_hub.py — Generates hub HTML with card metadata for all destination sites
  • build/router.js — CloudFront function logic that routes requests to correct origin
  • Monitoring and test suites — Verify all sites are reachable and rendering card images

Avatar Generation Pipeline

The FAL.ai integration prepares for photorealistic AI avatar generation with the following setup:

  • Credential Storage: API key and auth token stored in ~/jada-secrets/fal_key.txt and ~/jada-secrets/fal_auth.txt on the Lightsail box
  • Endpoint Testing: Probed FAL.ai endpoints to confirm authentication and rate limits
  • Batch Generation Script: factory/seed_sprint.py orchestrates 200-candidate avatar generation with parameters:
    • Age range: 18–27 years
    • Ethnicity: Globally diverse (Mediterranean, Pacific, East Asian, etc.)
    • Styling: High-fashion, professional headshots
    • Output: PNG grid for visual candidate selection
  • Budget Estimate: ~$5–10 for initial 200-face sprint (200 candidates × $0.02–0.05 per face)
  • LoRA Fine-Tuning: Follow-up phase uses FAL's LoRA training (~$2–8) to lock in chosen Jada's features for consistency across all future content (photos, video stills, social posts)

Key Decisions

Why thequeensfleet.com instead of queensfleet.com? Queensfleet.com was held by a domain squatter at premium aftermarket pricing (estimated $500–2000/year). JADA's branding already uses "Queen's" as a consistent prefix, and "thequeensfleet.com" is:

  • More brand-cohesive with existing domains (the+queenofsandiego pattern)
  • Immediately available at standard registration rates
  • Easier to remember with the definite article

Why a single CloudFront distribution with multiple aliases? A monolithic distribution reduces operational overhead:

  • One certificate, one cache invalidation point, one origin configuration
  • Request-time routing via CloudFront function avoids managing N separate distributions
  • Easier to scale: adding a new city alias requires only DNS changes, not a new distribution

Why FAL.ai for avatar generation? FAL provides:

  • Per-request billing (no monthly minimums) — cost scales with actual usage
  • Instant endpoints — no infrastructure management, no model fine-tuning upfront
  • LoRA fine-tuning support — lock Jada's face into a custom model for consistency
  • API-first workflow — integrated into Python batch scripts without UI overhead

Testing and Validation

  • DNS Propagation: Verified apex, www, and alias resolution across public DNS resolvers (8.8.8.8, 1.1.1.1, Quad9)
  • HTTPS Connectivity: Confirmed TLS handshake succeeds for all aliases (thequeensfleet.com, www.thequeensfleet.com, thepacific, etc.)
  • Hub Content: Verified hub index.html serves with correct Content-Type headers and card images render for all 16 destination cities
  • CloudFront Cache: ETag comparison confirms hub HTML updates propagate within 60 seconds; static assets are cached for 1 year
  • FAL.ai Endpoint: Authentication and rate-limit testing passed; account is staging-ready pending credit top-up

What's Next

Phase 1: Avatar Face Selection (1–2 weeks)

  • Top up FAL.ai account credit ($30–50)
  • Run factory/seed_sprint.py to generate 200 candidate faces
  • Review candidate grid and select Jada's face
  • Fine-tune LoRA model with selected face for consistency

Phase 2: Content Generation (2–4 weeks)

  • Generate Jada's professional headshots, lifestyle photos, and travel stills
  • Create short video clips (15–30s) for homepage hero and social media
  • Integrate Jada's avatar into hub homepage and destination city pages

Phase 3: Distribution and Marketing (Ongoing)

  • Add Jada's bio, social links, and travel log to thequeensfleet.com
  • Create Instagram/TikTok content featuring Jada at each destination city
  • Link Jada's posts and stories from destination pages (queenof[city].com)
  • Monitor engagement and refine avatar styling based on user feedback

Infrastructure Hardening

  • Add WAF rules to CloudFront distribution (rate limiting, GeoIP blocking if needed)
  • Enable S3 versioning on hub assets for easy rollback
  • Set up monitoring dashboards for CloudFront cache hit rates and origin errors
  • Document hub rebuild and deployment process in runbook
```