Skip to content

ci: serve the dplaax.dev wire surface from S3 + CloudFront - #4

Merged
y1o1 merged 2 commits into
mainfrom
feat/wire-cloudfront-deploy
Jul 24, 2026
Merged

ci: serve the dplaax.dev wire surface from S3 + CloudFront#4
y1o1 merged 2 commits into
mainfrom
feat/wire-cloudfront-deploy

Conversation

@y1o1

@y1o1 y1o1 commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

Why

The frozen wire URI /vc/v1 is extensionless. GitHub Pages derives Content-Type from the file extension alone and offers no header override, so the context was served as application/octet-stream. S3 object metadata serves it as application/ld+json — that single constraint moves the apex wire surface off Pages.

What

  • .github/workflows/deploy.yml — assembles the served tree from the canonical sources (contexts/v1.jsonld/vc/v1, schemas/*.json/schemas/*, site/), guards the signing-scope sha256 pin (9716bca…), refuses to sync --delete any bucket not named wire.*, excludes the extensionless identifier keys from the bulk sync (single-write upload with the correct media type — no transient octet-stream window), and invalidates CloudFront. Ships disabled (if: false) until the OIDC role + repo secrets are wired.
  • infra/deploy.md — target topology (Route 53 → CloudFront (OAC) → private wire.dplaax.dev bucket, versioning on), the served-object/media-type table, the Pages→S3 migration order, and a fail-fast, pin-guarded manual fallback.
  • pages.yml retired + site/README.md updated — the cutover already happened and was verified against production: apex A/AAAA now alias the wire distribution, and https://dplaax.dev/vc/v1 returns 200 + application/ld+json, byte-exact under the pin; all 16 schemas byte-exact; grant-type page and root/404 behavior intact; www.dplaax.dev (LP) unaffected. The last Pages deployment stays untouched as the DNS rollback target.

Verification (production, 2026-07-24)

curl -sI https://dplaax.dev/vc/v1          # HTTP/2 200, content-type: application/ld+json
curl -s  https://dplaax.dev/vc/v1 | shasum -a 256
#   9716bca789bdb1042451746800cc463a616a57817008001a3a895e88c0aff25f (= pin)
# schemas 16/16 byte-exact vs schemas/*.json; /oauth/grant-type/did 200; bogus path → 404

Reviewed by multi-agent review (Claude + Codex ×2 rounds); all actionable findings addressed in-branch.

🤖 Generated with Claude Code

y1o1 and others added 2 commits July 24, 2026 17:09
GitHub Pages derives Content-Type from the file extension only and cannot
override response headers, so the frozen extensionless wire URI /vc/v1 was
served as application/octet-stream. Move the apex wire surface (/vc/v1,
/schemas/*, /oauth/grant-type/did) to a dedicated S3 bucket behind
CloudFront, where object metadata sets application/ld+json.

The served tree is assembled from the same single sources as the Pages
workflow (contexts/v1.jsonld, schemas/*.json, site/) and guarded by the
existing sha256 pin. Ships disabled (if: false) until the bucket and
distribution exist; pages.yml is retired after the DNS cutover is verified.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The apex A/AAAA records moved from the Pages IPs to the wire distribution
(E3OEG9PWPHUC8W / wire.dplaax.dev bucket) and the full §5 battery passed
against production: /vc/v1 byte-exact under the signing-scope pin AND
Content-Type: application/ld+json — the header Pages could not set — plus
all 16 schemas byte-exact, the grant-type page, and root/404. The last
Pages deployment stays up untouched as the DNS rollback target; only the
workflow that would redeploy it is removed. site/README.md now documents
the S3 publishing path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@y1o1
y1o1 merged commit 2cd9040 into main Jul 24, 2026
1 check passed
@y1o1
y1o1 deleted the feat/wire-cloudfront-deploy branch July 24, 2026 15:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant