At some point, every developer who runs personal projects accumulates an awkward mix of infrastructure. A Rails app on Heroku from a few years back. A side service on a Digital Ocean droplet that someone set up manually and is now a mystery. A couple of Lambda functions because that seemed like a good idea at the time. Billing spread across three dashboards. No consistency.
That was my situation. It wasn’t a disaster: everything was running, but the overhead was real. Deploying a new project meant choosing a platform, configuring it from scratch, and mentally filing it away in the ever-growing map of “where is that thing running.”
I wanted one place that I controlled, where I could deploy anything with minimal ceremony and predictable monthly costs. I wanted CI/CD that worked out of the box. I wanted to not think about infrastructure until I had to.
That’s a very specific use case: personal projects, small client work, side experiments. It’s not the same as a team running a production SaaS. The right answer depends entirely on context.
Coolify is a self-hosted platform: you run it on your own VPS, and it gives you a Heroku-like interface for deploying Docker-based services. Connect a repo, point it at a Dockerfile or a buildpack, configure your environment variables, and it handles the rest: builds, deploys, reverse proxy, SSL certificates, process management.
I moved everything onto a single VPS running Coolify. The setup took a weekend. The ongoing maintenance is close to zero.
A few things that I use constantly:
emanuelpetre.dev.env files being manually synced between machines.There are real things that a managed cloud provider does better.
Scaling. If a project suddenly needs 10x the resources, a managed platform handles that gracefully. On a single VPS, you are constrained by the machine. For personal projects this has never been an issue, but it is a meaningful constraint for anything that could spike.
Managed services. AWS RDS, ElastiCache, CloudFront: these are genuinely good products. Running your own Postgres on a VPS means you’re responsible for backups, replication, and recovery. I handle this carefully, but the operational burden is mine.
Reliability guarantees. A major cloud provider has redundancy I cannot replicate on a single server. For personal projects, occasional downtime is acceptable. For anything with a real SLA, it is not.
Ecosystem integrations. If you are already running on AWS, Lambda, S3, and CloudFront, the integrations between those services are valuable. Moving off the platform means rebuilding some of those connections.
For the mix of personal projects and small services I run, a well-sized VPS costs around $20-40/month depending on requirements. The equivalent portfolio spread across Heroku, Vercel, and various AWS services was running me significantly more, not because any individual service was expensive, but because the fragmentation meant I was paying for minimums on several platforms simultaneously.
The consolidation also reduced cognitive overhead. I know where everything runs. I know how to deploy it. I know how to check its logs. That consistency has its own value.
This setup makes sense if you are an individual developer or a very small team, comfortable with Docker, running projects where occasional downtime is acceptable, and want to optimize for simplicity and cost over raw scalability.
It does not make sense if you are running a production service with real uptime requirements, if you need the integrations that come with a major cloud platform, or if your team does not have the ops knowledge to manage a VPS.
I still use AWS for specific things (S3 for storage, SES for email). I’m not ideologically opposed to cloud providers. I just stopped using them as the default answer to every deployment question.