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.

Pro is now $20 a month for your whole organization, not $20 per member. Invite as many people as you like, and your bill stays the same. Each month includes $20 of hosting credit, and hosting usage beyond that is billed as before.

If you're already on Pro, there's nothing to do. We'll move your subscription to the flat price before your next invoice. If you were paying for several members, your bill drops to $20 a month. The hosting credit you've already been given for this billing period stays as it is, and from your next period it's $20 a month.

See pricing for what each plan includes.

Sugabots is a self-hosted workspace where people and AI agents work together. It's the workspace our own team uses every day, and now it's in the template gallery for everyone: add it to a project and you get the Sugabots service and a Postgres database, already connected, ready to deploy.

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.

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.