Building a Granular Technical Blog Infrastructure Across Four Sailing & Marine Sites

```html

What Was Done

We implemented an automated technical blog generation system that captures detailed development session activity across four domain properties: queenofsandiego.com, sailjada.com, dangerouscentaur.com, and burialsatseasandiego.com. Each site now has its own technical blog subdomain (tech.queenofsandiego.com, tech.sailjada.com, etc.) that auto-publishes granular, engineering-focused posts documenting infrastructure changes, file modifications, and deployment activities.

This system was built to provide complete transparency into development work—Sergio and other stakeholders can drill down into exact file paths, AWS resource changes, DNS modifications, and infrastructure decisions rather than seeing high-level summaries.

Technical Architecture

Three Core Components

Blog Generator Script (/Users/cb/Documents/repos/tools/tech_blog_generator.py): Parses Claude Code session transcripts (JSONL format), extracts tool use entries, files modified/created, and commands executed, then generates structured HTML blog posts.
Infrastructure Init Script (/Users/cb/Documents/repos/tools/tech_blog_init.py): Provisions cloud resources for each blog—S3 buckets, CloudFront distributions, ACM certificates, and DNS records.
Stop Hook (/Users/cb/.claude/hooks/tech_blog_stop.sh): Executes automatically when a Claude Code session ends, triggering blog generation and deployment.

Infrastructure Details

S3 & CloudFront Deployment

For queenofsandiego.com and sailjada.com, we leveraged existing wildcard ACM certificates (*.queenofsandiego.com and *.sailjada.com) already provisioned in AWS Certificate Manager. This eliminated certificate management overhead.

Created four S3 buckets (one per blog):

qos-tech-blog (queenofsandiego.com)
jada-tech-blog (sailjada.com)
dc-sites (dangerouscentaur.com) — existing wildcard distribution E2Q4UU71SRNTMB
bats-tech-blog (burialsatseasandiego.com)

Each bucket is configured as a static website origin with CloudFront distributions in front. S3 buckets are private with public access blocked; CloudFront Origin Access Identity (OAI) handles all public traffic, enforcing HTTPS and caching.

DNS Strategy & Certificate Validation

queenofsandiego.com & sailjada.com: Both use Route53 hosted zones. The tech blog subdomains were created as CNAME records pointing to their respective CloudFront distribution domain names (e.g., tech.queenofsandiego.com CNAME d123.cloudfront.net).

dangerouscentaur.com: Uses Namecheap DNS. The wildcard distribution already existed on dc-sites bucket. We added a CNAME record at Namecheap: tech.dangerouscentaur.com CNAME d456.cloudfront.net.

burialsatseasandiego.com: Uses GoDaddy DNS. We provisioned a new ACM certificate for tech.burialsatseasandiego.com, then validated it by adding the DNS validation CNAME record directly in GoDaddy's DNS console via their API.

CloudFront Configuration

All distributions enforce HTTP → HTTPS redirect. Cache behavior TTL is set to 300 seconds (5 minutes) for index.html and 86400 seconds (1 day) for static assets, allowing rapid blog updates while caching performance for images and stylesheets.

Cache invalidation is automated: when the stop hook publishes a new post, it invalidates the CloudFront cache using the AWS CLI with path pattern /*, ensuring readers see fresh content within seconds.

Blog Generation & Post Format

Session Transcript Parsing

Claude Code sessions are exported as JSONL (JSON Lines) format. Each line represents a transcript entry with optional tool use blocks. The generator parses these to extract:

All files written/edited (path and action type)
All CLI commands executed (with placeholder redaction for sensitive values)
Tool function calls and their parameters
Timestamps and session metadata

The generator then constructs an HTML blog post with sections for:

What Was Done: A narrative summary of the session's purpose
Files Modified/Created: A detailed list with exact paths
Commands Executed: CLI invocations and their purpose
Infrastructure Changes: AWS resource operations, S3 uploads, CloudFront invalidations
Technical Decisions: Why certain approaches were chosen

Post metadata includes session start/end time, word count, and a permalink slug based on timestamp and domain.

Credential Redaction

The generator performs aggressive credential filtering:

Removes AWS access keys, secret keys, and session tokens from command output
Redacts API keys, API secrets, and authentication tokens
Filters database passwords and connection strings
Removes email addresses from email templates and personal data
Replaces actual AWS account IDs with [ACCOUNT_ID] placeholders

This ensures blog posts are safe to share without exposing operational credentials while maintaining complete technical transparency.

Navigation Integration

Updated the Ship's Papers dropdown menu on each site's main navigation to include a "Technical Blog" link pointing to the corresponding tech subdomain. This surfaces the blog to stakeholders directly from the primary site navigation.

Deployment Workflow

When a Claude Code session ends:

The stop hook script executes automatically
It downloads the session transcript from Claude's API
The blog generator parses the transcript and creates an HTML post
It determines the target domain (based on files modified in the session)
Uploads the post to the appropriate S3 bucket (e.g., qos-tech-blog)
Updates the blog's index.html with the new post link
Invalidates the CloudFront cache
Logs the operation (including timestamp, domain, post URL)

Key Decisions & Rationale

Why CloudFront in front of S3? CloudFront provides edge-cached delivery, HTTPS termination, and cache control without running any compute infrastructure. For a static blog, this is the most cost-effective and performant approach.

Why leverage existing wildcard certs? Both queenofsandiego.com and sailjada.com already had wildcard certificates. Reusing them saves time and avoids certificate management complexity.

Why granular file-level logging?