What's New.

We've rebuilt every page of the app. It was built up a feature at a time, and it showed: pages laid out differently, controls that looked the same but behaved differently, and the same fact shown in different places. Now there's one layout, one set of components, and one place for each piece of information.

What's different:

• One layout everywhere. Every signed-in page shares the same top bar and sidebar, so switching between projects, environments and settings always works the same way.
• Canvas and deployment history, reworked to match, with clearer statuses.
• Billing that shows where you're heading. The billing page now forecasts your next invoice at your current rate of hosting usage, with your included credit taken off.
• Errors that tell you what to do. When something fails, the message says what went wrong and what to change, and an unexpected error comes with a reference ID you can send us.

If something you relied on has moved, or looks wrong, let us know on Discord or at support@suga.app.

When a build fails, the reason is in the build log, and until now an agent connected over the MCP server couldn't see it. A new `get_build_logs` tool returns a build's full log along with its status, error message and timings, so your agent can work out why a build failed and suggest the fix without you copying the log across.

Long logs come back a page at a time, and the tool only returns builds from organizations you've given the agent access to.

The projects page now also has a card with the MCP server URL, so connecting an agent doesn't mean digging through the docs first.

CPU and memory aren't independent on Suga. They're held to a ratio, so raising CPU raises the memory floor and lowering it drops the ceiling. Until now the only sign of that was the memory value moving by itself when you changed CPU, with only a block of text telling you why.

The sliders now shade the stretches of the scale you can't reach. Drag CPU down and the shaded bar on the memory slider grows from the top, shoving the memory thumb back into range. Hover a bar and it tells you what's blocking it and which way to move, whether that's the ratio or your plan's ceiling.

A running deploy used to say "Deployment running" and leave it there. If it was building from a repo, the build was where the time was actually going, which was previously unclear.

The banner now names what's building: "Building api" for one service, "Building 3 services" for more. It also now reads the status from a realtime builds endpoint, so it won't report a build before one starts. The build panel and associated build logs now live in the URL. These build URLs are now shareable, so you can provide the relevant build link to other members of your team.

Volumes have changed slightly as well. Rather than displaying the name on the canvas node, it will instead show the mount path. With this change we've also updated the auto generated mount change wording in the review step. Rather than just saying "changed mounts", it will instead read like this:

mounted /data on api
mount /data → /var/lib/pg on postgres
unmounted /cache from worker

Reordering mounts also stopped reporting a change that was never there.

A new environment opens to an empty canvas, with nothing on it to say what to do next. Two changes:

• A guide on the empty canvas. When an environment has no resources, a guide points at adding your first service. It doesn't block anything: you can still pan, zoom, and use the add button and right-click menu as normal.
• GitHub first in the add menu. Deploying a repo is the most common way to start, so it's now the first option. The menu is also flattened, so adding a service from GitHub or from a container image are both top-level choices rather than a submenu.

Opening a project used to put a loading overlay in front of the canvas while it fetched and drew itself. The canvas is now rendered on the server, so your services, functions, and connections are on screen when the page loads instead of after a spinner.

The projects page used to be a plain grid of names. Now each card gives you a quick sense of what's actually inside a project before you open it.

Every card surfaces:

• The most recently active environment and its status at a glance.
• A preview of that environment's resources: services, functions, databases, and volumes.
• Compact CPU and memory meters showing what's allocated against your limits.
• A footer with environment and resource counts and when the project was last updated.
• Recent deployment activity.

We've also added search and sorting, so finding the right project is quick once you've got a few of them. Sort by name, last activity, or when it was created.

The history panel has been rebuilt around the thing you actually scan for: what changed, and when.

At first glance you can see the status, who started the deployment, when the deployment happened, the commit message, and how many resources were created or destroyed. Expand to see the details.

Selecting a past deployment no longer snaps your canvas to it. You preview it and apply the historical state deliberately, with a separate button, so browsing history can't clobber unsaved work. You will also be able to see active deployments in this list.

We've also updated the flow of the apply, with commit messages now being required. To keep that from being a chore, you can generate a short summary of your changes as the default message. Now every entry in the history carries something meaningful even when you don't type one yourself.

Importing a compose file with a lot of shared configuration used to mean a lot of repeated typing. A stack like Supabase reuses the same values, such as a database password or a signing secret, across many services, and we were asking you to fill each one in every service that used it.

Two changes fix that:

• Shared variables are asked for once. When the same variable shows up across multiple services, we now set it up as an environment-level secret that each service references, instead of a separate copy per service. The import form groups these as shared, so you fill in a database password once rather than ten times.
• Variables inside connection strings are picked up. Values embedded in a larger string, like a password inside a `postgres://` URL, used to be missed entirely. They're now detected and surfaced alongside everything else.

The result is a much shorter form when you import a real-world stack, and fewer chances to fat-finger the same secret into a dozen boxes.

It wasn't always clear when your Suga URL was actually live. Adding a generated URL made the row in the dashboard look ready right away, even though the service still had to be redeployed before traffic flowed. Hitting a `*.suga.run` host that wasn't currently routed would land you on a generic gateway error, with nothing to say whether the route was wrong, the deploy had been torn down, or the platform was broken.

Both are sorted now. Custom domain rows show a clear pending state with a redeploy prompt right in the row, and unrouted `*.suga.run` hosts serve a branded Suga page that explains the hostname isn't routed yet.