Apr 21, 2026•4 min read

Stop Paying the “DevOps Tax”: Why I Built My Own Deployment Engine

The gap between “localhost:3000” and a live production URL is still too wide. Here is how I’m closing it.

Stop Paying the “DevOps Tax”: Why I Built My Own Deployment Engine

As a Founder at Obsidyne, I wear a lot of hats. But my favorite one is still “Developer.” I live in the code — the logic, the architecture, and the problem-solving.

However, as our company grew, I found myself resenting one specific part of the stack: The Deployment Ritual.

You know the drill. You finish a brilliant Next.js application. It runs perfectly locally. But to get it live on a cost-effective VPS, you have to switch context completely. You stop being a Software Engineer and start being a SysAdmin.

  • SSH into the server.

  • Generate and add GitHub deploy keys.

  • Clone the repo.

  • Run npm install and npm build.

  • Write an Nginx config file (and pray you didn’t miss a semicolon).

  • Run Certbot for SSL.

  • Check htop to see why the server is slowing down.

It’s not hard, but it’s friction. And for us at Obsidyne, that friction compounds into hours of lost time.

I wanted the one-click simplicity of Vercel, but I wanted the raw power, control, and pricing of our own VPS infrastructure.

Since that bridge didn’t exist, I decided to build it myself.

Enter DeployDeck: The “Universal Adapter” for My Code

I spent my recent weekends building DeployDeck. It is a centralized control panel designed to be the nervous system for my development workflow. I built this solo because I needed a tool that matched my specific mental model of how deployment should work.

What does it actually do? DeployDeck abstracts away the server management entirely.

  1. Multi-Provider Support: I can connect any number of VPS nodes (AWS, DigitalOcean, Hetzner) and link multiple GitHub accounts.

  2. The “One-Port” Deployment: I select a repo, assign a port, and hit go. The engine handles the cloning, dependency installation, and build process.

  3. Automated Orchestration: This is the part I’m most proud of. The system automatically generates the Nginx reverse proxy configuration and provisions Let’s Encrypt SSL certificates.

  4. Live Telemetry: It’s not just a launcher; it’s a monitor. I can track CPU, RAM, and Storage usage across all my deployed projects in real-time. I know exactly which app is hungry and which server has room to spare.

  5. Full Lifecycle Control: I don’t need to touch the terminal to manage the apps. I can Start, Stop, Restart, or Delete any project directly from the dashboard.

I push code, I click one button, and DeployDeck handles the handshake between the raw metal and the web.

The Technical Challenge (And Why It Matters)

Building this wasn’t just about wrapping a few shell scripts in a UI. The hardest part was architecting a system that could handle the state of multiple servers simultaneously.

Handling the asynchronous nature of SSH streams while ensuring atomic operations (so a failed build doesn’t leave Nginx in a broken state) forced me to dig deep into Node.js child processes and server-side architecture.

This is the kind of engineering challenge I love: taking a complex, manual process and turning it into a silent, reliable automated flow.

A Glimpse into the Future: Obsidyne Cloud

Right now, DeployDeck is a tool I built to help us move faster. It’s our internal secret weapon.

But as the architecture matured, my partners and I realized this fits into a much larger vision we have for the company. We call it Obsidyne Cloud.

We believe the future of development isn’t about choosing between “easy” and “powerful.” It’s about having both. DeployDeck is the first “teaser” — the engine room — of the ecosystem we are building at Obsidyne.

What’s Next?

I am currently “dogfooding” DeployDeck — using it to manage all my live projects.

I’ll be writing a series of technical deep-dives on how I built specific parts of this engine, specifically:

  • How to manage SSH keys programmatically across multiple GitHub accounts.

  • Automating Nginx configurations with Node.js.

If you are a developer, a founder, or just someone tired of manual Nginx configs, follow along. The road to a better cloud starts here.

To see more of my work, check out ashvinpkumar.com. If you have questions about the architecture or want to discuss the roadmap, connect with me on LinkedIn.