Colophon

Tech stack

Architecture decisions

• →One-page landing with distinct sections for skills, experience, services, projects, and contact — anchor-based navigation.
• →Client-side track toggle (cookie `track`): a single hero component, skills and services adapt to Salesforce or IT Ops profile.
• →Dedicated pages for About, Certifications, and Blog — accessible via the navbar, not duplicated in the landing.
• →Server Components by default: only interactive components (hero, theme toggle, contact form) are marked `use client`.
• →Supabase data fetched server-side with Redis cache (stale-while-revalidate) — no direct client queries.
• →MDX Blog: articles written as `.mdx` files in `content/blog/posts/{locale}/` — statically rendered at build time, no database required.

Caching strategy

• →Upstash Redis stores Supabase query responses (projects, certifications, about) with a 5-minute TTL.
• →stale-while-revalidate: if data is cached, it's returned immediately while an async revalidation runs in the background.
• →Manual invalidation: the `POST /api/cache/invalidate` endpoint (protected by secret) allows purging cache after data updates.
• →RSS feed: `Cache-Control: public, max-age=3600, stale-while-revalidate=86400` — 1h CDN cache, revalidated every 24h.
• →ISR (HTML pages): disabled on Vercel CDN by security design — the per-request CSP nonce (eliminating `'unsafe-inline'`) is incompatible with cached HTML. Caching is planned via a homelab reverse proxy (Q4 2026), which will cache HTML at its own layer without compromising the nonce.

Security

• →HTTP headers in `next.config.mjs`: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy (`same-origin`), Cross-Origin-Resource-Policy (`same-origin`). Framework fingerprinting suppressed via `poweredByHeader: false`.
• →Row Level Security (RLS) enabled on all Supabase tables. `project_assets` restricted to published-project assets only — draft assets are not exposed via the anon key.
• →Rate-limiting via Upstash Redis (sliding window) on sensitive endpoints: contact (5 req/10 min), testimonials (3 req/24h), cache invalidation (10 req/min), health check (30 req/min), CSP reports (20 req/min), admin panel (5 req/15 min — brute-force protection). If Redis is not configured in production, the limiter fails closed (all requests blocked). During a transient Redis outage, it fails open to avoid blocking legitimate users — except on `/admin`, which remains fail-closed.
• →Honeypot fields on contact and testimonial forms — bots filling hidden fields receive a silent 200 response.
• →Origin validation: API requests from unknown origins are rejected in production.
• →Debug routes disabled in production: `/api/redis-test` returns 404 outside of development mode.
• →CORS restricted: `/api/health` scoped to the site origin only — monitoring tools call server-to-server, no browser CORS needed.
• →security.txt at `/.well-known/security.txt` (RFC 9116) — responsible disclosure contact.
• →No secrets in `NEXT_PUBLIC_*` — all sensitive keys (service role, Redis token, admin credentials) remain strictly server-side.
• →External validation (neutral third parties): securityheaders.com · Mozilla Observatory — HTTP security posture verified independently from the site.

Open source