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

  1. Publish content - write project pages, manage posts and links, upload images, and update manifests through the admin UI.
  2. Serve and persist - render public pages from static assets while CGI endpoints mirror content between local cache and S3.
  3. Deploy and verify - build a linux/amd64 image with Podman, push to ECR, update Lambda, and run validation plus smoke checks.

Technical highlights / stack

Frontend
HTML5 CSS3 Vanilla JS No build step
Backend
Shell CGI BusyBox httpd Cookie sessions
Storage
AWS S3 MinIO Local cache
Deployment
AWS Lambda Lambda Web Adapter CloudFront ECR Podman

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

Read-only Lambda Startup copies the image web root to /tmp/www so CGI writes can update manifests and generated files.
S3 cache A synchronous S3 sync runs before serving, then background refresh keeps local reads fast and simple.
Admin surface Login, draft save, publish, delete, upload, links, and analytics all go through small CGI scripts.
Release checks Static validation catches broken HTML and links, while live smoke checks cover CloudFront, Lambda, adapter, and routes.

Hard parts

  • Lambda's read-only filesystem required a writable /tmp/www runtime 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

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.