An agent operates SaladCloud for you
Claude Code, Codex, Cursor, or a custom agent deploys, scales, monitors, and troubleshoots your container groups,
transcription jobs, or AI Gateway requests through the SaladCloud API. This page is for you.
A coding agent helps you build for SaladCloud
The agent writes your Dockerfile, your health probes, your reallocation handling. It needs to know how a container
behaves on this network. This page tells it where to look.
Your agent's model runs on SaladCloud
You want Aider, Cline, Goose, OpenClaw, or the Vercel AI SDK to use an LLM served by SaladCloud. That is the AI
Gateway integrations section, not this page.
Install the SaladCloud skills
SaladCloud publishes Agent Skills — task-specific instruction files in the openSKILL.md
format that Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Goose, and most other coding agents load on demand.
Each skill tells the agent which API operations to use for one job, what to read before writing, and when to stop and
ask you.
Point the skills CLI at the docs site and pick what you want:
https://docs.salad.com/.well-known/agent-skills/index.json, so the same command picks
up new and updated skills when you run it again. To see what is available without installing anything, open that index
or the Agent Operations section, which holds the runbooks the skills are built on.
Add the documentation MCP server
The documentation itself is an MCP server athttps://docs.salad.com/mcp. It needs
no authentication and gives the agent three tools: search the docs, browse them as a filesystem, and report a page that
is wrong or missing. Pair it with the skills so the agent can look up the page a skill points at instead of guessing.
--scope user puts the server in every project; drop it and Claude Code adds it to the current project only. Codex
accepts codex mcp add salad-docs --url https://docs.salad.com/mcp, which writes the same TOML block for you.
This server reads documentation only. It does not call the SaladCloud API on your behalf; for that, the agent uses your
API key directly, as described next.
Give the agent an API key — and understand what you are handing over
Every SaladCloud API call is authenticated with theSalad-Api-Key header. Read Using the API
first; the facts that matter for agents are these:
- The key is yours, not the organization’s. Each user has one API key, and it grants access to every organization, project, and container group that user can reach in the Portal. An agent holding your key can act everywhere you can. There is no read-only or single-organization key today.
- Scope the blast radius with a dedicated account. If your agent should only touch one organization, invite a separate member account to that organization and give the agent that account’s key. Rotating it later will not break your own tooling.
- Keep it in the environment, never in the prompt. Set
SALAD_API_KEYas a secret environment variable and let the agent read it from there. The skills and runbooks are written to use that variable and to never print its value. Do not paste the key into a chat, a repository, or anAGENTS.md. - Rotate with a grace period. When you change the key from the Portal’s API Access page you can keep the previous key valid for an hour, a day, or a week, so an agent mid-task does not fail the moment you rotate.
- Quota is your spend ceiling. Billing is by replica running time, and each organization has a replica quota across all container groups. That quota is the hard limit on how much an agent can spin up; set it deliberately before letting an agent scale things.
- AI Gateway is a different key. Salad AI Gateway uses an organization-specific
Bearer token (
SALAD_AI_GATEWAY_API_KEY), not your SaladCloud API key. The agent runbooks keep the two apart; make sure your environment does too.
What the agent should read
The Agent Operations section is written for the agent, not for you. It sets source precedence (a live API response beats the OpenAPI specification, which beats a runbook, which beats a tutorial), lists the actions that require your explicit go-ahead (stopping, deleting, scaling down, reallocating an instance, repeating anything billable), and defines retry, verification, and stop rules. The installed skills point into it; if you are writing your own agent, start there too. Three more things every agent can use:llms.txtat docs.salad.com/llms.txt indexes every page with a one-line description and opens with the agent instructions above.- Any page as Markdown. Append
.mdto a page URL (for examplehttps://docs.salad.com/reference/api-usage.md) to get clean Markdown instead of HTML. - OpenAPI specifications for the public API, IMDS, Transcription API, and Transcription Lite live in the
api-specsdirectory of this documentation’s repository. They are authoritative for paths, schemas, required fields, and enums.
Building for SaladCloud with a coding agent
A coding agent that has never deployed here will make the same mistakes a new engineer makes: assume the disk persists, assume the instance stays up, assume one replica is enough, forget IPv6, ship a 40 GB image. Thesalad-container-image
skill (installed with the command above) carries the rules; these are the pages it is built from:
- Before you deploy
— instances are interrupted without warning and reallocated automatically; cold starts are slow; build for
amd64. - IMDS — how a running container learns its own status and asks to be reallocated.
- Health probes — startup, liveness, and readiness, and what a misconfigured probe looks like from the outside.
- Networking — one port through the Container Gateway, IPv6 required inside the container.
- Troubleshooting — image size limits, pull failures, and the states a stuck instance sits in.
- Job queues — the worker contract for queue-autoscaled groups.