Vultr CLI for coding agents

When a coding agent can run shell commands with access to a Vultr account, it can use vultr-cli to inspect cloud resources and use commands that change them to manage those resources. The CLI is Vultr’s command-line tool for services such as virtual machine instances, Kubernetes, DNS, firewalls, and object storage. It returns text or structured JSON and YAML, which makes its output useful to both people and scripts. The official Vultr CLI project documents the tool and its commands.

A useful first task is read-only: ask an agent to list existing instances and summarize their names and regions. The command sends a request to Vultr, so the agent needs access to an API key, a secret credential that authorizes requests. Keep that key outside the prompt.

Install and authenticate

The project’s installation instructions include a Homebrew command for macOS:

brew install vultr/vultr-cli/vultr-cli

The README lists other install options too, like GitHub release downloads and a Docker image.

Vultr uses API keys to authenticate CLI requests. In the Vultr console, turn on API access for your account and copy the key, as the Vultr guide to enabling API access describes. Then set the VULTR_API_KEY environment variable so the CLI can use the key. The shell supplies an environment variable, a named value, to programs it starts. For example, enter the key at a hidden prompt in Bash instead of putting it in your agent’s instructions:

read -s -p "Vultr API key: " VULTR_API_KEY
export VULTR_API_KEY
printf '\n'

Bash hides the key as you type when you use its silent input option. Commands you start from that shell can read the exported variable. Do not commit the key to a repository or include it in a prompt; give the agent only the shell access it needs.

List instances as JSON

Run the instance list command with JSON output:

vultr-cli instance list --output json

The CLI contacts Vultr and returns the instances visible to the authenticated account. JSON is structured text, so an agent can inspect fields and summarize them without relying on the layout of a human-readable table. The global --output flag also takes yaml, and its default is text, as the README shows. The instance list reference says the command returns 100 items per page by default. You can raise that with --per-page up to 500 and use --cursor to get the next page.

The command does not create, update, or delete an instance. Its output depends on the account’s current resources, so there is no fixed result to expect. If the account has no instances, the response will reflect that; an agent should report what the command returns rather than inventing resource details.

A realistic prompt for this task is:

Run vultr-cli instance list --output json. Summarize each returned instance’s name and region. Do not change any Vultr resources. If the command fails, report the error without printing credentials.

The agent performs the API request when it runs the command. Writing a summary is local work; the list command itself does not change Vultr resources.

Keep inspection separate from changes

Vultr CLI also provides commands that change cloud resources. For example, its instance creation reference documents options for creating an instance. Creating an instance sends Vultr a write request, which adds a cloud resource. This is separate from listing existing instances.

For agent tasks, request inspection first. If a later task calls for a change, have the agent present the exact command and intended resource details for review before it runs that command. Do not assume a read-only listing is a preview of a future change: it only reports current account data.

Know the boundary

Vultr CLI is a shell tool, not a coding-agent-specific integration. The agent invokes its commands through the shell, and those commands use the credentials available to that shell. This makes the CLI practical for a bounded task such as inventorying instances, but the agent’s access depends on the API key and account.

The CLI can also read the key from a vultr-cli.yaml file that you pass with --config. The README says an environment variable overrides the key in that file. Before you allow a command that changes resources, check which key the shell exports and confirm that it belongs to the intended account.