DEV Community

Cover image for Hardik Khanduja built ZeroArch in 48 hours in Zerops: a canvas you draw your infrastructure on, and an AI that audits it before it writes the YAML
Zerops profile image Zerops Devs
Zerops Devs for Zerops

Posted on

Hardik Khanduja built ZeroArch in 48 hours in Zerops: a canvas you draw your infrastructure on, and an AI that audits it before it writes the YAML

#zerops #wemakedevs #hackathon

"I'm a visual thinker, and a lot of developers are too" - Hardik Khanduja

Over the weekend of August 8 and 9, Zerops ran The Zerops Challenge in collaboration with WeMakeDevs. The format was deliberately unforgiving. Forty-eight hours, solo only, no planning phase and no slide decks. The only hard requirement was that the finished thing had to be a real deployed application on Zerops with a live URL, still running when the judges got to it. Not a local demo, not a screen recording.

Over 1,000 developers signed up, more than 10,000 build and deployment pipelines fired, and 250+ valid projects came out the other end. Seven of them won. One of the winners was Hardik Khanduja, who took a share of the $5,000 credits pool for ZeroArch, a visual infrastructure designer that turns a drag-and-drop diagram into a production ready zerops.yml.

We sent him some questions. His answers turned out to be one of the most useful pieces of platform feedback we got out of the whole weekend, so we are publishing them close to verbatim.

First, introduce yourself. Hi, I am Hardik Khanduja. I am a full-stack developer who loves building in public and experimenting with new tech. I've always been interested in finding ways to make developer workflows smoother, especially when it comes to the gap between writing code and actually managing the infrastructure it runs on.

What did you build, and where did the idea come from? I built ZeroArch. It's an interactive, drag-and-drop canvas where you can visually map out your cloud architecture, like connecting your frontend to an API and a database. Once you design it, Google Gemini AI audits the setup for security issues and generates a production-ready zerops.yml config file for you.

The idea came from a personal frustration: writing YAML files by hand is annoying and error-prone. One wrong space or an exposed port, and your app breaks or becomes vulnerable. I'm a visual thinker, and I realized a lot of developers are too. I wanted a tool where you could visually sketch what you want, and let the code write itself.

The canvas. Components come out of the left rail, and connections between them are the architecture.

Walk us through the architecture. The stack is Next.js 15 using the App Router, React Flow for the interactive canvas, PostgreSQL for storing saved blueprints, and Prisma as the ORM.

The most interesting part is how the AI compiler works. React Flow stores the canvas state as a JSON of nodes and connections. When you hit Generate, our server converts that graph into an AST, an abstract syntax tree, and feeds it to Gemini. The prompt is designed to act like a strict DevOps engineer. It doesn't just write the YAML, it actively warns you if you do something insecure, like trying to connect a frontend directly to a database without an API layer in between.

The audit pass on a heavier design. Note what it is actually saying: the ingestion layer is correctly decoupled through RabbitMQ, a connection to the results database is missing, and only the web client and upload API should have public routing enabled. The queue, the worker and the database stay inside the private project network.

That last screenshot is worth sitting with for a second, because it is the argument ZeroArch is quietly making. The interesting part of an architecture is not the list of services. It is which of them can be reached from the outside, and which ones can only be reached by their neighbours. Drawn on a canvas, that becomes obvious. Written by hand in YAML at two in the morning, it does not.

What did the AI get wrong most often, and how did you catch it? And on the platform side, what fought you hardest? When Gemini was generating the zerops.yml files, it would occasionally hallucinate Alpine-specific packages or get the YAML indentation wrong. To catch this, I had to refine the system prompt with strict schema constraints, forcing the AI to output structured data that we could parse safely.

On the platform deployment side, the trickiest thing was Alpine's lack of legacy OpenSSL 1.1 libraries, which Prisma was expecting. Prisma would crash on boot because it couldn't find the shared library. I had to explicitly configure Prisma's binaryTargets to support OpenSSL 3.0, and add a prepareCommands step in zerops.yml to install openssl via apk using sudo, since the setup runs as a non-root user.

What did you not understand about Zerops when you first opened it? The database connection binding. Coming from platforms that auto-inject the database URL directly into the app, I didn't realize at first that Zerops gives you the base connection string, pointing to /postgres, but you have to manually suffix it with /db, or whatever your specific database name is, in the secret variables to let Prisma write to it. Once I realized PostgreSQL 15 has strict permissions on the default system database, it clicked, but it definitely had me scratching my head for a bit.

Any advice for people just starting out their deployment journey? Don't ignore the logs, and pay attention to your environment's OS. A lot of developers write code on macOS or Windows and forget that their app is going to run in a lightweight Linux container, like Alpine, in production. If you rely on database engines or native node modules, test your container configurations early. And most importantly, build in public. The feedback and support from the community are what keep you going when deployments get frustrating.

What we took from this

The Alpine and OpenSSL one is the flip side of running real Linux containers rather than an abstracted app runtime. You get prepareCommands, apk, and control over the image, which is exactly what let him fix it in one step. You also get to meet the problem in the first place. That trade is one we would make again, but it is the sort of thing worth being upfront about.

And his advice is the correct advice. The gap between a laptop and a production container is where most first deployments die, and it is why we would rather you meet that container early than have it hidden from you until something breaks.

Congratulations, Hardik. Well earned.

ZeroArch

The Zerops Challenge

Connect with Hardik

More winner interviews from The Zerops Challenge are on the way.

Top comments (0)