MAY'D IT
The portfolio itself: a two-origin static architecture with reproducible builds, supply-chain controls, a command interface, and an intentionally isolated browser arcade.
Problem
A technical portfolio should demonstrate engineering judgment without requiring a CMS, public admin panel, database, long-lived application host, or a dependency-heavy runtime merely to present static information.
Constraints
- Keep the public portfolio static and independent from homelab availability.
- Isolate experimental arcade code on a separate origin with no trusted backend relationship to the main site.
- Build from a locked dependency graph with lifecycle scripts disabled and deployment credentials isolated from application dependencies.
- Keep project content data-driven so new case studies can be added without creating a new page implementation each time.
Architecture
- 01
Astro builds the portfolio and arcade into independent static artifacts deployed to separate Cloudflare Workers Static Assets origins.
- 02
A latest → stable promotion model gates production while GitHub Actions runs build, signature, vulnerability, SBOM, and artifact-integrity checks.
- 03
The project registry feeds reusable cards and one dynamic static route for every case study.
- 04
The command interface and arcade add interaction entirely in the browser without creating accounts, APIs, databases, or server-side state.
Failures / lessons
- A portfolio can demonstrate architecture through its own constraints instead of only describing other systems.
- Separating build and deployment credentials reduces what compromised dependencies can reach.
- Static-first does not mean interaction-free; it means adding runtime machinery only where it earns its existence.