Overview

This is the site you're looking at right now. It's a Next.js portfolio and blog deployed to AWS using SST v4, with Cloudflare managing DNS records and CloudFront handling SSL via ACM. The whole thing is infrastructure-as-code, supports staging environments, and deploys in about two minutes. I built it because I wanted a place to write about the things I'm building and a portfolio that reflects how I actually work. That meant deploying it the same way I'd deploy a client project, not just pushing to a hosting platform and calling it done.

Architecture

The deployment stack is straightforward but production-ready:

• SST v4 manages the infrastructure as TypeScript code
• AWS hosts everything: Lambda for server-side rendering, S3 for static assets, CloudFront as the CDN
• Cloudflare manages DNS records (proxy disabled; SSL terminates at CloudFront via ACM)
• SST Secrets manage the GitHub token and analytics ID
• AWS SSM Parameter Store holds the Cloudflare provider credentials that the deployment wrapper passes to SST

That's the core of it. SST handles the Lambda function packaging, S3 bucket creation, CloudFront distribution, and Cloudflare DNS record management. A named non-production deployment gets the generated AWS URL, while production gets the real domain. During sst dev, Next.js runs locally and connects to the stage's linked resources.

Content System

The site uses an MDX-based content system built on the Magic Portfolio template with Once UI components:

• Blog posts are .mdx files in src/app/blog/posts/
• Project pages are .mdx files in src/app/work/projects/
• All personal info, work history, and skills live in a single content.tsx config file

MDX gives me full React component access inside markdown, so I can drop in code blocks, styled callouts, and interactive elements without leaving the content files.

What Made This Worth Building Properly

I could have deployed this to Vercel in five minutes. But there are a few reasons I went the SST + AWS route: Practice what I preach. I build AWS infrastructure for clients every day. My own portfolio should reflect that. Using SST v4 for a relatively simple site gave me hands-on time with the framework's Next.js integration and Cloudflare provider before recommending it to anyone else. Isolated stages. sst dev runs the Next.js process locally while deploying the supporting resources needed for that stage. When I need a shareable preview, sst deploy --stage staging creates a separate deployment without touching production. Each stage incurs the normal cost of the AWS resources it creates. AWS-native deployment target. The site runs on Lambda, S3, and CloudFront instead of a proprietary application runtime. Replacing SST would still require rebuilding the infrastructure definition, but it would not require moving the application away from AWS-specific hosting primitives. Separate application and deployment credentials. The GitHub token and analytics ID are SST Secrets. Cloudflare provider credentials stay in encrypted SSM parameters and are exposed only to the deployment process. None of those values are committed to the repository. I wrote a longer field report on the framework in What SST v4 Gets Right for Full-Stack AWS Applications, including the sst dev model, stage behavior, state, secrets, and the upgrade trade-offs.

Tech Stack

• Next.js 16 (App Router) for the frontend
• React 19 for the component layer
• Once UI component library and design system
• MDX for blog posts and project pages
• SST v4 for infrastructure-as-code deployment
• AWS (Lambda, S3, CloudFront) for hosting
• Cloudflare for DNS management
• Google Analytics via @next/third-parties for lightweight traffic visibility
• GitHub for source control