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.

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.

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:

Until now, logs were real-time only. You could read them whilst the service was running but as soon as it was replaced during a deployment or restart, the previous logs were no longer accessible.

Logs are now retained, and there are two new places to work with them: a dedicated Logs explorer for each environment, and a refreshed logs tab in the service panel on the canvas.

The new explorer is available from the sidebar. It has a bunch of new features:

• Search by keyword across all your services, and filter by service and level (info, warn, error, debug).
• A volume histogram above the stream, stacked by level, so a jump in errors is easy to spot.
• Time ranges from 5 minutes to 14 days, preset or custom, with longer history on paid plans.
• Click any line for a detail panel: the full message, parsed fields, stack trace, and a permalink you can send so a teammate lands on the same entry.
• Live mode to watch entries stream in, or page back through a fixed window.
• Copy the lines on screen, or export the filtered set to CSV or JSON.

The logs tab on a service got the same treatment. Filter by log level inline and open the full explorer with that service already selected when you need more than a quick look. The UTC/local toggle, replica toggle, and follow/tail are all still there for quick debugging.

If a spike shows up in your per-replica metrics, you can now jump straight to the logs to find out what caused it.

Some frameworks bake env vars into the output at build time rather than reading them at runtime. Vite is the obvious example: anything prefixed `VITE_` gets inlined into the bundle when `vite build` runs. Until now Suga only supported runtime env vars, so frameworks that needed values during the build couldn't see them.

You can now set build-time env vars on any service, available for both auto-detect and Dockerfile builds. Custom build and start commands are also configurable for auto-detect, so you can override what Suga's framework detection picked if it didn't match what your project actually does.

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

Browse and deploy from a curated library of service templates with the new discovery UI. Templates cover common service types: web servers, data stores, workers, and more. Each template comes with pre-configured settings, environment variables, port mappings, and sensible resource defaults.

How it works#

When adding a new service to the canvas, you can now browse templates by category instead of starting from a blank configuration. Select a template, customize the settings if needed, and deploy. Variable references between services are wired up automatically based on the template definition.

Templates are designed to get you from zero to deployed as fast as possible, especially for common patterns like "web server + database + cache" that most projects need.

When creating a new environment, you can now fork variables from an existing one. Instead of re-entering every variable from scratch, select a source environment and its variables will be carried over.

A review step shows exactly which variables will be copied before anything is applied, so you can adjust values (like swapping production URLs for staging ones) before confirming. This is especially useful when spinning up preview or staging environments that share most of their configuration with production.

Environment variable references are now checked for circular dependencies. If service A references a variable from service B, which references one from service A, you'll see a clear warning on the canvas before deploying. Circular edges are rendered with a distinct style so they're easy to spot.

Circular references cause infinite resolution loops at deploy time, which previously resulted in confusing deployment failures. Now these are caught before you deploy.

Services will now automatically rebuild and update when you `git push` to your repository.

What is Keel#

Keel is a Kubernetes operator that watches for new container image tags and triggers rolling updates automatically. It runs inside your cluster and listens for webhook notifications from container registries (Docker Hub, GitHub Container Registry, etc.).

When a new image tag is published, Keel receives the webhook, matches it against your deployment's image policy, and initiates a rolling update. No CI/CD pipeline changes needed.

How it works in Suga#

When you deploy a service through Suga, we configure Keel's image update policy for that deployment. Push a new tag to your registry, and Keel handles the rest: it detects the new tag, updates the deployment spec, and Kubernetes rolls out the new pods.

This is particularly useful for teams that build images in external CI systems (GitHub Actions, CircleCI, etc.) and want deployments to update automatically without triggering a full redeploy through the Suga dashboard.