How We Cut Our Google Cloud Bill by 60% with Clouddley

When we first launched, we went all in on Google Cloud’s managed services — Cloud Run, Cloud SQL, Memorystore, Cloud Tasks, and Cloud Monitoring. It felt like magic at first. But soon, that magic came with a hefty bill: $4,000+ per month mostly from idle workloads, overprovisioned services, and pricing models optimised for Google’s bottom line, not ours. Month after month, costs crept up. So we asked a simple question:

“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: On paper, we were paying for lots of infrastructure. In reality, most of our workloads were predictable and steady, which meant we were paying a premium for features we rarely used.

​

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 best part? Clouddley gives us all that for free — no markup, no monthly license, just full access to our own Google Cloud account.

​

The migration journey

We didn’t jump in blindly. We built a migration plan in three phases: 1. Audit and identify
We 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%.

2. Pilot migration
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)

​

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.

The cloud is about choice. Sometimes that means choosing convenience, other times it means choosing control. For us, making that choice, workload by workload, unlocked massive savings and made our business more resilient.