What we shipped.

We've updated the flow for new projects so there's more direction on what you can do. We used to just put you on an empty canvas, but now there's a proper `/new` page that asks where you want to start before it goes off and creates anything. There are three new options:

• Import a GitHub repo, where you pick a repo and configure the build before deploying.
• Start from a template, and once you pick one and fill in any env vars it needs, you end up with a project that's already wired up.
• Start with an empty project, which is the same path it always was for getting to a blank canvas.

This is all available from an unauthenticated state, so you can start adding "Deploy to Suga" buttons to all your project READMEs.

If you tried to import a repo you'd just pushed commits to, you might have seen it show up as "empty" and refuse to import, leaving you stuck with no obvious way forward. Fixed now.

Worth sharing the lesson: the GitHub API exposes a `size` field on each repo, and `size === 0` is a tempting shortcut for detecting empty ones. It isn't reliable. That field is updated by a background job on GitHub's side that can lag by up to an hour, so a repo you just pushed to can still report zero size well after the fact. We now detect empties at the branch-fetch stage instead: no branches, no commits, nothing to import. Repos with actual content sail through, regardless of what `size` claims.

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.

• 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