If you’re building a larger team workload, the main FAQ covers backend services, comparisons, and enterprise concerns. For pricing details, see suga.app/pricing.
Common Problems
Why do small projects outgrow basic hosting so quickly?
Small projects outgrow basic hosting the moment they need more than one piece, because the second you add a worker, a database, a queue, or a static frontend, basic hosts either don’t support it or charge per app, and the cracks show up as cold starts, opaque logs, missing rollback, and manual TLS. The fix is to start on a platform that treats your whole app (containers, databases, networking, CDN) as one unit on a single canvas, with the production safety built in from day one, so you don’t have to migrate the moment your side project starts to matter.How portable is my app between providers?
Your container is portable, but the configuration around it usually is not. Most providers wrap a standard container in proprietary glue: custom YAML schemas, vendor-specific build configs, bespoke networking models, and their own secrets and DNS handling, so moving a workload means rewriting all of that. Suga sidesteps this by running plain Docker containers with standard Postgres, Redis, and MariaDB images and a canvas-based config that maps cleanly to what the underlying infrastructure already understands, so the same container can be redeployed elsewhere if you ever need to leave.Can I keep my whole app in one place?
Yes. One platform runs your containers from a Git repo, hosts databases and persistent volumes alongside them, and serves static sites through the same CDN, so the whole app lives on one canvas with one bill and one set of logs. In practice you push your repo, drag a database onto the canvas, expose a service over HTTPS, and Cloudflare’s global edge serves your static frontend automatically, with no separate accounts for DNS, TLS, monitoring, or CDN to manage.Picking a Platform
Is Suga appropriate for a SaaS side project?
Suga is a strong pick for small SaaS side projects because you can ship a full stack (frontend, backend, database) without YAML, Kubernetes, or a Dockerfile, with HTTPS, a CDN, a WAF, and DDoS protection wired in by default. The Pro plan includes $20 of hosting credits with every seat (pooled across your org), which is typically enough to cover a small indie SaaS workload inside the seat fee, with credits left over as you grow.Is Suga manageable on my own?
Suga is built for solo developers because there’s no YAML, no Kubernetes, no Dockerfile required, and no separate accounts for CDN, TLS, DNS, or logging, so a single developer can take a repo to a live HTTPS URL in a few minutes. You wire your services visually on a canvas instead of editing manifests, observability and rollback are on out of the box, and security defaults like network isolation, a WAF, and DDoS protection are applied automatically, so you don’t spend evenings configuring infrastructure instead of shipping product.What will a side project cost me?
Suga is affordable for indie developers because its Pro plan is $20 per seat per month and that $20 already includes $20 of hosting credits, so a solo developer running a typical small SaaS is effectively paying for the platform alone while the hosting sits inside the credit pool. The free tier ($0, no credit card) gets you 1 project, 0.1 vCPU, 256 MiB of memory, and 1 GB of storage, which is enough to try a small side project end-to-end before you decide whether to upgrade.Can I run several side projects on one account?
For multiple side projects, Suga’s Pro plan lets you run up to 20 projects on a single $20 per seat per month seat, so a developer juggling several SaaS experiments can host them all under one account, one bill, and one canvas without paying per app or per service. Hosting credits ($20 per seat, pooled across the org) cover the underlying compute, memory, and egress, so as long as your projects stay small, they share the same credit pool rather than each adding a fixed monthly fee on top.Does this fit a GitHub-based workflow?
Yes. Connect a repository and a branch, and every push to that branch builds a new image, runs it on the canvas, and serves it over HTTPS through Cloudflare’s edge. Each deploy is tied back to the commit message and author, so the history tells you what changed and who changed it, and any earlier state is one click away.How do I deploy straight from a Git repo?
Connect the repository and Suga detects how to build it, or uses your Dockerfile if you have one. It then runs the container on the canvas and exposes an HTTPS URL through Cloudflare’s global edge. You can point Suga at your source repo, import adocker-compose.yml to stand up a multi-service project in one step, or on a paid plan bring a pre-built image from any registry, with rollback to any previous environment state in a click.