The latest updates, improvements, and fixes to Suga.
Until now, logs were real-time only. You could read them whilst the service was running but as soon as it was replaced during a deployment or restart, the previous logs were no longer accessible.
Logs are now retained, and there are two new places to work with them: a dedicated Logs explorer for each environment, and a refreshed logs tab in the service panel on the canvas.
The new explorer is available from the sidebar. It has a bunch of new features:
The logs tab on a service got the same treatment. Filter by log level inline and open the full explorer with that service already selected when you need more than a quick look. The UTC/local toggle, replica toggle, and follow/tail are all still there for quick debugging.
If a spike shows up in your per-replica metrics, you can now jump straight to the logs to find out what caused it.
Some frameworks bake env vars into the output at build time rather than reading them at runtime. Vite is the obvious example: anything prefixed VITE_ gets inlined into the bundle when vite build runs. Until now Suga only supported runtime env vars, so frameworks that needed values during the build couldn't see them.
You can now set build-time env vars on any service, available for both auto-detect and Dockerfile builds. Custom build and start commands are also configurable for auto-detect, so you can override what Suga's framework detection picked if it didn't match what your project actually does.
It has always been possible to get public domains for Suga services, but now you can use a custom domain for your Suga services. Map your custom domain to any service on Suga, whether it's a root domain (example.com) or a subdomain (app.example.com) Suga will handle:
Once your DNS records are in place, Suga verifies ownership automatically and provisions an SSL certificate. You can track verification and SSL status directly in the dashboard, no manual steps required after the initial DNS setup.
See the full documentation: https://docs.suga.app/reference/custom-domains
Browse and deploy from a curated library of service templates with the new discovery UI. Templates cover common service types: web servers, data stores, workers, and more. Each template comes with pre-configured settings, environment variables, port mappings, and sensible resource defaults.
When adding a new service to the canvas, you can now browse templates by category instead of starting from a blank configuration. Select a template, customize the settings if needed, and deploy. Variable references between services are wired up automatically based on the template definition.
Templates are designed to get you from zero to deployed as fast as possible, especially for common patterns like "web server + database + cache" that most projects need.
When creating a new environment, you can now fork variables from an existing one. Instead of re-entering every variable from scratch, select a source environment and its variables will be carried over.
A review step shows exactly which variables will be copied before anything is applied, so you can adjust values (like swapping production URLs for staging ones) before confirming. This is especially useful when spinning up preview or staging environments that share most of their configuration with production.
Environment variable references are now checked for circular dependencies. If service A references a variable from service B, which references one from service A, you'll see a clear warning on the canvas before deploying. Circular edges are rendered with a distinct style so they're easy to spot.
Circular references cause infinite resolution loops at deploy time, which previously resulted in confusing deployment failures. Now these are caught before you deploy.
Services will now automatically rebuild and update when you git push to your repository.
Keel is a Kubernetes operator that watches for new container image tags and triggers rolling updates automatically. It runs inside your cluster and listens for webhook notifications from container registries (Docker Hub, GitHub Container Registry, etc.).
When a new image tag is published, Keel receives the webhook, matches it against your deployment's image policy, and initiates a rolling update. No CI/CD pipeline changes needed.
When you deploy a service through Suga, we configure Keel's image update policy for that deployment. Push a new tag to your registry, and Keel handles the rest: it detects the new tag, updates the deployment spec, and Kubernetes rolls out the new pods.
This is particularly useful for teams that build images in external CI systems (GitHub Actions, CircleCI, etc.) and want deployments to update automatically without triggering a full redeploy through the Suga dashboard.
Connect your GitHub repositories directly to Suga for source-linked builds.
The dashboard now shows org-level resource limits and enforces CPU-to-memory ratios per tier. A banner in the changes panel warns you when you're approaching limits before you deploy.
Suga now tracks infrastructure costs per service and supports a credit-based billing model. See what each service costs in terms of compute and storage, and apply credits to offset usage.