“What if we ran everything on VMs — but still on Google Cloud — and used Clouddley to automate it all?”That’s when we made the call: shift workloads from managed PaaS to our own VMs. It wasn’t an overnight decision, and it wasn’t risk-free. But it paid off: We did it. We cut our bill by over 60%.
What you’ll learn in this
- Why PaaS can become a financial trap at scale
- How we identified the workloads to move
- The cost breakdown before and after the migration
- The challenges we faced and how we solved them
- Lessons you can apply if you’re making a similar move
The wake-up call
We hit the tipping point during a review. Our finance team noticed that most of our operating expenses were going into cloud services. For a company still chasing profitability, that was very unsustainable.Here’s what our original setup looked like:
| Component | Service on Google Cloud | Monthly Cost |
|---|---|---|
| App Runtime | Cloud Run | $1,600 |
| Database (Postgres) | Cloud SQL | $1,200 |
| Redis Cache | Memorystore | $322 |
| Background Workers | Cloud Tasks | $400 |
| Logging & Monitoring | Cloud Ops Suite | $100 |
| Add-ons / Networking | Cloud NAT + Load Balancer | $500 |
| Total | $4,122 |
The turning point
Our CEO asked a simple question:“What would this cost if we just ran it on VMs?” I mean, we are building the next big thing for servers: backend infrastructure for compute. Why don’t we implement it internally?We modelled the numbers. The same workloads, if sized correctly and run on dedicated VMs with automation in place. That meant potential savings in figures too big to ignore. We migrated everything to Google Compute Engine VMs, but used Clouddley as our platform to manage:
- Provisioning
- Networking (DNS, TLS, Load Balancing)
- Observability (Logs, Metrics, Alerts)
- Backup & Failover
- Secrets & CI/CD
The migration journey
We didn’t jump in blindly. We built a migration plan in three phases: 1. Audit and identifyWe tagged and tracked workloads for 30 days. The result confirmed what we suspected:
- 70% of compute usage was flat and predictable.
- Less than 15% of workloads had spiky, unpredictable traffic.
- Databases were overprovisioned by at least 40%.
We started small, moving background workers and a staging environment to VMs. Within a month, we reduced the bill without service disruption. That gave us confidence to move production workloads, and we did. 3. Full rollout
Over three months, we migrated:
- App servers → VM pool behind a managed load balancer.
- Redis cache → self-managed on VMs.
- Worker queues → smaller VM fleet that scaled with demand.
The outcome
Now this is what the new setup looks like New Setup (Fully on VMs)| Component | Monthly Cost |
|---|---|
| App servers (GCE)x2VM | $650 |
| PostgreSQL DB (GCE) | $700 |
| Redis (GCE) | $250 |
| Workers (GCE) | $200 |
| Monitoring & Logs | Free |
| Total | $1,800 |
The results
- 60%+ cost reduction
- More predictable performance (no cold starts, full CPU control)
- Full visibility into workloads, disk, memory, and traffic
- No vendor lock-in — all infra runs in our own Google Cloud project
- Ability to scale compute up or down as needed — no PaaS limits
The bigger picture
Cutting 60% from our cloud bill wasn’t just about saving money. It gave us:- Financial headroom to invest in new product features.
- Operational control to fine-tune workloads for performance.
- Strategic flexibility to mix PaaS and VMs instead of being locked in.
Getting started with Clouddley?
A backend infrastructure for your own compute. Run apps, databases, brokers, and AI workloads on your VMs, bare metal, or VPS.
