The Terraform estate behind a production AI platform had grown into a monolith that was heavy to change.
I broke it into reusable modules and ported a dozen components myself — Kubernetes, VPC, databases, observability — across AWS, GCP and Scaleway.
Each building block now evolves on its own, without risking another.
Security ships in the same modules as everything else: private networking, dedicated IAM roles and least-privilege rights for every environment, rather than a layer bolted on afterwards.
The teardown path is separate from the build path and goes back through the control plane: nothing disappears as a side effect.
Rebuilding critical infrastructure stays frightening as long as you cannot prove nothing moved.
I contributed to a script — Bash plus a Jenkins pipeline — that compares the Terraform plan of two branches, diffing resource_changes stage by stage, with the environment picked at run time.
Enough to validate a migration without deploying it blind.
Testing close to production called for realistic data, without ever exposing customer records.
I wrote a script — Docker plus Bash — that copies the production RDS database into test environments, anonymising it on the way; infrastructure provisioned in Terraform with strict IAM roles, and run through GitHub Actions.
Test environments now mirror production faithfully, which makes bugs reproducible — with no confidentiality risk.
Release notes were written by hand, and the product team learned about shipments late.
On every merge to main, a Jenkins pipeline reads the Git history, generates the changelog, updates the release page through the Notion API and notifies the product Slack channel.
Nobody has to think about it any more, and everyone knows what went to production.
Access to RDS databases had to be controlled and traced, without leaving standing permissions open.
I built a dynamic approval flow through Slack, backed by AWS SSM, Lambda, CloudTrail and EventBridge, with connections secured by SSH/VPN tunnels and SSO authentication.
Every request is approved, watched in real time through CloudWatch and New Relic, and leaves a complete trail.
Diagnosing an incident meant hopping from one tool to another.
I centralised metrics — collected by Prometheus, visualised in Grafana — and logs in OpenObserve, with contextual Slack alerts that link straight to the relevant runbook.
Instance health reads in real time, and root cause comes much faster.
StackPrometheus · Grafana · OpenObserve · Slack
Full-stack monitoring with New Relic
Little real-time visibility into the health of the AWS infrastructure and the applications.
I integrated New Relic end to end: infrastructure agent on ECS, APM on EC2, Browser agent on the front end, wired to AWS services — RDS, ECS — through the API.
Dashboards and real-time alerts on CPU, memory and database performance, pushed to Slack, so incidents are spotted and handled faster.
Nobody really knew where the cloud bill came from.
I built a dashboard that queries AWS Cost Explorer, aggregates the data in Python and renders it in Grafana, with alerts when spend per service or per team drifts.
Its main use was flushing out orphaned resources and forgotten snapshots we were paying for without knowing.
StackAWS Cost Explorer · Python · Grafana
Open source · GitHub
Open source projects
Personal projects whose code is public, from FinOps to AI agents.
wasteless.io
My reference FinOps project — open source and self-hosted: making AWS waste visible before it reaches the bill.
Nine detector families — idle EC2 and RDS, orphaned EBS volumes, elastic IPs, forgotten snapshots and AMIs, unused load balancers, NAT gateways and VPCs, gp2 volumes to migrate to gp3. Every recommendation carries its evidence, a confidence score and an estimated monthly cost.
Safe by construction: collection runs through a read-only IAM role, any write requires a second optional role and fails without it, and dry-run mode is on by default.
Closed loop: three execution paths — direct AWS action, Terraform pull request, or manual task — then verification. A Cost Explorer follow-up confirms the real saving once seven billing days have passed.
Sorting an inbox by hand is repetitive and time-consuming.
Five Python agents, orchestrated behind a FastAPI service, hand over to each other on the Gmail inbox: reading and classifying messages, drafting a reply, approval before sending.
A testing ground for orchestrating several agents around one concrete task.
StackPython · FastAPI · Gmail API · React · Docker