Builds from a git repo now run end-to-end inside the builder itself. The clone and build-plan step used to run on a separate worker before handing off, which meant copying your repo across the wire twice. Now the builder fetches your code directly and goes straight into the build.
For most repos this lands up to 2x faster, with no action needed on your end.
If you noticed your build log freezing mid-build, that wasn't you. Fixed now, along with a couple of related quirks.
Service and volume nodes on the canvas have a new design with more useful information visible up front.

Handful of UI improvements:

Sometimes the connection between your browser and Suga's hosted infrastructure can drop, whether it's your internet going down or an outage on Suga's end. Previously, these issues could be confused with errors in your deployed resources. Now they're clearly identified as connection problems.
This was done along with an updated Suga status page for each part of the system.
Searching for GitHub repositories and branches in your build config now uses fuzzy matching. Partial names and minor typos will still surface the right results instead of showing an empty list.
When there's genuinely no match, the empty state now includes your search term so it's clear what was filtered: "No repositories found for 'docs'".
A round of fixes to how nodes behave on the deployment canvas:
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.