Deploy and Debug on Vertra Cloud with Your AI Agent

Once your agent is connected to the Vertra Cloud MCP server, you ask in plain language and it chains the tools for you. This page shows the requests that work best, which tools they run and which key scopes they need.

​

Deploy a project for the first time

Creating an application uploads a folder from your computer, so it needs the local server (Claude Code, Codex, Claude Desktop, Cursor and other clients that run npx @vertracloud/mcp). Start the agent in the project folder.

Deploy this folder to Vertra Cloud as a Node app called support-bot, with 512 MB, and wait until it’s online.

Creation is asynchronous: the app starts in building and becomes up or down. If it ends down, last_build_error says why and the agent can fix the code and try again. For later updates:

Deploy the current folder to support-bot with the message “fix login timeout”.

That runs deploy_app (apps:files), which keeps the release history so you can roll back.

​

Find out why an application went down

Why did orders-api go down? Read the last 300 log lines and the memory usage, and tell me the cause before changing anything.

Everything here is read-only, so a key with only apps:read is enough. Log lines reach the agent marked as untrusted content: a line printed by your app is read as data, never as an instruction. Asking for the cause before any change keeps the agent from restarting or redeploying on its own. The crash debugging guide explains the common causes. If the agent is running in the project folder, the next request closes the loop:

Fix the cause in the code, run the tests, and deploy to orders-api.

​

Create a database and connect it to an application

Create a 1 GB PostgreSQL called orders-db, set DB_HOST, DB_PORT and DB_USER in orders-api, and show me how the code should connect.

The connection string comes with a <password> placeholder: the API never returns the database password, so it doesn’t enter the conversation. Copy it from the database page in the dashboard and add it yourself as a variable (for example DB_PASSWORD). The app also needs the database’s client certificate: see Connect a database.

​

Go back to the previous version

orders-api started failing after the last deploy. Show me the release history and what a rollback would change, then roll back to the last version that worked.

rollback_app is marked destructive, so the client asks you to confirm before it runs. See Rollback and zero-downtime deploys.

​

Take a snapshot before a risky change

Take a snapshot of orders-db before I run the migration. If the migration fails, restore it.

create_snapshot and restore_snapshot use snapshots:write; list_snapshots uses snapshots:read. Restoring replaces the current data, so the client asks you to confirm. See Backups and snapshots.

​

Read your site’s traffic

Compare this week’s traffic on shop-web with last week’s. Which paths have the most 5xx errors?

get_app_analytics and get_app_analytics_errors use apps:read. Paths and referers come from your visitors and also reach the agent as untrusted content. See Web Analytics.

​

Look up how the platform works

According to the Vertra Cloud docs, how much storage does a 2 GB PostgreSQL get?

get_docs reads this documentation and needs no scope. It’s how the agent checks a limit or an error code instead of guessing.

​

Keep the agent safe

• Start with read scopes. apps:read, databases:read and snapshots:read cover investigation. Add write scopes when you need them, preferably in a separate key.
• Leave destructive confirmations on. Deleting, stopping, restarting, overwriting a file, changing a variable and rolling back are marked destructive, and the client asks before each one. Don’t allow them permanently.
• Variable values never reach the agent. list_envs returns only names, and set_env doesn’t echo the value.
• Revoke what you no longer use. Each key, including one created by an OAuth connection, appears under Settings → API keys. An account has up to 10 keys.