Cloudgate
Start free trial
MenuClose

Let your AI agent deploy, with guard rails

Cloudgate gives Claude Code, Cursor or any MCP client its own member account: a role, a grant to the Services it may touch, and its own keys. It deploys, opens previews and reads logs and health. Every call lands in the audit log and secrets never reach it.

Start free trialSee the guard rails

What is an Agent in Cloudgate?

An Agent is a member of your Organization that is not a person. Your AI tool acts as it, so what the tool can reach is decided in Cloudgate, not in a prompt.

Its own role
Reader to look, Operator to deploy and run. Never more than the role allows, whatever the agent is asked.
Its own grant
The Projects, Environments and Services it may reach. A staging grant keeps it out of production.
Its own keys
Agent keys, shown once, that you can let expire or revoke without touching anyone else's access.
It outlives its maker
The Agent belongs to the Organization. When the person who made it leaves, the agent keeps working.

How does an AI agent connect to Cloudgate?

Over MCP. The endpoint is your console's address followed by /mcp, and the agent key goes in the Authorization header as a bearer token. That is the whole of the setup: no OAuth flow, no plugin to install on the Server.

Create the Agent in Settings, Agents. The console's Connect panel then shows the configuration for each MCP client it supports, ready to paste into Claude Code, Cursor or another client.

On the Hosted instance the console is cloudgate.octabyte.app. On a self-hosted Cloudgate install it is your own address.

HTTP request to the MCP endpoint
# What every MCP call carries
POST https://cloudgate.octabyte.app/mcp
Authorization: Bearer <agent key>
Content-Type: application/json

What does an agent's deploy look like?

The agent queues a build, follows it, reads the log and checks health before it reports back. The tool names below are the real ones. A retried deploy joins the queued build, and the stored database address comes back masked.

MCP client session, connected to Cloudgate
# An illustrative session. Project, Service and ids are examples.

you    The checkout page fails on an empty cart. The fix is
       merged. Ship it to staging and tell me if it is healthy.

agent  deploy_service
       { "serviceType": "application", "serviceId": "storefront" }
result { "deploymentId": "dep_7f2c", "coalesced": false,
         "message": "Deployment dep_7f2c is queued; poll list_deployments for it." }

# The client timed out and retried. Nothing new is queued.
agent  deploy_service
       { "serviceType": "application", "serviceId": "storefront" }
result { "deploymentId": "dep_7f2c", "coalesced": true }

agent  list_deployments
       { "serviceType": "application", "serviceId": "storefront" }
result [ { "deploymentId": "dep_7f2c", "status": "done" }, ... ]

agent  read_deployment_log
       { "deploymentId": "dep_7f2c", "lines": 100 }
result ...
         Installing dependencies
         DATABASE_URL=••••••
         Build finished, starting container
         ...

agent  get_service_health
       { "serviceType": "application", "serviceId": "storefront" }
result { "uptimeChecks": [ { "name": "checkout", "state": "up" } ],
         "openIncidents": [] }

agent  Deployed dep_7f2c to staging. The checkout uptime check
       is up and there are no open incidents.
An illustrative session between an MCP client and Cloudgate. Names and ids are examples.

Which tools can an agent call?

Four groups of tools, each checked against the Agent's role and grant on every call. There is no tool that runs a shell, applies a Plan or changes an alert.

Deploy and operate

Queue a build, start or stop a Service, or cancel a Deployment that should not finish.

  • deploy_service
  • start_service
  • stop_service
  • cancel_deployment
Previews

Open a requested preview of a branch, give it more time, rebuild it, or end it early.

  • create_preview
  • extend_preview
  • redeploy_preview
  • delete_preview
  • list_previews
  • get_preview
Plans and project config

Read the Project config, ask for a fresh Plan and read what it would change. Applying it stays with you.

  • get_project_config
  • request_plan
  • get_plan
Read health, logs and state

Follow a Deployment, read its log, and read the same health a person sees on the Health tab.

  • get_service_health
  • list_deployments
  • read_deployment_log
  • get_service
  • get_environment
  • list_projects
  • list_environments
  • list_domains

What stops an agent from doing damage?

The limits sit in Cloudgate, outside the model, so they hold whatever the agent is told or tells itself.

Every call is in the audit log
One row per call, with the tool and the outcome: succeeded, refused or failed. A refusal names its reason, such as permission, grant or rate limit.
Secrets are masked in every result
Stored secrets, from environment variables to database passwords, are replaced with •••••• in every answer, deployment logs included.
Rate limits per Agent
120 reads and 10 writes a minute, shared by all of an Agent's keys. Going over answers 429 with a Retry-After and spends nothing.
Deploying twice is safe
If a Deployment of the Service is still queued, a second deploy_service answers that one with coalesced: true and queues nothing.
Plans are requested, never applied
An agent can tell you what a change to the Project config would create, change or destroy. You review the Plan and apply it in the console.
Keys work in two places only
An agent key is accepted at the MCP endpoint and the Gateway. The REST API and the sign-in routes refuse it, and a personal key is refused at /mcp.

How does an agent test its own fix?

With a requested preview: a copy of the Application built from a branch, with its own address, that expires on its own. The agent never touches the Environment you ship from.

Pushing to a branch needs git access, which you give the AI tool at your git provider. An Agent's grant reaches Cloudgate's Projects, Environments and Services, never your repository.

  1. Push a fix to a branch

    The agent commits its change to a branch, with the git access you gave it.

  2. Open a preview of that branch

    create_preview builds the branch as its own preview, which expires by itself. extend_preview gives it more time.

  3. Read the log and health

    read_deployment_log and get_service_health show whether the build worked and the app answers.

  4. Report back, or try again

    It tells you what it found, or pushes another commit and calls redeploy_preview.

Can agents call AI models you host yourself?

Yes, through the Gateway. Deploy a model served by Ollama, vLLM or llama.cpp as a Service, on your own Server and GPUs. Every call reaches it through Cloudgate's Gateway, which speaks the OpenAI API, so any OpenAI client works by changing its base URL.

The caller uses the key of a caller Agent, a third role that may call the AI models it is granted and nothing else. The Gateway counts token spend per model and per calling Agent, so give each app or agent its own caller Agent: its spend shows on its own line, and you can suspend one caller without cutting off the rest.

How AI models and the Gateway work

.env of any OpenAI client
# Any OpenAI client, pointed at the Gateway
OPENAI_BASE_URL=https://<console>/ai/<AI model id>/v1
OPENAI_API_KEY=<caller Agent key>

Where to go next

Built your app with AI?
The plain-language path from a folder or a template to an address you can share, with your AI doing the deploying if you like.
Everything Cloudgate does
Ways in, where it runs, and what it looks after once your app is live: databases, backups, domains, monitoring and access.
Deploy from your terminal with the CLI
For scripts and CI, the cloudgate command uses a personal key, kept apart from your agents' keys.
Plans and prices
Agents are not counted. A plan counts Servers and Cloud Environments, with a 30-day free trial.

Questions about AI agents

Which AI tools can connect to Cloudgate?

Any MCP client, such as Claude Code or Cursor. It connects to your console address plus /mcp with an agent key as a bearer token. The console's Connect panel has the configuration for each supported client.

Can an agent see my secrets?

No stored secret reaches it as written. Every tool result, deployment logs included, passes through a mask that replaces stored secrets with ••••••. A value the build prints that Cloudgate never stored is not masked, so do not let builds print secrets.

What is the difference between the Reader and Operator roles?

A Reader reads: Services, Deployments, logs, health and plans, and it can ask for a Plan. An Operator can also deploy, start and stop Services, cancel Deployments and manage previews. Both are limited to the Projects, Environments and Services in their grant.

Can an agent apply infrastructure changes or turn off alerts?

No. An agent can ask for a Plan and read it, but no tool applies or dismisses one, whatever its role. It reads a Service's health and never adds, edits or removes an uptime check or an error-rate threshold, so it cannot silence an incident.

What happens if an agent gets stuck in a loop?

Each Agent has two budgets: 120 reads a minute and 10 writes a minute. A call over budget is answered with HTTP 429 and a Retry-After header, and writes a refused row in the audit log. Calling deploy_service twice while a build is queued joins that build instead of queuing another.

Can I use an agent key with the REST API or the CLI?

No. An agent key works only at the MCP endpoint and the Gateway. The REST API and the console's sign-in routes refuse it. Scripts and the CLI use a personal key instead.

Are Agents included in every plan?

Yes. Agents and the MCP endpoint are part of the Starter plan on the Hosted instance, and of every self-hosted install. See Cloudgate pricing for what each plan counts.

Give your agent a key, not your keys

Create an Agent, grant it one Environment, and connect your MCP client. Every plan starts with a 30-day free trial.

Start free trialDeploy a template