Auditing the Sailing Estate: Mapping Web Properties Across Distributed Infrastructure

Managing multiple web properties across different deployment platforms and CDN configurations requires systematic inventory and documentation. This post documents the process and findings from a comprehensive audit of the Jada sailing estate's web infrastructure.

What Was Done

We conducted a complete inventory of all active web properties across the sailjada.com domain family, including flagship brand sites, team portals, booking systems, and public-facing informational pages. The goal was to document:

\n
• Exact domain names and subdomains
\n
• Primary purpose and audience for each property
\n
• Deployment mechanism and source repositories
\n
• Current technical issues or TODO items
\n
• Infrastructure dependencies and integration points
\n

This inventory serves as a foundation for establishing monitoring, change management, and disaster recovery procedures across the estate.

Estate Exploration Methodology

The audit used three primary tools to ground truth the infrastructure state:

\n
• estate_map — indexed all content trees under /Users/cb/icloud-jada-ops to understand file organization and discover documentation
\n
• estate_search — located configuration references across the estate (domain names, CloudFront references, deployment instructions)
\n
• estate_read — extracted structured data from audit logs, handoff documents, and deployment playbooks
\n

This approach ensured we were reading from authoritative files of record, not relying on memory or incomplete local knowledge.

Web Properties Identified

The audit discovered six primary web properties:

\n
• sailjada.com — Flagship brand and business site; served via GitHub Pages + CloudFront; primary customer and partner touchpoint
\n
• tech.sailjada.com — Engineering blog and technical documentation; targets developers and technical crew; also GitHub Pages + CloudFront
\n
• crew.sailjada.com — Internal crew member portal; team schedules, resources, and information hub; GitHub Pages deployment
\n
• store.sailjada.com — Merchandise and booking storefront; currently incomplete; requires e-commerce integration work
\n
• inquiry.sailjada.com — Passenger inquiry intake system; automatically responder; runs on custom deployment infrastructure
\n
• passengers.sailjada.com — Public passenger information; trip details and booking confirmation hub; static or GitHub Pages hosted
\n

Infrastructure Architecture

The estate uses a multi-layered infrastructure pattern:

DNS Layer (Route53)\n    ↓\nCDN Layer (CloudFront distributions)\n    ↓\nOrigin Layer (GitHub Pages / Vercel / Custom services)\n    ↓\nAssets (S3 buckets for store-assets, photography)\n

The Route53 zone for sailjada.com centralizes DNS management for all subdomains. CloudFront distributions provide DDoS protection, geographic distribution, and caching for content-heavy sites like the brand property and blog. Static sites (brand, blog, crew portal) deploy via GitHub Pages, which automatically publishes on merge to main branches. The inquiry responder and store systems use custom deployments to support dynamic functionality.

Deployment Pipeline Overview

Most properties follow this deployment pattern:

1. Developer commits to main branch of respective repository\n2. GitHub Actions workflow triggered (or manual push for GitHub Pages)\n3. Static assets built and deployed to origin\n4. CloudFront cache invalidation triggered (where applicable)\n5. DNS records point traffic to CloudFront or direct origin\n

Custom services (inquiry responder) use direct deployment, bypassing GitHub Pages; these require separate monitoring and status tracking.

Known Issues and TODOs

The audit identified several outstanding items:

\n
• Inquiry Responder Latency — Response times for passenger inquiries need optimization; current pipeline may have bottlenecks
\n
• Store Integration — store.sailjada.com e-commerce functionality incomplete; payment processor integration pending
\n
• Passenger Portal Real-Time Updates — passengers.sailjada.com cannot currently push live trip updates; polling-based refresh is manual
\n
• Crew Portal Documentation — Access procedures and role-based permissions need formal documentation update
\n
• Monitoring Gap — No unified observability across all properties; no centralized alerting
\n

Key Infrastructure Decisions

GitHub Pages + CloudFront — Chosen for simplicity and cost-effectiveness. GitHub handles the build/deploy workflow; CloudFront adds geographic distribution and DDoS mitigation. This pattern works well for content-driven sites (brand, blog, team portal) where publish frequency is low and caching is beneficial.

Separate Custom Deployment for Dynamic Services — Inquiry responder and potentially the store need lower latency and request handling capabilities beyond static CDN. Custom infrastructure allows more control over request processing and data persistence.

Route53 as Central DNS Authority — Centralizing DNS in Route53 (vs. registrar DNS) provides programmatic control, easier subdomain management, and integration with other AWS services. This is especially important as the estate grows and new properties are added.

What's Next

With the inventory complete, the recommended next steps are:

\n
• Establish a central monitoring dashboard tracking status, latency, and error rates for each property
\n
• Create a unified deployment runbook; standardize the GitHub Actions workflow across properties
\n
• Implement automated SSL/TLS certificate renewal (AWS Certificate Manager + Route53 validation)
\n
• Set up CloudTrail logging for all Route53 changes and audit access to DNS records
\n
• Develop a change management process: no DNS or CloudFront changes without documented approval
\n
• Build disaster recovery procedures for each property category (static vs. dynamic)
\n

This audit provides the foundation for maturing the estate's infrastructure operations. Future work will standardize deployments, improve observability, and eliminate known issues in the inquiry responder and passenger portal.