DEV Community: Zerops

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

Zerops Devs — Fri, 28 Aug 2026 05:00:00 +0000

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

Live demo: https://frontend-2bdf.prg1.zerops.app/
Source: https://github.com/abdultalha0862/deploydoctor
Project page: https://appstage-290f.prg1.zerops.app/projects/deploydoctor-ai-powered-deployment-incident-diagnosis

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

Hackathon page: https://www.wemakedevs.org/hackathons/zerops
Kickoff livestream with Kunal Kushwaha and Francesco Ciulla: https://www.youtube.com/live/1bpt0iuXuNM

Connect with Abdul Talha

X: https://x.com/AbdulTa62185243
LinkedIn: https://www.linkedin.com/in/abdul-talha/
GitHub: https://github.com/abdultalha0862

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

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 Devs — Mon, 24 Aug 2026 07:29:16 +0000

"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

Live app: https://app-1eb-3000.ny1.zerops.app/
Source: https://github.com/Hardikkhanduja/ZeroArch
Hardik's original build post: https://www.linkedin.com/posts/hardik-khanduja-60a9a6287_buildinpublic-zeropshackathon-wemakedevs-activity-7491519883357286400-JiO2

The Zerops Challenge

Hackathon page: https://www.wemakedevs.org/hackathons/zerops
Kickoff livestream with Kunal Kushwaha and Francesco Ciulla: https://www.youtube.com/live/1bpt0iuXuNM
ZCP quickstart, the route most builders took from prompt to live URL: https://docs.zerops.io/zcp/quickstart

Connect with Hardik

X: https://x.com/HardikKhanduja
GitHub: https://github.com/Hardikkhanduja
LinkedIn: https://www.linkedin.com/in/hardik-khanduja-60a9a6287/

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

The rise of self-hosted PaaS — is $5 VPS all you need?

Aleš — Fri, 23 Aug 2024 06:08:12 +0000

There's a little trend going on over at the developer community on X, jokingly called "$5 VPS" — every time Vercel has an oopsie and sends someone a $100k bill, people jump to replies shouting, "Stop using Vercel, just buy this $5 VPS, I use it to handle 100k visits, no problem". So let's explore this trend and see what it really means.

When hosting apps in 2024, out of the many different options for hosting, you have these four major groups — big cloud, dev-focused PaaS, "frontend" focused platforms and VPS/VDS hosting. Honorable mentions are managed Kubernetes platforms and specialized managed hosting, where nearly any open source software offers some sort of cloud managed version. Lines between these groups are blurry, as many providers branch out into multiple categories.

A little bit of history

How did we get here? The pioneer in cloud hosting was Amazon, with their AWS in 2006, followed by Azure and Google Cloud in 2010. Meanwhile Heroku launched properly in 2009, offering a fresh take on the cloud, using Amazon's infrastructure but offering a more user-friendly and focused approach. In 2013 DigitalOcean was founded, creating a mix between VPS and managed solutions. In 2014/2015, Netlify and ZEIT (eventually rebranded as Vercel) were founded, specializing in building and hosting serverless and frontend apps. Around 2019 a new generation of developer friendly PaaS started gaining traction, with Render and Fly leading the charge. Many smaller / narrowly specialized hosting platforms were founded since, many building on top of others.

Rise of the cheap VPS and self-hosted PaaS

Now self-hosted PaaS on cheap hardware is getting popular. You can get 8 vCPU + 16 GB RAM server node for yourself for about 29.99 euro, that's surely enough to run everything one needs, right?

On top of that, nowadays there are many popular open-source PaaS alternatives.

And many dev-ifluencers are promoting them over PaaS.

The perfect solution?

Sounds great in theory, you get the cheap hardware and you get all the functionality of a PaaS for free through open source software. But let's break down a couple of main differences between self-hosted PaaS and PaaS:

1. You don't have to deal with the infrastructure

PaaS providers typically run hundreds or even thousands of robust server nodes or use Amazon's EC2 infrastructure to provision resources for your containers. You don't have to monitor the infrastructure, handle the OS / Kernel updates, deal with faulty hardware, you never touch the actual underlying infrastructure.

2. You get managed databases and storage solutions

PaaS providers usually offer managed or semi-managed, production-ready services like Postgres, Redis (or open-source alternatives like Valkey), and an S3-compatible storage solution.

3. Build servers, High availability & backups

It turns out that setting up a good infrastructure isn't easy, especially if you need to go beyond simple sites or apps. Your apps should be highly available with a load balancer in front of them, running on at least two containers, your primary database should run on at least three containers (write/read/read) with proxy load balancers in front. Each of these containers and load balancers should run on a different physical server. Storage should run on a different node. Your backups should be encrypted and saved on a different node. Builds should run on a different node.

With a self-hosted PaaS you are responsible for the underlying infrastructure, scaling capabilities of the platform software don't really matter that much, because you still have to scale the hardware yourself. The database services on self-hosted PaaS will likely be nothing more than Docker Compose containers spun up on demand. While this might be fine as long as you properly handle the underlying file system, it's not the ideal solution for a production database. Database services simply require a little bit more care. You might also end up in a situation where you have too much RAM and not enough CPU, since the underlying infrastructure is not granular enough. The actual utilization of the paid resources might also vary, since you can't scale automatically on the fly or start your build servers only when you need to run builds. And the more applications you have, the messier things can get.

But, can't you just run everything on a single server? Well, yes—especially if you're hosting only a couple of small, mostly static (or server-side generated/rendered) sites, and everything might work just fine. That is, until it doesn't.

Ultimately, it comes down to whether the cost is worth the extra features and the comfort of not dealing with the infrastructure at all, while having a setup you can trust to scale with your needs.

Price comparison

Price differences might vary a little across different use cases, and you usually you wouldn't probably need to use dedicated CPU for all services. But to make the comparison as accurate as possible, let's choose a medium-sized real-life production project with a typical setup and try to configure a similar setup for each provider, considering both features and resources. And when possible, dedicated or performance CPU cores will be used to normalize performance levels, as shared CPUs can have varying overcommitting ratios across different providers.

Reference setup

Prices for different providers

You can find the configuration details by hovering over the items on Zerops' website.

Zerops, the developer first PaaS

At Zerops, we recognize the need for an affordable PaaS. In the best-case scenario, what you'd want as a developer:

the ability to create as identical as possible, but also affordable environments for each project, one environment for development, one for production, even one for each developer to use locally
platform (and unified setup) that can support you no matter if you need to host a small static app, or a large project with multiple databases and microservices and anything in between
flexibility of VPS

An integral part of these requirements is that resources should be inexpensive, with all advanced features included by default. And so our vision is the perfect mix of developer experience, flexibility, robustness, and scalability, along with a pricing model that doesn't get in the way of good development practices.

You can get all the features you'd expect from a PaaS, but also automatic scaling, unified environments and prices of resources approaching those of cheap VPS providers.

This pricing applies equally to both simple and complex projects, regardless of whether they have low or high traffic.

A 10-minute walkthrough of Zerops

Our journey integrating Qdrant in Zerops

Zerops Devs — Thu, 22 Aug 2024 21:09:13 +0000

Vector databases are revolutionizing how data is managed and stored for AI applications. At Zerops, we recognized the growing importance of vector databases, leading us to integrate Qdrant, one of the most popular options available. While it might seem straightforward to spin up a Qdrant instance using a Docker container, the reality of managing a production-ready vector database is far more complex. In this article, we'll explore the intricacies of Qdrant implementation and how we've addressed the challenges at Zerops.

Understanding Data in Qdrant

In Qdrant, data is organized into collections, which are essentially named sets of vectors. Each collection contains vectors that share the same dimensionality and are compared using a specific metric. Collections in Qdrant are further divided into shards—independent stores of vectors that can handle all the operations provided by collections.

This architecture allows for distributing the workload across multiple Qdrant nodes in a cluster, enhancing performance and reliability. To ensure high availability (HA), shards can be replicated across nodes. Understanding this structure is crucial for grasping the complexities of deployment and management.

Deployment Options: Balancing Simplicity and Reliability

At Zerops, we offer support for both HA and non-HA modes of Qdrant, giving you the flexibility to choose the configuration that best suits your needs.

Non-HA Mode: Simplicity for Non-Production Projects

The Non-HA mode is perfect for non-production projects where data persistence isn't critical. This setup involves a single Qdrant node, making it easy to install and manage. In Zerops, deploying Qdrant in Non-HA mode is straightforward:

We run the Qdrant binary in a Ubuntu container.
Port 6333 is opened for communication.

Even if a data outage occurs, our backup solution ensures minimal disruption.

HA Cluster: Reliability for Production Environments

For production environments where reliability and data availability are crucial, the HA cluster mode is essential. Setting up an HA cluster can be complex, but we've streamlined the process in Zerops:

Cluster Configuration: We enable cluster mode by adding enabled: true to the configuration file and configure peer-to-peer communication on port 6335:

   cluster:
     enabled: true
     p2p:
       port: 6335

Node Setup: Building a cluster requires careful configuration of each node:
- The first node runs with a --uri <uri> flag to let other peers know how to be reached.
- We make the address of the first peer node1.db.<service_name>.zerops available in local DNS.
- All other peers start with the --bootstrap <cluster_uri> flag to locate the rest of the cluster.
High Availability: Qdrant uses the RAFT protocol, which requires more than 50% of the nodes to be functional. We automatically set up 3 nodes per cluster to meet this requirement.
Automatic Replication: By default, we automatically create replicas of any collection across all nodes. This safeguards against data loss if a node fails and serves as a safety net for incorrect replication_factor configurations. This approach ensures data safety even if the replication_factor is incorrectly configured by the user. If desired, this feature can be disabled by setting the automaticClusterReplication parameter to false.
Failure Recovery: If a node fails, we automatically start a new node, connect it to the cluster, and create replicas of each collection and shard on the new node.
Node Cleanup: We streamline this process by utilizing the Qdrant API to identify the current cluster Leader node, which then efficiently handles the removal of failed nodes.

Overcoming Technical Challenges

During the integration of Qdrant with Zerops, we encountered and solved several complex issues. Fortunately, Qdrant offers robust tools to monitor and manage clusters through its well-documented REST and gRPC APIs.

One issue we faced was that when a new node was added to the cluster, it appeared fully operational but couldn't receive new replicas. This is often due to ongoing data transfers between nodes, which can take considerable time. To address this, Qdrant provides the POST /cluster/recover endpoint, which can be triggered on any non-leader node. This endpoint sends a request to the current leader to create a snapshot. The leader then sends this snapshot back to the requesting node for application. This snapshot captures the cluster's agreed-upon state at a specific point in time, allowing the cluster to recover and synchronize.

Data Backup: Safeguarding Your Qdrant Data

At Zerops, we prioritize the safety and security of your data by providing:

Daily, automatic backups at no extra cost
Backups in the form of encrypted disk snapshots for each collection
Secure upload to our S3-compatible backup storage
Retention of up to 100 backups per stack for a maximum of one month
Current maximum storage size per project of 25 GiB

You also have the flexibility to choose between different backup options, including one-time backups, regular backups with a customizable frequency, or even disabling backups entirely.

Our backup retention policy is designed to provide comprehensive coverage. For example, if you back up every hour, you'll have up to 4 days of backups available. This ensures that you have access to recent versions of your data in case of any issues.

The Value of Managed Vector Databases

While it's possible to set up and manage Qdrant yourself, doing so properly requires significant expertise and resources. Our managed Qdrant solution allows you to leverage the power of vector databases without the operational complexities. You can focus on developing AI features, while we ensure your vector database is running optimally, is highly available, and is protected against data loss.

Ready to harness the power of vector databases without the operational headaches? Give Zerops a try