Behind the Scenes
This portfolio isn't on autopilot hosting. I package it, ship it, and run it myself on one small server — and it still loads fast anywhere in the world. Here is the whole system in one picture.
Almost every visit is answered at the edge, close to the visitor. My server is only touched when the edge doesn't already have the page.
No managed hosting. The site lives in a container on a small server I control from top to bottom — one predictable cost, nothing hidden behind a platform.
Self-hosted on a VPSWhen I push a change, an automated pipeline tests it, packages it, and deploys it. If anything fails the checks, it never reaches the live site.
Automated CI/CDPages are built ahead of time and served from servers close to each visitor, so the site stays quick even on a single-CPU machine.
Prebuilt + edge-cachedFor engineers
Every part of the build, with the real numbers and trade-offs behind it. Pick a topic.
Every layer is something I run and can reason about end to end — not a black box a platform hides from me.
React Server Components and route-level metadata, prerendered to static HTML at build time.
Full bilingual routing with correct hreflang alternates; setRequestLocale keeps every route static.
Utility-first classes over a small token layer that drives the dark theme and orange accent.
Used surgically — scroll reveals only where they help; pure-CSS fades everywhere else to keep JS off the route.
A standalone image built in CI and pushed to GitHub's container registry, versioned by commit SHA.
Typecheck, lint, build, push, and SSH deploy — a red pipeline never reaches production.
Cloudflare caches at the edge; nginx terminates TLS and reverse-proxies to the container on 127.0.0.1.
Metrics, logs, and alerting for this box and the client servers beside it — one self-hosted pane of glass.
The AI chat assistant runs on Groq; the contact form delivers server-side through Resend.
Everything is statically prerendered at build time — there is no per-request server rendering on the hot path.
The client i18n payload is stripped to 76 KB instead of shipping every blog post's text on every page.
Each blog page re-injects only its own post's content, so a page carries what it needs and nothing more.
ISR is reserved for the few places where data is genuinely live; static content stays static.
This architecture is not theoretical — it is the outcome of a real cost incident and the decision to own the platform end to end.
The site ran on Vercel and blew past its Fast Origin Transfer quota — 15.13 GB against a 10 GB limit — because every view was dynamically rendered and shipped a 1.6 MB payload.
Profiling by path, static rendering, payload stripping, and image recompression cut origin transfer by more than 90% — documented in full in the case study.
The site now runs on a small self-hosted VPS: Docker images built in CI, shipped through GHCR, deployed over SSH, and fronted by Cloudflare — one predictable monthly cost, no quota ceiling, full control of the runtime.
Senior work is mostly judgement under constraints. Each choice below was made against a measured cost on a 1 vCPU / 512 MB box, not a default.
WhyOn this 1 vCPU box, encoding a cover to AVIF measured 4–9 s versus ~0.6 s for WebP — a 7–16× penalty. Cloudflare does not yet cache /_next/image, so that encode is paid at the origin far more than once.
WebP-only. Covers stay light without ever stalling the single core. AVIF is re-enabled the day the edge caches optimised variants.
WhyThe animated footer needed one shader, not a general 3D engine. Pulling in three.js would have added well over 100 kB to a page that renders a single gradient effect.
The effect ships in roughly 4 kB of purpose-written WebGL — a ~25× saving over the library route.
WhyRoutes whose only motion was a fade were still pulling in the whole animation library. Opacity is GPU-composited — the browser does it identically for free.
Those routes ship 0 KB of animation JS and honour prefers-reduced-motion without any extra code.
Whynext-intl's getMessages without setRequestLocale forced dynamic SSR and embedded a 1.6 MB i18n payload — the full text of hundreds of posts — in every single response.
setRequestLocale plus per-page content injection cut the payload from 1,589 KB to 76 KB (−95%) and made every route prerenderable.
Whyoutput: standalone trims node_modules to only what server.js needs. But next/image's optimised-variant cache lived in the container's writable layer, so every deploy wiped it and the first request re-paid a full decode.
A named Docker volume persists optimised images across deploys, so a redeploy no longer costs a cold image cache.
WhyThis VPS also runs other services, and nearly every route is prerendered and read off disk while Cloudflare absorbs the repeat traffic. A large in-memory page cache would buy little and starve the neighbours.
The page cache is capped at 16 MB instead of the 50 MB default — enough to hold the hot pages, RAM left for the rest of the box.
Static assets ship with immutable, one-year Cache-Control headers, so repeat visits skip the network entirely.
ETags are left on, so revalidation returns 304 Not Modified instead of re-sending full bodies.
Security headers — CSP, HSTS, X-Frame-Options, nosniff — are set at the framework, not bolted on later.
Images are recompressed with sharp before they ever reach the repository, and critical CSS is inlined at build.
Running your own platform means owning its uptime. This box and the client servers beside it report into one self-hosted observability stack — the same setup described in my monitoring case study.
Prometheus scrapes node and container exporters; Loki collects logs; Grafana is the single pane of glass across every server.
Alert rules escalate through a chain that ends in a phone call, so incidents surface before users report them.
A Docker healthcheck probes the container every 30s, and uptime-kuma checks the public URL from the outside.
Short answers to what people ask most about how this site runs.
If I treat my own site this way, imagine your project.