AI agent deployments

Last updated: 2026-05-05

tavin.cloud lets AI agents deploy and operate app repos through a hosted Model Context Protocol server and a one-time deploy-intent flow. An MCP client can create projects, deploy services, set environment variables, inspect deployment status, and tail logs without screen-scraping a dashboard or inheriting browser cookies.

What problem does this solve?

AI coding agents can write code, but shipping that code usually requires separate credentials, dashboards, shell commands, and platform-specific CLIs. tavin.cloud gives agents a narrow, auditable deployment interface, so the same agent that changes a repo can also operate the running service without receiving broad cloud authority.

What can an AI agent do?

Task	Agent workflow
Create infrastructure	Create a project and service with an exposed container port.
Deploy code	Trigger a Railpack or Dockerfile build from a GitHub repo and watch deployment status.
Configure runtime	Set, update, and unset environment variables for a service.
Debug production	Read recent deployments, tail logs, and inspect metrics.
Control access	Use OAuth, scoped Personal Access Tokens, revocable deploy-intent tokens, and audit logs.

How can an agent discover the deploy flow?

tavin.cloud publishes machine-readable context for agents that start from the public site:

https://tavin.cloud/llms.txt — compact product and docs map.
https://tavin.cloud/llms-full.txt — full docs and comparison context.
https://tavin.cloud/.well-known/agent-skills/index.json — agent skill discovery index.
https://tavin.cloud/.well-known/agent-skills/tavin-cloud/SKILL.md — exact agent playbook for Tavin Cloud MCP operations.
https://tavin.cloud/.well-known/mcp/server-card.json — MCP server card.

The skill is written for prompts like “Use the tavin-cloud skill + MCP to deploy this repo. Start: https://tavin.cloud/llms.txt”. It tells the agent to inspect the GitHub remote, branch, detected build plan, optional Dockerfile path, exposed port, pushed commit state, and required environment variables before calling deployment tools.

What if the agent has no tavin.cloud credentials?

For a public GitHub repo, the agent can create a one-time deploy intent before OAuth or PAT setup:

POST https://api.tavin.cloud/api/v1/agent/deploy-intents with repoFullName, plus inferred branch, projectName, serviceName, buildContextPath, dockerfilePath, and exposedPort when known.
Send the returned approvalUrl to the user.
Keep the returned agentToken only for this task. It starts with tad_ and can only read the status for this one deploy intent.
After the user approves in the browser, poll GET /api/v1/agent/deploy-intents/{intentId} with Authorization: Bearer tad_....

The browser approval requires a signed-in, email-verified tavin.cloud user. Approval creates the project and service, clones the public GitHub repo, and starts the deployment. Private repos still use the OAuth/PAT-backed MCP flow so tavin.cloud can use the user’s GitHub connection.

The point of this flow is permission shape: the agent can start the request and watch status, but the user approves the infrastructure action in the browser.

What should an agent call?

For a first deploy from a GitHub repo, the preferred tool is init_from_repo.

The agent confirms identity with whoami.
It calls init_from_repo with projectName, repoFullName, branch, and optional serviceName, exposedPort, and dockerfilePath.
If the tool returns a deploymentId, the agent calls wait_for_deployment.
If the deployment fails, the agent reads get_deployment_build_logs, fixes the repo, pushes the branch, and calls deploy_project_source again.
If the tool returns githubConnected=false, the user connects GitHub from the dashboard, installs or configures the tavin-cloud GitHub App at github.com/apps/tavin-cloud/installations/new, grants it access to the repo, then the agent calls init_from_repo again with resumeServiceId set to the returned serviceId. If the app is already installed, the user can adjust repository access from GitHub App settings. The agent should not use separate connect_repo and deploy_project_source calls for this retry path.

The GitHub MCP path deploys code tavin.cloud can clone. If the user’s desired changes are only local, the agent should commit and push them or ask which branch to deploy before starting.

How does authentication work?

Interactive MCP clients can use OAuth 2.1 with Dynamic Client Registration: configure the MCP endpoint, approve once in the browser, and let the client store refreshable tokens. If the user does not have an account yet, the agent can register its OAuth client, ask which email to use, call the email_onboarding_endpoint from authorization-server metadata, and wait for the user to confirm the emailed link. Confirmation signs the browser in, relaunches consent, and redirects to the agent’s localhost callback with an authorization code. Headless agents and CI can use a tavin.cloud Personal Access Token. Each token is tied to a user, can be scoped, and can be revoked. The MCP endpoint rejects browser cookies by design, so an agent uses explicit Bearer credentials instead of silently reusing a dashboard session.

Why not just give the agent your platform API key?

Many deployment platforms are adding MCP and agent features. That is useful, but it does not automatically make production access safe. The safer default is to make the agent’s authority easy to understand:

What credential is the agent using?
Which tools can it call?
Can the user approve a deploy before it starts?
Can the credential be revoked without touching the user’s browser session?
Is every action auditable after the fact?

tavin.cloud is built around those questions. MCP is the transport; scoped deployment is the product boundary.

OAuth-capable clients can start with only the endpoint:

{
  "mcpServers": {
    "tavin-cloud": { "type": "http", "url": "https://api.tavin.cloud/api/v1/mcp" }
  }
}

Headless clients can pass a PAT explicitly:

{
  "mcpServers": {
    "tavin-cloud": {
      "type": "http",
      "url": "https://api.tavin.cloud/api/v1/mcp",
      "headers": { "Authorization": "Bearer tvn_..." }
    }
  }
}

When should you use this?

Use tavin.cloud agent deployments when you want Claude, Cursor, or another MCP-speaking tool to ship a backend, worker, daemon, or agent-built app as a normal container. It is a good fit for teams that want the deploy contract to stay close to the code review loop.

When should you wait?

Do not treat tavin.cloud as a mature global multi-region platform yet. If your app depends on WebSocket-heavy public routing, first-party managed databases, strict high availability, or production-proven enterprise controls, validate the current preview limits before moving critical workloads.