Why moving from public cloud to self-hosted PaaS saved costs and time

After eighteen months of quiet bill inflation, a growing SaaS vendor faced two uncomfortable truths: their cloud costs had tripled without adding features or customers, and each new tenant required a custom, hand-tailored setup that drained their platform team’s time. The solution wasn’t more tools—it was rebuilding the foundation beneath them.

Rising costs and rigid workflows forced change

The client’s monthly cloud statement had become a wall of line items no one on the leadership team read in full. NAT gateway traffic, cross-AZ data egress, and idle managed-service buffers added up to a bill that grew faster than revenue. Meanwhile, onboarding a new customer meant provisioning a custom VPC, a dedicated database, and a bespoke set of IAM roles—each change rippling through four-hour platform tickets.

Public cloud is a poor fit when your workload is predictable, multi-tenant by design, and cost-sensitive—yet still paying for elasticity you don’t use.

The team reached a clear conclusion: staying on the public cloud was draining both budget and morale. The question wasn’t whether to move, but how to rebuild without repeating the same operational debt.

A private PaaS built for multi-tenant efficiency

The new infrastructure emerged as a Platform-as-a-Service running on private virtual dedicated servers under full team control. The architecture centered on a single control plane that provisions tenants, deploys code, and orchestrates upgrades. Under the hood:

• - Shared-nothing isolation: each customer receives a dedicated Kubernetes namespace, database schema, and observability context—while nodes remain shared for cost efficiency.
• - Centralized identity: Keycloak handles authentication and policy, so access rules stay consistent across tenant sizes.
• - Self-service onboarding: new customers select their stack through an internal portal, cutting setup from days to a ten-minute form.
• - Hardened access: control-plane endpoints are reachable only via a VPN-gated jump host, eliminating public-internet exposure.

The design mirrors approaches used by Render, Fly.io, and Heroku—scaled to fit a single organization’s needs and operated by the team that uses it every day.

Measurable gains after three months

Once live, the platform delivered concrete improvements:

• - Costs fell below the old cloud baseline within two months and continued to decline, though the exact percentage isn’t disclosed publicly.
• - Customer onboarding dropped from days to ten minutes, shifting from multi-team coordination to a simple internal form.
• - Observability consolidated into a single Grafana stack, a single Loki instance, and a single Tempo backend—every environment visible from one screen.
• - Attack surface shrank to zero public-facing dashboards, eliminating SSO backlog and reducing exposure to external threats.
• - Vendor lock-in vanished: Helm charts and infrastructure-as-code can run on any VDS API, enabling future multi-cloud portability.

These results don’t make for flashy product pages, but they do appear in finance reports and team mood surveys.

The lasting lesson: build the foundation right

Too many digital transformations focus on adding new dashboards or AI widgets while neglecting the 90% beneath them. A strong foundation isn’t just about today’s budget—it’s about staying secure three years from now, deployable by any team member, and sustainable on whatever budget remains in 2028.

Most companies under-invest in infrastructure until it breaks—at which point the repair bill far exceeds the cost of building it correctly on day one. This project proves that investing early in a self-hosted PaaS can pay dividends in cost, velocity, and peace of mind.

Next steps for teams on the fence

This migration isn’t right for every workload. Consider self-hosting only if you can staff the ongoing operations, your traffic patterns don’t require cloud-scale elasticity, and you’re willing to trade off-the-shelf support for long-term control.

The real work starts after the migration—continuous tuning, security patching, and capacity planning. If you’re ready to take ownership of your foundation, the time to start is now.