Selected Work
$ ls -la ./work
total 8
-rw-r--r-- observability Self-hosted ELK at 5TB/day 5TB+ logs ingested per day -rw-r--r-- edge platform A CDN for hundreds of domains 50TB daily traffic sustained -rw-r--r-- reliability A 100GB/s load-test rig 100GB/s peak generated traffic -rw-r--r-- knowledge systems Knowledge base automation 80% faster information retrieval -rw-r--r-- aiops A tool-using agent for infrastructure 40% infrastructure cost reduction -rw-r--r-- automation An automated blog pipeline 70% content creation time cut -rw-r--r-- meta This site ~$6 monthly run cost -rw-r--r-- security Hardening a public agent endpoint 6 controls with a linked file and a testSelf-hosted ELK at 5TB/day
A self-hosted ELK stack ingesting more than 5TB of logs a day at roughly half the previous cost, on fixed spend instead of volume-based pricing.
Our observability spend was tied to DataDog's volume-based pricing while log volume climbed past 5TB a day.
Every new service made the bill worse, and dropping logs to save money would have gutted visibility.
I led the migration to a self-hosted ELK stack, designed and built in reproducible Terraform and Ansible so the cluster could scale to usage instead of being hand-grown.
The platform ingested over 5TB of logs per day at roughly half the previous cost, trading volume-based pricing for a fixed, predictable spend.
// provisioned by Terraform + Ansible — rebuildable from zero
// fixed cost replaced volume-based pricing
- — Self-hosting means owning upgrades, scaling, and cluster health — the price of leaving volume-based pricing.
- — Everything went through Terraform and Ansible, even when a one-off manual fix would have been faster that day.
- — Fixed cost cuts both ways: the cluster had to be deliberately scaled to usage rather than absorbing spikes on a vendor's balance sheet.
A CDN for hundreds of domains
A multi-tenant CDN serving hundreds of domains and 50TB of daily traffic, absorbing the load that had been reaching origin servers.
Hundreds of domains were leaning on their origin servers for traffic a cache should have absorbed, and page load times showed it.
The platform had to sustain 50TB of traffic per day without an operations team dedicated to babysitting it.
I architected and maintained a content delivery network fronting hundreds of domains, tuning caching to keep requests at the edge.
The CDN sustained 50TB of daily traffic, reduced origin hits, and improved page load times across every property.
// cache hit: the origin never sees the request
- — Aggressive caching protects origins but trades content freshness — that tuning is never finished.
- — One shared platform for hundreds of domains buys consistency and concentrates blast radius; changes rolled out carefully.
A 100GB/s load-test rig
A distributed load-test rig generating 100GB/s at peak, so capacity and reliability decisions came from measurements rather than guesses.
We needed to know how the platform behaved under real traffic spikes before customers delivered them.
The rig had to generate enough traffic to genuinely stress a platform built for 50TB days — small synthetic tests would have proven nothing.
I implemented a load test framework on K6 and K3s/K8s capable of sending over 100 GB/s of traffic, emulating real-world spike patterns.
Performance, reliability, and scalability were verified under realistic conditions — capacity decisions were made from measurements, not guesses.
// spikes rehearsed here, not discovered in production
- — A self-managed K6/K3s fleet is more upkeep than a load-testing SaaS, in exchange for full control of traffic shape and scale.
- — Synthetic traffic approximates real users, never equals them — results were treated as bounds, not guarantees.
Knowledge base automation
An automated knowledge base that made information retrieval 80% faster and halved onboarding, keeping documentation in step with the code.
Documentation drifted: answers lived across repos and went stale the moment the code moved on.
Manual upkeep didn't scale, and a search that returns stale docs is worse than no search.
I built a context pipeline over the documentation: embed on change, semantic search across every repo's docs, consistency checks between them, and automated updates triggered by the code itself.
Information retrieval got 80% faster, documentation accuracy reached 95%, and onboarding time dropped by half.
// docs update when the code does, not when someone remembers
- — Automated doc updates still ran through consistency checks — trust in the corpus mattered more than update speed.
- — A vector index is one more piece of infrastructure to run; 80% faster retrieval paid for it, but it isn't free.
A tool-using agent for infrastructure
A tool-using agent that proposes infrastructure changes behind a human approval gate — 40% lower cost and 60% lower MTTR.
Infrastructure decisions — scaling, right-sizing, incident response — leaned on whoever happened to be watching the dashboards.
Recommendations had to be grounded in real metrics, and the agent's capabilities had to be scoped so that a bad suggestion cost a review comment rather than an outage: an LLM guessing about infrastructure is a liability, not a tool.
I built a tool-using agent on LangChain whose tools read Prometheus metrics and logs. It queried the telemetry itself, analyzed the estate, proposed cost optimizations, predicted scaling needs, and generated the infrastructure-as-code to act on them — but its capabilities stopped at recommending. Applying anything required an engineer's approval.
Infrastructure costs came down 40% and MTTR dropped 60% — every change still passing through a human gate, with a growing share of issues prevented before they paged anyone.
// grounded in measured data, reviewed by humans
- — The agent proposed; engineers approved. Slower than auto-apply, but an unreviewed LLM change to production infrastructure was never on the table.
- — Grounding every recommendation in Prometheus data limited the agent to what was measured — blind spots in metrics became blind spots in advice.
An automated blog pipeline
An automated research-and-draft pipeline with a two-pass LLM review before anything publishes, cutting content creation time by 70%.
Publishing consistently is the part of technical writing that fails first — research and drafting eat hours that production work always wins.
Automation could not mean spam: posts needed trending relevance, deduplication against everything already published, and review before anything shipped.
I built a GitHub Actions pipeline that pulled trending topics from developer communities, drafted SEO-optimized posts with LLMs, and ran a two-pass review with duplicate detection before publishing.
Content creation time dropped by 70% and the site gained a steady stream of fresh, relevant posts.
- — Every draft went through a second review pass and duplicate detection — cadence was never worth publishing junk.
- — Trending-topic sourcing keeps posts relevant but biases toward what is already being talked about.
This site
The site you are reading: one Cloudflare Worker at the edge, with its full architecture and monthly running cost published on the colophon.
This site is the portfolio piece I couldn't buy: I wanted to demonstrate the architecture I sell by running it.
It had to be measurably fast worldwide, cost almost nothing to run, and stay honest — no fabricated numbers anywhere.
I built it on Astro with React islands and deployed it as a single Cloudflare Worker: nearly every page prerendered, with the AI copilot, contact flow, and live telemetry running through edge bindings.
It runs as a single Worker at the edge, and the parts that could be asserted are instead published: the full architecture, the monthly cost breakdown, and the Lighthouse scores with the date and commit they were measured at, all on the colophon.
- — Prerendering nearly everything means dynamic features live in islands — more discipline, much faster pages.
- — Workers AI within the plan allowance over premium model APIs: bounded cost, constrained model choice.
- — Where a number can't be measured, the site says so instead of inventing one.
Hardening a public agent endpoint
The Copilot on this site is an unauthenticated, tool-using agent on an endpoint that spends money per request. Every control that holds it up is linked to the file that implements it and the test that would catch its removal.
The Copilot on this site is a public, unauthenticated, tool-using agent on an endpoint that spends money per request — the same shape as the agent surfaces I build on platforms, at a size where I own every line of it.
No login, no human in the loop, no one watching a dashboard. Every control has to hold against an anonymous caller and against a model that can be argued with, and it has to hold overnight.
I worked the trust boundary a class at a time: prompt injection through retrieved and page text, tool-call abuse turning the navigation tool into an open redirect, unbounded request bodies on an endpoint whose Content-Length is client-controlled, and volumetric cost abuse. Each class got a control that fails closed and a test that fails the build.
Six controls, each linked below to its implementation and its test. The limiter denies rather than serves when KV is unreachable, the only side-effecting tool resolves against a closed allowlist server-side before anything is streamed, and the public MCP route answers from a bundled index while making no model calls at all.
// an unreachable counter denies the request, it does not wave it through
// retrieved and page text enters the prompt as data, never as instructions
- — Failing closed means a KV outage returns 503 instead of serving the assistant unmetered — availability traded for a bill I can predict.
- — The CSP is still Report-Only. Enforcing it would block Astro's per-build inline hydration scripts until they are hashed, and a policy that breaks the page is worse than one being observed.
- — The rate-limit counters are read-modify-write on KV, so under concurrency they under-count — and a contended write is tolerated rather than denied, since the shared daily key collides under ordinary multi-user traffic. Exact enforcement needs a Durable Object, which this traffic does not justify.
-
src/lib/server/ratelimit.ts
Three KV tiers per request — burst, per-IP, and a global daily backstop across all callers. A missing or unreadable KV denies with 503 rather than serving unmetered inference; the write path tolerates per-key contention, a bounded exception the tradeoffs below own.
// pinned by tests/unit/ratelimit.test.ts
-
src/lib/copilot/routes.ts
The one tool with a side effect resolves its target against a closed allowlist on the server. Schemes, protocol-relative targets and traversal are refused before anything reaches the visitor.
// pinned by tests/unit/routes.test.ts
-
src/lib/copilot/agent-core.ts
Retrieved and page text is fenced as untrusted data in the prompt, and the loop is bounded at three tool steps and 1200 output tokens so one request cannot fan out.
// pinned by tests/unit/agent-core.test.ts
-
src/lib/server/http.ts
Bodies are counted in encoded bytes and the stream is cancelled the moment the cap is passed — rejecting a large body after buffering it is not a defence.
// pinned by tests/unit/http.test.ts
-
src/lib/server/beacon-core.ts
The analytics sink accepts a closed set of events, normalizes paths through the same route allowlist, and has no field that can carry an identifier.
// pinned by tests/unit/beacon-core.test.ts
-
src/lib/voice/origin.ts
WebSocket upgrades check Origin themselves and refuse an absent one, because CORS does not apply to upgrades — the browser sends the header and enforces nothing.
// pinned by tests/unit/voice-origin.test.ts
// repo-relative paths — a test asserts every file above still exists
Want something in this list built for you? Get in touch.