What's New.

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.

Suga now has an MCP server. Connect an agent like Claude Code or Cursor to your account and it can do most of what you'd do in the dashboard, from your editor.

Paste the server URL into your MCP client, approve the OAuth consent screen, and pick which orgs the agent can reach. From there it can:

• Build out an environment: containers, volumes, gateways, env vars, secret slots, custom domains, and scaling.
• Inspect a running environment: deploy status, logs and events, endpoints, and capacity.
• Make day-to-day changes: bump an image tag, rotate a secret, add a custom domain.

Changes land in your draft and come back as a deeplink. You review them in the dashboard and click Deploy yourself. Agents can't apply, can't delete a project or environment, and can't read a secret value back out. The connection uses your existing org role, so an agent can't do anything you couldn't.

This replaces the in-app code assistant, which we've retired.

You can look at the MCP documentation, or get started now.

Claude Code, from your terminal:

claude mcp add --transport http suga https://dashboard.suga.app/api/mcp

Cursor, in `~/.cursor/mcp.json` (global) or `.cursor/mcp.json` (per-project):

{
  "mcpServers": {
    "suga": {
      "url": "https://dashboard.suga.app/api/mcp"
    }
  }
}

Codex, in `~/.codex/config.toml`:

[mcp_servers.suga]
url = "https://dashboard.suga.app/api/mcp"

Then run `codex mcp login suga` to authenticate.

You can now include references to other values in your environment variables. An example of where you might need this is database connection strings, which may reference the host, username and password values from elsewhere in your environment.

To add a reference to an environment variable type `{{` in the value field. This opens a picker where you can select another value to reference, keep typing to filter. Once you make your selection, the reference drops in at your cursor:

postgres://dbuser:{{postgres.PASSWORD}}@{{postgres.SUGA_PRIVATE_HOSTNAME}}:5432/app

References are keyed on the target service's hostname and point at a variable on that service. That covers the variables you set, and the ones Suga sets for you, including the addresses a service can be reached on.

Values resolve at deploy time against the environment being deployed, and they resolve through each other, so a value can point at a variable that is itself a reference. We catch circular references before the deploy goes out.

Deployment history has been dropped from the plan limits. The free plan listed a cap of 10 deployments per environment. That's gone, nothing prunes your history on any plan, and every plan shows the 50 most recent deployments for an environment.

Deployment history is the audit trail for an environment, including what changed, who deployed it, what to roll back to. Getting value from environment history requires history, so we decided that's not something we want to limit.

Cloning an environment used to read from its last deployment rather than its current definition. If you cloned an environment that had never been deployed, the copy opened to an empty canvas, and the review step that lets you pick which values to carry over could be skipped entirely.

Cloning now reads the environment's current definition, the same one on the canvas. The copy matches the original whether or not it has been deployed, and the review step always appears, with sensitive values off by default.

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.

There's now a usage card next to your projects on the dashboard, so checking what's left of your plan doesn't mean opening a separate page.

It covers:

• Resource pools: CPU, memory, storage, and TCP proxies, each metered against your limit.
• Platform limits: members, projects, environments, and custom domains, shown as a count against their cap.
• Rows turn amber past 80% of a limit and red once you're over it, with a summary at the top of the card.

Click a resource row to expand a ranked list of the projects using the most of it, with a link through to each one.

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.