PersonalSite
This site: portfolio, blog, links, admin tools, and deployment pipeline without a frontend framework.
PersonalSite is the operating surface for tebay.dev: static project pages, dynamic blog and links content, shell CGI admin workflows, S3-backed storage, analytics, and Lambda container deployment.
What it solves
I wanted a portfolio and CMS that stayed small, understandable, self-hosted, and deployable without a frontend build chain or heavyweight application server.
The result is a plain HTML/CSS/JS site with shared layout scripts, CGI admin endpoints, S3-backed content, local MinIO development, CloudFront delivery, and repeatable Lambda container deployment.
Who this is for
- People reviewing how this portfolio is built and operated
- Developers interested in framework-free web systems
- Builders comparing static pages with small dynamic admin tools
- Anyone evaluating my deployment, verification, and AI-assisted process
What it does
PersonalSite started as a constraint-driven portfolio rebuild: no frontend framework, no Node runtime, no build step, and no heavy CMS. It now powers project documentation, a blog, curated links, an admin panel, deployment scripts, smoke checks, and a small analytics pipeline.
Production runs as an AWS Lambda container behind CloudFront.
BusyBox httpd serves from /tmp/www,
the Lambda Web Adapter bridges Lambda events to HTTP, and S3
stores blog posts, images, links, and analytics data. On cold
start, the container syncs S3 content into a local cache before
serving requests.
Workflow covered
- Publish content - write project pages, manage posts and links, upload images, and update manifests through the admin UI.
- Serve and persist - render public pages from static assets while CGI endpoints mirror content between local cache and S3.
- Deploy and verify - build a linux/amd64 image with Podman, push to ECR, update Lambda, and run validation plus smoke checks.
Technical highlights / stack
Why it matters
This project shows how I prefer to build: choose constraints, keep the runtime visible, automate the risky parts, and verify behavior in the same environment that serves users.
Technical notes
/tmp/www
so CGI writes can update manifests and generated files.
Hard parts
-
Lambda's read-only filesystem required a writable
/tmp/wwwruntime copy. - Lambda containers required the Web Adapter, correct port setup, and cold-start timing.
- AWS CLI was more reliable than smaller S3 clients with Lambda temporary credentials.
- Shell-based JSON and manifest handling needed locks, cleanup, and validation.
- Cold-start failures can look like generic website failures without smoke checks.
Engineering takeaways
- Lambda plus CGI is viable for a low-traffic site when persistence is pushed to S3.
- Cold-start behavior deserves first-class validation, not only steady-state checks.
- MinIO-backed local development is worth it because storage code stays realistic.
- AI assistance is useful when constraints are explicit and runtime feedback is trusted.
Current scope
Public site
- Project pages
- Blog rendering
- Links page
- Theme swatches
- Responsive navigation
Admin
- Login/logout
- Draft and publish flow
- Image upload/list/delete
- Link management
- Analytics review
Operations
- Podman image build
- ECR push
- Lambda update
- Static validation
- Production smoke checks
Related work
What to do next
Read the source if you want to inspect the no-build frontend, shell CGI admin workflows, S3 cache behavior, Lambda deployment, and validation scripts behind tebay.dev.