Why I stopped waiting on the tech lead for deployments
Every dev deploy at our company went through one person checking servers by hand for free capacity. I found Coolify on a Reddit thread, standardized us on Docker Compose, and cut setup from a day and a half to about two hours. That was the first piece of taking over devops and deployment for the whole company. It now runs 200+ containers across 8+ servers, including my own.
Before Coolify, every dev deploy at our company went through one person: our tech lead. He’d check a handful of servers for one with spare CPU and RAM, SSH in, clone the repo, wire up a database if the project needed one (or create one if it didn’t exist yet), find a free port, point the reverse proxy at it, and assign a domain. By hand. Every project, every time.
That cost more than his afternoon. SSH keys to the shared servers went out to whichever developer happened to be on a project that week, and nobody tracked who still had access to what. Deploy steps differed from project to project, so they lived in someone’s memory instead of a doc. A new dev environment took about a day and a half to spin up, on average. And more than once, one compromised app took the entire shared server down with it, because nothing kept it separate from its neighbors.
So what actually fixed it?
Finding it on Reddit
I found Coolify by accident, on a Reddit thread about ways to simplify server management. The pitch sounded too clean: free, self-hosted, PaaS-style deploys, push-to-deploy, automatic Docker builds, one dashboard, all on our own servers.
I’d used enough “free” tools to expect a catch, usually a missing feature or just something barely held together with tape. I installed it on a spare box expecting to find the hole within an hour. I didn’t. Every app got its own container and its own environment, all managed from one dashboard, with no one else’s half-finished Kubernetes setup to reverse-engineer.
What kept me there was the team behind it, especially Andras Bacsai. Their philosophy and how seriously they take feedback and suggestions won me over, and the team ships fast without sacrificing quality or accountability. I’ve become something of a fan.
Standardizing the company on it
Standardizing on Coolify is what put me in charge of devops and deployment for the whole company. This post covers that one piece; the full shift, FOSS migration and all, is its own story.
Fixing the actual problem meant one rule: every application deploys as a Docker Compose stack, full stop. A developer writes the compose file in the project repo, and that’s the entire deploy contract. I set up Coolify’s GitHub App integration for our org, so it pulls from GitHub and deploys the stack directly. Push to a branch, and a webhook tells Coolify to redeploy automatically. Nobody needs an SSH key to the server anymore.
Coolify also owns the reverse-proxy networking end to end. The server doesn’t need any publicly exposed ports beyond 80 and 443 anymore. I map a domain to a container’s internal port inside Coolify’s UI, and it just works.
It also solved the blast-radius problem. Each app runs in its own container, so one broken or compromised app can’t take its neighbors down with it, even on a server they share.
Setup time for a new project dropped from a day and a half to around two hours.
Where it sits today
That was the origin. It’s grown well past that since.
| Then | Now | |
|---|---|---|
| Deploy method | git pull + npm start, by hand | Push to deploy, containerized |
| Isolation | None: shared ports, shared processes | One container per app |
| Servers managed | 1 at a time, manually | 8+, one dashboard |
| Containers running | 0 | 200+ |
| What breaks a neighbor | Almost anything | Nothing |
Most of what runs on it now isn’t the original dev environments it was built to fix. It’s become the backbone of the whole delivery function, and my own server runs on the same system: a smaller slice, same trust.
What I’d tell someone in the same spot
If deploys at your company still run through one person’s head, that’s not a staffing problem, it’s a process that never got written down. Standardizing on containers fixes it whether you have three projects or thirty.
Migrate incrementally. We moved projects over one at a time, lowest-stakes first, and let each one sit for a couple of weeks before trusting it with anything that mattered.
You don’t need outside clients to justify doing this properly. Your own team’s dev environments are worth the two hours it now takes.
I’m still on it, still adding servers, and I haven’t had a reason to look elsewhere since that Reddit thread.
