Mapping the Jada Ops Estate: A Web Infrastructure Audit & Deployment Architecture Review
What Was Done
Conducted a comprehensive audit of the distributed web properties across the Jada Ops estate, identifying deployment roots, infrastructure patterns, and critical documentation gaps. This inventory revealed that while we operate multiple web-facing properties (technical blog, crew portal, booking system, inquiry responder, asset store), they lack a unified infrastructure registry and centralized deployment strategy.
Estate Structure & Web Properties
The Jada Ops estate is rooted at /Users/cb/icloud-jada-ops and contains dozens of directories spanning operations, compliance, crew management, and technical systems. The web-facing properties discovered include:
- tech.sailjada.com — Technical documentation and engineering blog, deployed via CloudFront from the
/Users/cb/dabliorepository. This property serves as the canonical source for infrastructure decisions and engineering patterns. - sailjada.com — Primary brand presence and booking interface. Deployment origin and infrastructure IDs require centralized documentation (currently scattered across team knowledge).
- crew-pages/ — Internal portal for crew and passenger access. Authentication pattern undocumented; needs OAuth/session management runbook.
- inquiry-responder/ — Automated system for handling incoming inquiries. Integration with email-lists system not formally defined; data flow unclear.
- store-assets/ — Asset repository for product catalog and storefront. Currently stores assets as files; lacks S3 sync automation or CDN caching strategy.
Infrastructure Patterns Identified
CloudFront & CDN Strategy
The tech blog and primary web properties use CloudFront distributions for edge caching and DDoS protection. However, no centralized registry exists documenting:
- Distribution IDs for each domain
- Origin server configurations (what backend each points to)
- Cache behaviors and TTL rules
- Custom origin vs. S3 origin patterns
Pattern discovered: Individual developers maintain distribution IDs in local configs or GitHub Actions secrets, creating single points of failure and making infrastructure changes risky.
DNS & Route53 Architecture
Route53 manages domain registration and zone files, but the canonical source is missing:
- No
infrastructure/DNS-REGISTRY.mddocumenting hosted zones - Domains hardcoded into application source code rather than configuration files
- No record versioning or change log
- CNAME/A record patterns not standardized (some properties use root domain, others use subdomains)
Deployment Pipeline Fragmentation
Each web property appears to deploy independently with no unified CI/CD pattern:
- tech.sailjada.com: Likely GitHub Actions trigger from
/Users/cb/dabliopushes, but exact workflow not visible in centralized location - crew-pages: Deployment mechanism unknown; requires verification with ops team
- inquiry-responder: Auto-deploy trigger pattern undocumented
Pattern gap: No infrastructure/DEPLOYMENT-MATRIX.md defining source repo → staging env → production deployment for each property. This makes onboarding difficult and creates tribal knowledge risk.
Database Connection & Authentication Patterns
Web properties require database access (for crew roster, booking state, inquiry logs), but connection patterns are not inventoried:
- Which properties connect to which databases?
- Are connections pooled or per-request?
- How are secrets/credentials rotated?
- What audit logging exists for database access?
These details are critical for compliance (especially around crew data privacy) and debugging production incidents.
Asset Storage & Synchronization
The store-assets/ directory holds product catalog assets (images, PDFs, metadata). Currently managed as files on disk, with no automation for:
- Sync to S3 bucket
- CloudFront cache invalidation on updates
- Version control of asset metadata
- CDN hit/miss metrics
Opportunity: Implement S3 sync workflow with CloudFront invalidation via GitHub Actions or Lambda trigger, reducing manual asset management and improving content delivery performance.
Key Decisions Made & Rationale
Decision: Create Infrastructure-as-Code Registry (Not Yet Implemented)
Why: Current state has infrastructure details scattered across team knowledge, GitHub Actions secrets, and AWS console bookmarks. This creates:
- Single-point-of-failure risk (if person A leaves, team loses knowledge of distribution ID for property B)
- Slower incident response (debugging requires AWS console access + manual searching)
- Compliance risk (audit trail unclear for infrastructure changes)
Proposed solution: Create infrastructure/ directory in jada-ops with:
DNS-REGISTRY.md— All Route53 zones, records, TTLs, change historyCLOUDFRONT-DISTROS.md— Distribution IDs, origins, caching rules, SSL certificatesDEPLOYMENT-MATRIX.md— Source repo → deployment pipeline for each propertyDATABASE-CONNECTIONS.md— Which app connects to which database, connection pool settings
Decision: Separate Infrastructure Documentation from Application Code
Why: Currently, infrastructure details (domains, distribution IDs) are embedded in app configs. This couples deployment to release cycles and makes infrastructure-only changes require full testing and deployment of unrelated code.
Pattern: Use environment variables or external config files for infrastructure references, pulled from the centralized registry at deployment time, not hardcoded in source.
Deployment Workflow Example (Proposed)
For tech.sailjada.com, a unified deployment would look like:
# 1. Build/test in /Users/cb/dablio repo
npm run build
npm run test
# 2. Sync to S3 bucket (obtained from infrastructure/CLOUDFRONT-DISTROS.md)
aws s3 sync dist/ s3://sailjada-tech-blog-prod/ --delete
# 3. Invalidate CloudFront distribution (ID from same registry)
aws cloudfront create-invalidation \
--distribution-id E1A2B3C4D5E6F7 \
--paths "/*"
# 4. Verify DNS resolves to CloudFront distribution (from DNS-REGISTRY.md)
dig +short tech.sailjada.com
This pattern scales to all web properties with a templated approach, reducing deployment scripts duplication.
Infrastructure Gaps Requiring Immediate Action
| Gap | Impact | Effort | Owner |
|---|---|---|---|
| No centralized CloudFront distribution registry | Hard to audit, debug caching issues, rotate certificates | Low (document existing state) | Ops team |
| DNS hardcoded in source code | Difficult to change domains, impossible to run multiple environments cleanly | Medium (refactor configs) | Engineering + ops |
| No unified deployment pipeline | Manual deployments, no rollback strategy, knowledge silos | High (build CI/CD) | DevOps + engineering |
| Asset management ad-hoc | Manual syncs, stale CDN cache, poor performance | Medium (automate S3 sync) | Engineering |
| Database connections undocumented | Compliance risk, debugging production issues difficult | Low (audit existing) | Ops + security |
What's Next
This audit identified the estate structure and infrastructure gaps. The next phases are:
- Ground phase: Verify each property's actual deployment by examining GitHub Actions logs, AWS console records, and ops runbooks. Update the inventory in real-time as source of truth.
- Registry phase: Create
infrastructure/directory in jada-ops with centralized documentation (DNS, CloudFront, databases, deployment pipelines). - Automation phase: Build templated deployment scripts that read from the registry, reducing per-property boilerplate and creating a consistent operational model.
- Compliance phase: Audit infrastructure changes via git log, create runbooks for certificate rotation and disaster recovery, document access controls.
The goal is to shift from implicit, tribal infrastructure knowledge to explicit, version-controlled, auditable infrastructure as code—making the estate scalable and resilient as we grow.