Each project tells the same story: I found a gap, built the solution, and can say what changed.
NetBird — replacing the existing VPN
in progress
The gap: OpenVPN: outdated, manual config on every joiner/leaver, nobody else knows how to troubleshoot it.
What changed: A clean private network, managed through a UI — each machine added in two clicks, access cleanly revoked.
The context
OpenVPN’s era is over. Every network change meant editing a config file by hand, one line at a time, then restarting. Only I could do it — and when I was on leave, everything bottlenecked.
What I built
NetBird, self-hosted: a WireGuard overlay network with an admin UI. Machines register themselves, rules are visible, access gets revoked cleanly.
What it shows
Moving from a tool only I hold the keys to, to a tool the team understands. That’s the exact shift from craft to industrial.
What I learned
WireGuard is simpler than people say; NetBird adds the orchestration layer that was missing. The trickiest part is key management and rotation.
A modern, self-hosted VPN the whole team can use without calling me.
Toolbox — install without thinking
in progress
The gap: Every reinstall = half a day lost redoing the same gestures, with the risk of missing one security setting.
What changed: A colleague's machine becomes operational with one command, always the same way — SSH keys, business tools, configs.
The context
Every reinstall, the same playlist of gestures: SSH keys, packages, configs, company tools. Each repeated gesture is a chance to forget something — and production machines don’t forgive omissions.
What I built
Toolbox: a versioned Ansible + scripts set that installs the company’s tools on colleagues’ workstations from a single source of truth. Every fresh machine ends up in the same state, every time.
What it shows
The utility script I write internally uses the same reflex as infrastructure: a reproducible sequence, a quality contract. Maintenance is instant in peer review because there is one source of truth: the playbook.
A set of Ansible playbooks and scripts that turns a fresh machine into a ready workstation, with no manual steps.
Local LLM — toward a LiteLLM / Bifrost AI gateway
in progress
The gap: I have to understand AI tooling from the inside, not watch from the sidelines — and build tomorrow's AI infrastructure without improvising.
What changed: Local LLM experiments that led to a running POC: LiteLLM / Bifrost AI Gateway, OVH AI Endpoints and Mistral providers, harness testing and scoping for potential AI projects.
The context
The appetite: understand AI tooling from the inside. What started as an experiment — running models locally on my own hardware, learning the system layer (memory, quantization, latency) that abstractions hide — has grown into a structured effort.
What I built
- Local experiments: a home stack to run LLMs, managing memory, contexts and API exchanges. That groundwork led to the next step.
- AI gateway POC, in progress: LiteLLM / Bifrost AI Gateway as the single entry point, wired to two providers — OVH AI Endpoints and Mistral. The goal: route, throttle and observe model calls the way you route network traffic.
- Tooling evaluation: harness tests and scoping of potential AI projects, to separate what deserves industrialization from what stays exploration.
What it shows
Going from AI consumer to AI operator. An AI gateway is reasoned about like network infrastructure: routes, quotas, monitoring, accountability. Same trade, different layer.
Where I’m heading
Deepening my knowledge of LLMs, AI infrastructure and its operations — that’s the direction this site documents. The POC becomes the base if a real production need emerges.
From local LLM experiments to an AI gateway POC — LiteLLM / Bifrost, with OVH AI Endpoints and Mistral providers.