If you noticed your build log freezing mid-build, that wasn't you. Fixed now, along with a couple of related quirks.

• Logs will reliably stream live as the build runs.
• Logs consistently show up on completed builds too, not just in-progress ones.
• If your connection drops mid-build, it reconnects and picks up where it left off.

Service and volume nodes on the canvas have a new design with more useful information visible up front.

• An icon bar on each service node shows git/image source, mount path, and network status without opening config.
• Status is now split into live state (running, failed, deploying, warning) and change state (new, modified, deleted). Both are visible at the same time, so a running service with pending changes shows both.
• If volumes are detached from their parent service, they now reposition near the parent node. Resolving an issue that caused volume nodes to be moved off screen.

Handful of UI improvements:

• The "enable Suga domain" option was hard to find and didn't prefill the port. It's now a clickable card with a default port.
• We've improved the consistency of styling (borders, radius, etc.) for UI elements, such as inputs, selects, and autocompletes.
• Services no longer require a private port. Public ports are automatic, so leaving private ports empty is fine.
• Container errors in deployment logs now link to explanations, instead of just expanding the log line.

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.

• If sync disconnects, the canvas locks and shows a connection banner instead of stale or loading indicators.
• If workflow statuses can't be retrieved, they show "unknown" rather than errors that look like your service is broken.
• If real-time updates drop, a banner lets you know updates have paused.

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:

• Services no longer appear behind the config panel when added to the canvas. Centering now accounts for the side panel width.
• Adding a new service opens the config tab automatically. Switching between existing services preserves whichever tab you were on.
• Unmounting a volume no longer sends it off screen. Detached volumes now reposition next to their parent node.
• Undo after deleting a node restores it to its original position on the 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:

• DNS Verification Suga checks that it's registered and detects your DNS provider.
• SSL Certificates SSL is automatically managed, ensuring a secure connection without any setup from you.
• Traffic Routing Routes all traffic to your service automatically.

How it works#

1. Add a domain: Enter the domain you want to use.
2. Pick a port: Choose which port on your service the domain should route to.
3. Configure DNS: Copy and paste the DNS record information into your provider.

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.

Details#

• Available on Pro (up to 10 domains) and Enterprise plans.
• Each domain maps to a single service and port within an environment.
• Apex domains require a DNS provider that supports CNAME flattening (Cloudflare, Namecheap, etc.).

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.

How it works#

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.