The Stack Behind This Site

A personal site is a small system, but the same rule governs it that governs an enterprise platform: every component you add is a component you must maintain, patch, and pay for. This site is the architecture I recommend when someone asks how to publish on the modern web without taking on an operations burden they will resent within a year. What follows is the full stack and the reasoning behind each layer.

The principle: static first, dynamic narrowly

Nearly everything a portfolio site does is known at build time. The pages, the articles, the project cards, and the structured data can all be produced once and served as files. Rendering them on every request adds servers to secure and bills to audit while producing an identical result for the reader.

So the foundation is a static site, and the dynamic surface is exactly one path: the contact form. That single decision drives most of what follows. The compliance surface shrinks, the cost approaches zero, and there is no database because nothing here requires one.

The build: Astro, Tailwind, MDX

Astro generates the site. It renders to plain HTML by default and ships JavaScript only where a page explicitly opts in. On this site, that amounts to a project filter and a theme toggle, and the total measures in kilobytes. Content lives in MDX and JSON collections validated by schema at build time, which means a project card with a missing field fails the build rather than reaching the reader.

Tailwind CSS handles styling against a small set of design tokens covering color, shadow, and type. The visual system is a few hundred lines of CSS on top of the utility classes, which keeps any future restyling inexpensive.

Pagefind indexes the built HTML and serves search from static files. There is no search service to run, no API key to protect, and no per-query cost to monitor.

The delivery: S3, CloudFront, ACM, Route 53

The built site lands in a private S3 bucket. Nothing in it is publicly readable. CloudFront fetches objects through Origin Access Control, so the CDN is the only door into the origin, and a CloudFront function rewrites clean URLs to their underlying index.html objects. ACM issues the TLS certificate, and Route 53 aliases cyberd.tech to the distribution.

This is a deliberately conventional pattern, and that is its virtue. It provides global caching, TLS by default, and an origin that cannot be scraped directly, using services mature enough that their failure modes are documented and their costs are predictable. At personal-site traffic, the monthly bill is a few dollars.

The dynamic layer: one Lambda, deliberately

The contact form posts to API Gateway, backed by a single Lambda function. The function validates the submission, checks a Cloudflare Turnstile token to reject automated submissions before a human ever sees them, and forwards the message through SES. No submission is stored. The function is a relay rather than a database, and this is a deliberate privacy decision: data that is never retained is data that cannot leak, and a contact form has no reason to retain anything.

The infrastructure: CDK, so the whole thing is code

Every resource named above, from the bucket to the DNS records to the function, is defined in an AWS CDK stack that lives in the same repository as the content. A deploy is a push to the main branch: GitHub Actions builds the site, synthesizes the stack, and ships both together. The infrastructure can be reviewed in a pull request and rebuilt from a clean checkout.

I hold client systems to this same standard, and the reasoning is identical at both scales. A system you cannot rebuild from source is a system you do not fully own, because the knowledge of how it works lives somewhere other than the code.

The AI-native layer: two surfaces, one source

This is the part most sites skip. This site publishes for two kinds of readers. Humans receive the HTML. Agents receive a parallel surface generated from the same content at the same build: llms.txt and llms-full.txt indexes, a Markdown report for every page (for example, /projects/moxa.md), and JSON-LD structured data describing the person, the projects, and the writing.

None of this costs anything at runtime, because it is all static output. What it changes is legibility. An AI system researching me on someone’s behalf receives curated, canonical context instead of whatever it can extract from a navigation bar. As more buying research is delegated to agents, that difference will separate the sites that get found from the sites that get understood.

What it costs to run

• Compute: a pay-per-request Lambda that spends most of its life idle, billed accordingly.
• Storage and delivery: S3 and CloudFront at personal-site traffic, a few dollars per month.
• Maintenance: dependency updates. There is no server to patch and no database to back up.

The takeaway

No single piece of this stack is exotic, and that is the point. Each component is conventional, well documented, and chosen because its failure modes are known, then composed so that the whole system runs without attention. That is the standard I hold enterprise systems to, applied at the smallest scale I operate.

If you are building a site like this one, the pattern transfers directly: static first, one narrow dynamic path, infrastructure as code, and a machine-readable surface published beside the human one.