What's New.

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 full docs here, 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.

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.

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.

Public TCP proxies are moving to paid plans. On the free tier you'll still see the option in the public networking config, but it now sits behind an upgrade prompt. For existing applications with TCP proxies, there is no migration to do. These will continue to work and won't be torn down. The change will only apply to creating new TCP proxies. Those on Pro and Enterprise plans are unaffected.

Public TCP proxies are a power-user capability: most legitimate free projects never reach for them, yet we were seeing them frequently for users who were running antagonistic workflows. Gating them to paid plans keeps the free tier focused on trying Suga out and lets us keep it generous for everyone using it as intended.

If you have a legitimate reason for trying out TCP proxies you can reach out to us at support@suga.app and we can arrange a trial.

You can now turn any Git repo into a one-click deploy. Drop a "Deploy on Suga" button in your README, and anyone who clicks it lands in Suga with your project ready to configure and deploy.

If your repo already has a compose file, that's all you need. Suga reads it, wires up the services, and asks for any variables before deploying. No extra config to maintain alongside your project.

It works from a signed-out state, so the button is genuinely one click for whoever finds your repo. It's an easy way to share a working template, hand someone a starting point, or let people try your project without walking them through a setup.

Adding one is two lines of markdown. Point the link at your repo and use our badge as the image:

[![Deploy with Suga](https://suga.app/badge.svg)](https://dashboard.suga.app/new/template?repo=your-org/your-repo)

Swap `your-org/your-repo` for your GitHub repo and you're done. A few options if you need them:

• If your compose file isn't on the default branch or at the repo root, add `&branch=` and `&path=` to the link.
• To point straight at a compose file anywhere, use `?compose=<url>` instead of `?repo=`.
• For READMEs with a dark background, swap the badge for `https://suga.app/badge-light.svg`.

This will render like this: