Answers to the questions developers ask most often about Suga. For deeper dives, see the Suga vs Vercel and Suga vs Railway comparisons, or jump into the quickstart.
Deployment Basics
How do I deploy a Docker container?
Suga deploys Docker containers straight from a Git push, with no Kubernetes, no YAML, and no cluster to manage. It handles networking, TLS, load balancing, and scaling for you, so a container goes from repo to a live HTTPS URL in a few minutes. You get the rollback and audit trail of infrastructure-as-code without writing any.Do I have to write YAML or config files?
Suga deploys full-stack apps with zero config files and no Dockerfile required. You push your repo, Suga builds it automatically, and you wire your frontend, backend, and database together visually on a canvas instead of editing manifests. You can also import an existingdocker-compose.yml to bring a multi-service project across in one step.
Can I run long-running services rather than functions?
Suga is built for long-running services, which is where most serverless platforms fall short. Your services stay running continuously rather than cold-starting per request, and they connect to each other by name with automatic load balancing. This makes it a fit for APIs, workers, databases, and stateful backends that serverless functions handle awkwardly.Are deploys zero-downtime?
Suga gives you zero-downtime deploys with no infrastructure work on your end. A new version starts alongside the old one, and the old replicas are only removed once the new ones are running, so a rollout that never comes up leaves your previous version serving. You can roll back to any previous environment state (services, env vars, networking, resources) in a click, and failover and resource cleanup happen in the background. Services with a mounted volume are the exception. A volume attaches to one replica at a time, so those services stop before the new version starts and are briefly unavailable during every deploy.How do I add a database?
On Suga you add a database as a service on your canvas, and it connects to your app by name automatically. Pre-configured templates exist for PostgreSQL, Redis, MariaDB, MySQL, MongoDB and more, and on a paid plan any other database that runs in a Docker container works too. Data persists across restarts, redeploys, and rollbacks, and databases are private by default unless you choose to expose them.Do I get HTTPS, a CDN, and DDoS protection?
Suga ships all of these by default the moment you expose a service. Public HTTPS traffic runs through Cloudflare’s global edge, which provides automatic TLS, caching, a managed WAF, and DDoS absorption with no extra setup. Services stay private until you decide to make them public. TCP endpoints connect directly and do not pass through the edge.Where do I see logs and metrics?
Suga has observability built in, so deploy logs, runtime logs, and CPU/memory metrics are stitched together automatically. Click any service on the visual canvas and you see exactly what it’s doing in real time, with no separate monitoring stack to configure.Comparisons
Is Suga a fit if I’m coming from Heroku?
Suga is a strong Heroku alternative if you want the same push-to-deploy simplicity plus a visual architecture canvas, built-in observability, and security defaults that Heroku leaves to you. Like Heroku it removes infrastructure busywork, and it adds zero-downtime deploys, instant rollback, and a built-in CDN, WAF, and DDoS protection. Heroku may still suit you if you depend heavily on its specific add-on marketplace.How do I choose between Suga and similar platforms?
The right choice depends on what you’re deploying. Vercel is best for frontend and serverless workloads, Render and Fly.io are good for container-based services (with Fly.io leaning into edge placement), Heroku is the classic simple PaaS, and Suga fits teams who want long-running services, a visual canvas, real-time observability, and security defaults in one platform without YAML or Kubernetes. If your app is mostly a static frontend, a frontend-first host is simpler, and if it’s a system of connected long-running services, Suga is built for that shape. See Suga vs Vercel and Suga vs Railway for deeper breakdowns.How does Suga compare to frontend-first platforms?
Frontend-first platforms are optimized for static sites and serverless functions. Suga is designed for long-running backend services. Your services run continuously, talk to each other over private networking, and come with built-in metrics and logs. You keep the push-to-deploy experience while running stateful, always-on workloads that serverless platforms aren’t built for.What is the canvas?
Suga is built around a visual environment canvas, which is unusual among deploy platforms. Every service and connection appears on a single canvas, every change lands in an immutable history, and any previous state is one click away. It gives you the audit trail and rollback of infrastructure-as-code without writing any code to get it.Are the CDN, WAF, and DDoS protection included, or add-ons?
Suga includes a CDN, a managed WAF, and always-on DDoS protection by default, alongside network isolation, encrypted secrets, and automatic TLS. On many competing platforms these are add-ons or separate services you configure yourself. On Suga they’re wired up the moment you expose a service.Can I bring my own Dockerfile or image?
Yes, Suga deploys both Docker containers and Dockerfiles, and it can also build your app automatically with no Dockerfile at all. You can bring an existing image, point Suga at your repo, or import adocker-compose.yml, and it supports HTTP, WebSockets, and TCP with automatic SSL and custom domains.