DEV Community

Cover image for "Read the failure. Ship the fix." Abdul Talha on building DeployDoctor on Zerops
Zerops profile image Zerops Devs
Zerops Devs for Zerops

Posted on

"Read the failure. Ship the fix." Abdul Talha on building DeployDoctor on Zerops

A DevOps technical writer built a tool that reads your deployment logs and tells you what broke. The interesting decision is that it checks its own rules before it calls the AI.

Over the weekend of August 8 and 9, Zerops ran The Zerops Challenge in collaboration with WeMakeDevs. Forty eight hours, solo entries only, and one hard rule: the finished thing had to be a real application deployed on Zerops with a live URL, still running when the judges reached 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 was DeployDoctor, by Abdul Talha.

Here are his answers, close to verbatim.

First, introduce yourself.

I am Abdul Talha, a DevOps technical writer focused on cloud infrastructure, application deployment, self-hosting, and open-source technologies.

I work with tools like Docker, Docker Compose, Linux, cloud platforms, reverse proxies, databases, and observability tools. When I write a technical guide, I prefer to deploy and test the application myself so I can document the actual process, issues, and solutions rather than just explain the theory.

I also follow a docs-as-code workflow using Git and Markdown. Along with technical writing, I build projects to learn and experiment with different DevOps and cloud technologies. DeployDoctor was one of those projects, which I built as part of the Zerops Challenge.

What did you build, and where did the idea come from?

I built DeployDoctor, a tool that helps developers troubleshoot deployment issues.

The idea came from my own experience. While deploying different applications, I faced many issues where finding the actual cause and solution took a lot of time. So I thought of building a tool that could identify frequently occurring deployment problems and provide their solutions in one place.

DeployDoctor analyzes deployment logs, identifies known error patterns, and provides the likely cause and recommended fix. For issues that the built-in analyzer cannot identify with enough confidence, it uses Gemini for further analysis.

The example in the screenshot is one every developer has met at least once: the app is connecting to PostgreSQL via localhost instead of the database service hostname.

Walk us through your architecture.

DeployDoctor has three main components: a React frontend, a Fastify API, and a PostgreSQL database.

The frontend is responsible for the user interface, while the API handles the deployment log analysis and application logic. PostgreSQL stores the incidents and analysis results.

For log analysis, I used two layers. First, the API checks the logs against known deployment error patterns. If it finds a match with enough confidence, it returns the result directly. If it cannot identify the issue confidently, it sends the logs to Gemini for further analysis.

On Zerops, I deployed the frontend and API as separate services. This kept the application components separated and also helped me understand how services are configured and connected on Zerops.

One part I found interesting was using the rule-based analyzer before Gemini. It makes the analysis more predictable for known issues and avoids using AI for every request.

What did Zerops get wrong most often, and how did you catch it?

Most of the issues I faced were related to deployment configuration rather than the application itself.

I had to make a few changes to the Zerops configuration, including the Prisma setup and the API URL used by the frontend. I caught these issues by checking the build and deployment logs and testing the application after each deployment.

Whenever something failed, I checked the logs, identified the configuration issue, made the change, and deployed it again.

What did you not understand about Zerops when you first opened it?

When I first opened Zerops, I wasn't immediately familiar with how the platform structured applications and services.

I was used to deploying applications with Docker Compose or directly on a VPS, so the Zerops service-based approach was different from what I was used to. I initially needed some time to understand how the frontend, API, database, environment variables, and deployment configuration fit together.

Once I understood that structure, the deployment process became much easier to follow.

Any advice for people who are just starting their deployment journey?

Start with a simple application and understand how it works before trying to deploy it.

Learn the basics of the application stack first, especially things like ports, environment variables, databases, and how different services communicate with each other. When something fails, don't immediately change multiple things at once. Check the build and application logs, identify the actual error, and then fix it step by step.

Also, don't be afraid of deployment errors. They are a good way to understand how applications actually work in production. The more applications you deploy and troubleshoot, the easier the process becomes.

What we are taking from this

Two things stand out, and neither is the AI.

The first is the design decision Abdul flags himself: the rule-based analyzer runs before Gemini, not after, and not instead. A known failure signature is matched deterministically and returned immediately. Only when confidence is too low does the log get handed to a model. That means the common cases are instant, free, and give the same answer every time, and the model is reserved for the cases that actually need judgement.

That is a better instinct than most AI tooling shows right now, and it is the same instinct behind good infrastructure. Reach for the deterministic thing first. Keep the expensive, non-repeatable thing for the problems that earn it. It is not a coincidence that this came from someone whose day job is deploying software carefully enough to write down exactly what happened.

The second is his answer about the first hour. He came from Docker Compose and from putting things on a VPS directly, and the thing that slowed him down was not a command or an error message. It was the mental model. How the frontend, the API, the database, the environment variables and the deployment config relate to each other on Zerops is genuinely a different shape from a compose file, and until that shape is in your head, nothing else lands.

We think about this a lot. Zerops asks you to think in services on a private network rather than in containers on a host, and that model is the reason the platform can do the things it does. It is also, reliably, the thing that costs people their first hour. Abdul's account is useful precisely because he is not complaining about it. He needed time, he got it, and then, in his words, the deployment process became much easier to follow.

The gap between those two states is the whole problem worth solving, and it belongs in onboarding rather than in a hackathon weekend.

Congratulations, Abdul. Well earned.

DeployDoctor

The live demo ships with example logs you can click, including CrashLoopBackOff, Node OOM, DNS ENOTFOUND and a missing env var, so you can try it without having to break something first.

The Zerops Challenge

Connect with Abdul Talha

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

Top comments (0)