The Team Formation

The process kicked off with a bit of a twist: team formations were handled on a random basis. After submitting my initial application, the teams were announced the following day. I was fortunate to be paired with teammates from my own department, which made our initial communication and technical alignment much smoother from the start.

The Roadmap: A Three-Phase Journey

The event was structured into three distinct phases designed to bridge the gap between learning and execution:

• Phase 1: The Workshop (Day 1) The first day was dedicated to an intensive technical workshop. We dived deep into the world of AI Agents, Model Context Protocols (MCPs), and effective bug hunting strategies. This provided us with the necessary toolkit to tackle the challenges ahead.

• Phase 2: The Hackathon (Day 2) The second day was the main event a rigorous 6-hour sprint. Time was our biggest constraint, forcing us to prioritize core functionality and rapid prototyping.

• Phase 3: Interview of shortlisted Students

Problem Statement: Automated Bug Detection and Analysis

The core problem statement challenged us to build an intelligent, automated system capable of identifying and explaining software vulnerabilities. In the world of high-stakes hardware and software development at Infineon, efficiency in bug hunting is paramount. Our task was to create a "Black Box Solution" that didn't just find errors, but understood them.

The Architecture ("Black Box"):

The Winning Strategy: Our Multi-Agent Architecture:

When we moved from the concept to the implementation, we knew a single script wouldn't be enough. To meet the mentors' requirements for scalability and robustness, we developed a modular, agent-based ecosystem. Each agent was designed with a specific "responsibility," allowing the system to handle complex code analysis in parallel.

How We Built It

Our final architecture (shown below) relies on a collaborative workflow:

• Ingest & Context Agents: These handle the heavy lifting of parsing datasets and refining queries to the MCP server.

• The Logic Core: We split the reasoning between a Code Analysis Agent (to find the "diff") and an MCP Retrieval Agent (to fetch specific RDI documentation).

• Dynamic Scaling: To future-proof the solution, we introduced a "Known vs. Unknown" logic gate. This allows the system to use a Validator Agent (powered by Gemini/oss120B) when it encounters new rules, ensuring the system learns and adapts over time.

This modular approach was a key talking point during our final presentation. By demonstrating how the system could add new "rules" and scale with larger datasets, we were able to satisfy the mentors' technical deep-dives and secure our win.

Experience the modular workflow yourself by visiting repository on Github.

What Set Us Apart: Our Winning Edge

We approached the problem as a scalable product. Our solution stood out because it wasn't just a bug detector it was a comprehensive, agentic framework.

Here is why our approach was different:

• Architectural Superiority: Our core strength lay in a sophisticated multi-agent system that decoupled data ingestion from reasoning.

• Dual-Interface Versatility: We provided two ways to interact with our tool: a high-efficiency TUI (Terminal User Interface) for power users and a polished GUI built with Tkinter for a more accessible, user-friendly experience.

• Proactive Scaling Strategy: We directly addressed the mentors' concerns regarding long-term viability. By implementing a "Known vs. Unknown" logic gate, our system can dynamically scale its knowledge base by adding new rules through an MCP Validator Agent.

• Context-Aware Reasoning: Instead of basic pattern matching, we used an MCP Retrieval Agent to fetch real-time RDI documentation. This allowed our Explanation Agent to provide deep, technically accurate descriptions of every bug found.

• Hybrid Intelligence: By leveraging models like Gemini and oss120B within our agentic workflow, we ensured high precision in both code analysis and the generation of the final CSV output.

A Win and a Lesson

The moment finally arrived. As the winning teams were announced, hearing our names was an incredible rush. All the stress of the 6-hour sprint, the architectural debates, and the deep dives into MCP servers had paid off.

My key takeaways from this experience:

• Success isn't just the trophy: Building a complex, multi-agent system from scratch in 48 hours taught me more about software architecture than any textbook could.

• Ownership of Mistakes: I identified areas where I can improve whether in technical depth or interview communication and I’m treating those as a roadmap for my next big project.

• The Power of Collaboration: Working with a random team from my department turned out to be a blessing; we blended our strengths perfectly to deliver a polished product.

A home lab represents independence.
Not the grand, dramatic kind — more like "this is my controlled environment, powered by determination and hardware."

Mine wasn't assembled from unlimited resources, grand ambitions, or enterprise equipment humming in climate-controlled racks.

It began with one freelance contract and a refurbished HP Elite Desk 800 G1 SFF — a dated i5 4th Gen, 8 GB of DDR3, a 128 GB SSD, and a 500 GB HDD that clearly had previous owners.

Nothing impressive. Nothing costly.
Just adequate.
And adequacy is sufficient when you understand your requirements.

Why I Even Wanted a Home lab

I'm uncomfortable entrusting my data to external entities — particularly corporate giants.
Google Photos controlling access to my memories?
A commercial password manager securing my digital identity?
Random web services processing my documents for simple tasks?

Unacceptable. Hard pass.

I needed infrastructure that was:

• Private

• Affordable

• Self-owned

• And safe to experiment with without real consequences.

Commercial cloud services limit experimentation.
A home lab provides full administrative access without guardrails.

That's the difference.

The Brain: Proxmox on Old Hardware

I reformatted everything, installed Proxmox directly on the 128 GB SSD with ext4 (ZFS wouldn't cooperate with this legacy system), and instantly this retired office machine became a testing ground.

A testing ground for experimentation, learning, and late-night rebuilds when inspiration struck.

Nothing Is Public-Facing — And That's the Magic

Many showcase self-hosted infrastructures with reverse proxies, DNS configurations, Cloudflare tunnels…

Impressive architectures, certainly.
But I didn't want internet exposure for my services.

So I constructed an isolated environment:

• A virtual network (10.20.30.0/24)

• A virtual router (IPFire)

• A virtual DNS (Pi-hole)

• A VPN access point (NetBird)

• A reverse-proxy layer (Traefik)

• DNS management via Cloudflare

When remote, I connect NetBird, authenticate, and immediately access my homelab as if local.

No exposed ports.
No reverse proxy complexity.
No Let's Encrypt rate limiting concerns.
Just functionality.

The Proxy Network — A Private Layer for User-Facing Apps

To maintain complete control and isolation:

• I established a dedicated Docker bridge network called proxy with subnet 192.168.204.0/24.

• Every container serving a web interface runs inside this network—Immich, Stirling-PDF, Vaultwarden, OmniTools, etc.

• Traefik is the sole container exposed to the outer virtual network (10.20.30.0/24) via the Docker host. It manages all routing, TLS termination, and service discovery.

• Internally, no container has direct host-LAN exposure. Services communicate exclusively via the proxy network and Traefik configurations.

• External access requires VPN (NetBird). No public ports exposed, no internet-facing services.

• DNS is managed by Cloudflare, but subdomains resolve only within the VPN-connected environment.

This architecture provides:

• Strong network isolation

• Centralized, manageable ingress (Traefik)

• Minimal attack surface

• Control over service routing and TLS certificates

• Security confidence

In summary: all user-facing services behind one gateway. I control access.

The Services I Run (and Why They Matter to Me)

1. Immich — My Photos, My Rules

Google Photos works until policy changes. Until account locks. Until your photographic history depends on corporate decisions.

Immich runs on my HDD. No fees. No compression. No external access.

First time my photos feel genuinely owned.

2. Vaultwarden — Passwords Shouldn't Live in Someone Else's Building

A self-hosted password manager changes everything.

No breach concerns. No tracking. And it provides Bitwarden premium features (TOTP!) without subscription costs.

Self-hosting this revealed:

"Privacy doesn't require money. Just intention."

3. NetBird — My Portal Back Home

I appreciate opening NetBird remotely and immediately accessing my homelab as if I never left.

Seamless. WireGuard-powered seamlessness.

4. Traefik — The Entry Gate I Control

Traefik handles all service routing within my virtual network. It dynamically discovers containers and maps domains internally, while I manage DNS via Cloudflare. It also handles TLS certificates via Let's Encrypt, maintaining security without manual certificate management.

5. Cloudflare DNS — Domain Management, My Terms

Instead of dynamic IPs or exposed ports, I use Cloudflare for DNS management. Cloudflare's infrastructure provides protection while maintaining my control.

6. n8n — Automation Without Asking Permission

Cloud automation platforms impose limits: "Free tier exceeded." "Maximum X workflows." "Upgrade required."

n8n simply states:

"Do whatever you want, unlimited."

That approach works.

7. Obsync (CouchDB) — My Obsidian, Synced Like a Superpower

An extension called "Self-hosted LiveSync" syncs Obsidian via CouchDB.

I deployed a CouchDB Docker container. Connected it. Notes sync faster than commercial sync services.

Also: Zero cloud. Zero tracking. Zero dependencies.

8. OmniTools — A Toolbox That Doesn't Sell My Files

Image converters. Document compressors. All local. All private.

Uploading sensitive documents to random websites for processing always seemed problematic.

9. Stirling-PDF — My Document Converter, My Terms

I recently deployed Stirling-PDF, an open-source PDF conversion/processing service. No external dependency. No tracking. If PDF processing is needed, it happens in my infrastructure, under my control.

Subdomains? Yes. Public? Never.

I use private DNS names like:

immich.pve.onkarsathe.co.in
vaultwarden.pve.onkarsathe.co.in  
pihole.pve.onkarsathe.co.in
stirling-pdf.pve.onkarsathe.co.in

They resolve only inside the NetBird network (and via internal DNS + Traefik) and through Cloudflare-managed DNS. From the outside, these domains are non-existent.

Why This Homelab Means So Much to Me

It wasn't built with expensive hardware. It wasn't built with enterprise equipment. It wasn't built from necessity.

It was built because:

• I wanted data ownership

• I wanted to learn

• I wanted safe experimentation

• And because running infrastructure on your own terms feels right

Most pursue the cloud. I pursued control.

Future Upgrades

• More RAM

• A small NAS

• Monitoring (Grafana + Prometheus)

• UPS for power reliability

But honestly? Even without upgrades, this setup already provides something invaluable:

A private digital space that belongs exclusively to me.

Some pictures of server seating in the corner:

Final Thoughts

This homelab isn't perfect. It's not powerful. It's not impressive by enterprise standards.

But it's functional, and it's mine, and it was built with purpose.

We exist in a world where corporations want your photos, your passwords, your notes, your documents, your behaviors, your life.

My homelab is my response:

"No. I'll take it from here."