The case
for Suga.
Three common objections to switching, answered directly.
You should not need to know what a VPC is to ship a side project.
You should not need a DevOps hire before your first customer.
You should not be shipping infrastructure when you could be shipping features.
You should not get a cloud bill that eats a month of runway.
“What we have works fine right now”
Modern PaaS products work well for certain app types. If you’re deploying a frontend with serverless endpoints, a single container with a managed database, or a short-lived job, most platforms handle those cleanly and the developer experience is good.
Suga is built for the cases where you want more control than the platform gives: self-hosted databases and caches, multi-service apps where the services are designed together rather than wired up through environment variables, environments that can be forked and thrown away for testing, and service types the platform doesn’t support natively.
If any of those would change how day-to-day work feels, that’s a reason to look. You don’t need to be blocked before you think about a switch.
“Moving apps sounds like a lot of work”
For most apps, Suga can deploy straight from your code. Point it at a repository, and Suga detects your language, framework, and dependencies. From there, it builds a working deploy with no extra config. If you’d rather bring a Docker image or a docker-compose file, those work too.
You also don’t have to move everything at once. Start with one service, keep your existing platform for the rest, and cut over when you’re ready. Deploys are zero-downtime, and environments can be forked or deleted, so trying Suga doesn’t commit you to anything.
“What if we hit a wall again?”
The usual walls on a PaaS are capability, not scale: a service type the platform doesn’t support, a database you can’t configure, a runtime the platform doesn’t accept, or a feature gated to a higher tier.
Suga lets you add those things to your project instead of outgrowing the platform. Custom services, self-hosted databases and caches, and non-standard runtimes all deploy directly on Suga.
Frequently asked questions.
Does Suga have proprietary parts I'd need to rewrite?+
No. Your app runs as a standard container. You don't write Suga-specific code, and your framework and database choices stay unchanged. If you ever leave, your app continues to run elsewhere without rewriting.
Is Suga a fit for solo developers and small teams?+
Yes. Suga Free covers a side project or an evaluation with no credit card required. Pro is designed for small teams building production apps, with unlimited projects and environments, environment forking, and pooled hosting credits.
How predictable is pricing as we grow?+
Pro is $20/seat/month and includes $20/seat/month of hosting credits. Credits pool across your team, and any overages are billed at the same published per-second rates for compute, memory, storage, and network. The same rates apply whether you're running one service or many.
Deploy something in the next 3 minutes.
Free tier, no credit card, just bring your repo.