vultr-cli turns the Vultr API into one cobra command tree per resource

The command tree mirrors the resource list, not the API endpoints

vultr-cli is the official command line tool for Vultr services, and the shape of the tool is visible in the help output the README opens with. There are about thirty command groups, each named after the resource it manages: account, apps, backups, bare-metal, billing, block-storage, cdn, container-registry, database, dns, firewall, inference, instance, iso, kubernetes, load-balancer, logs, marketplace, object-storage, os, plans, regions, reserved-ip, script, snapshot, ssh-key, user, version and vpc.

That grouping is the design decision worth noticing. The alternatives are a command per API endpoint, which produces an unwieldy flat list, or a generic resource command that takes a type argument, which makes every invocation longer. Grouping by resource gives you vultr-cli dns domain create and vultr-cli instance list as the memorable forms, and the sub commands under each group are the operations.

Two global flags are worth knowing. There is a --config string for the path to a config file, and an output format flag, -o with text, json or yaml as the accepted values and text as the default. The json output is what makes the tool usable in a pipeline, since the default human readable form is not what you want to pipe into jq.

The tool is built with cobra, and the module file records the rest of the stack: viper for configuration, the govultr client at version 3.33.2 for talking to the API, oauth2 for the token flow, and yaml.v3 for the config file format. The module path is github.com/vultr/vultr-cli/v3, so the major version is in the import path.

Authentication is an environment variable, and the config file is the fallback

You need a Vultr API key, which you get from the account settings page, and the README is clear that you pass it as an environment variable, with the form export VULTR_API_KEY=<your api key>. There is no key flag in the global help output, which is a deliberate choice. A flag would end up in your shell history and in any process listing, while an environment variable can be set from a secret manager and scoped to a single command.

The config file is the alternative, and the precedence rule is the part to remember. The config flag can be used to specify the vultr-cli.yaml config filepath, and when the api-key key is defined with a value the CLI will use it, but environment variables override the value defined in a config file.

The config file itself is minimal. Currently the only available field that you can use with a config file is api-key, so the whole file is one entry, api-key: MYKEY, and you point the flag at it with the --config path, for example vultr-cli instance list --config /Users/myuser/vultr-cli.yaml.

So there are two ways to supply the credential and one rule for resolving them: the environment wins. For a local shell, exporting the variable is the path of least resistance. For a machine where the key lives in a file, the config file works, but you need to remember that setting the environment variable once will shadow it permanently.

Installing means choosing a channel, and there are five

The README lists the installation options as download a release from GitHub, build from source, use a package manager, or use Docker, with the package managers being Arch Linux, Brew, OpenBSD current, Snap which is coming soon, and Chocolatey, plus Fedora appearing in its own section later.

The package manager installs are one line each, and the four documented ones are:

pacman -S vultr-cli

brew install vultr/vultr-cli/vultr-cli

dnf install vultr-cli

pkg_add vultr-cli

From source, the short way is a go install of the module, and the README gives the command go install github.com/vultr/vultr-cli/v3@latest. The longer way clones the repository and uses the Makefile, which takes the target name as an argument, make builds/vultr-cli_(pass name of os + arch, as shown below). The available targets cover darwin amd64 and arm64, linux 386, amd64 and arm64, windows 386 and amd64 as .exe files, and a linux arm build. The resulting executable lands in builds/vultr-cli_(name of os + arch).

Docker is the fifth channel. The image is on Docker Hub as vultr/vultr-cli, and the latest version is pulled with:

docker pull vultr/vultr-cli:latest

Or you pass a version string in the tag, for example docker pull vultr/vultr-cli:v2.15.1, and the available versions are listed on the releases page.

The Dockerfile in the repository shows the shape of that image. It builds on golang:1.26-alpine3.22 with CGO_ENABLED=0, runs the same Makefile target, and the runtime stage is plain alpine:latest with ca-certificates added, with the built binary copied in and set as the entrypoint.

The everyday commands, and one flag detail that will bite you

The examples section is a short list of the operations that matter most, and they show the argument style.

Listing instances is vultr-cli instance list. Creating one takes four identifiers plus a name, and you get the values for those from the other commands, in the form vultr-cli instance create --region <region-id> --plan <plan-id> --os <os-id> --host <hostname>.

Creating a DNS domain is the same shape, with a domain name and an IP address, in the form vultr-cli dns domain create --domain <domain-name> --ip <ip-address>.

The flag detail is about booleans. The README says you should use = when using a boolean flag, and the example appends --notify=true to the instance create command. That is not the usual Go flag style, and it is a consequence of how the command is wired rather than a general rule of the tool.

The lookup commands are what you will actually use most, because the create commands need identifiers. The command list includes plans to display available plan information, regions to display regions information, os to display available operating systems, and iso to manage ISOs, plus marketplace for marketplace information. The flow is the obvious one: find the region id, find the plan id, find the os id, then create the instance.

Shell completion is a separate setup step per shell

Autocompletion is available through the completion command, and the README is upfront that this feature requires setup. Each shell has its own sequence, and the difference between the two forms matters.

For bash, you can source the completion script directly for the current session:

  $ source <(vultr-cli completion bash)

Or you write it to a file for every session, and the README gives the per platform path, for example writing to /etc/bash_completion.d/vultr-cli on Linux and to /usr/local/etc/bash_completion.d/vultr-cli on macOS.

For zsh, completion has to be enabled in the environment first, which means adding a compinit call to your shell configuration, and then the completion file is written into the first entry of your fpath. The README notes you will need to start a new shell for the setup to take effect.

Fish is the simplest, since the output is piped straight into source, and a file can be written to ~/.config/fish/completions/vultr-cli.fish for every session.

PowerShell has two forms as well, one that pipes into Invoke-Expression for the current session and one that writes vultr-cli.ps1 to source from a profile.

The common thread is that writing a file is the durable option and piping is the disposable one, and the README says you need a new shell for the setup to take effect in at least the zsh case.

Where a cloud CLI stops, and what the project does not do

The scope is the obvious limitation. This is a Vultr tool, so it covers Vultr resources and nothing else. If your estate spans more than one provider, the resource lists here are not portable, and you would be running one CLI per provider with a different flag vocabulary in each.

The second limitation is that there is no state. The repository has no state file, no plan file, and no concept of a desired configuration. Every command is an imperative call against the live API, which means the tool is excellent at one off operations and at scripting, and it is not a way to describe infrastructure and reconcile it. If you want reviewable infrastructure as code, a Terraform provider or a Pulumi package for Vultr is the different approach, and the difference is that those tools keep the desired state in a file you can diff, while vultr-cli has nothing to diff.

The third is the API key model. The credential is a single environment variable with no notion of scopes, no per command permissions and no separate service accounts. For automation that touches billing, or that creates and destroys servers, a single credential with broad access is a coarse instrument, and the config file option does not improve on it because it holds the same key.

The alternative to weigh is the govultr Go client, which is what the CLI is built on and which you can use directly if you want the API without the command line. The difference in approach is that govultr gives you the same endpoints as a library with no argument parsing, no output formatting and no cobra conventions, which is the right choice when you are writing a program rather than a script. The CLI is the right choice when a person or a shell script is driving.

Recent releases, an active branch, and the usual provider obligations

The maintenance picture is straightforward. The last push was on 2026-10-19 and the repository is not archived. The release history shows v3.11.0 on 2026-08-07, v3.10.0 on 2026-04-16 and v3.9.2 on 2026-03-26, so the minor version has been moving steadily through 2026.

The build is reproducible in the usual Go way. The Makefile exports CGO=0, so the binary is static, and GOFLAGS=-trimpath, which strips local filesystem paths from the binary. Every target is an explicit GOOS and GOARCH cross build, which is why the same source tree produces the darwin, linux and windows binaries without a C toolchain on the machine.

The repository layout matches a typical cobra project: main.go at the root, cmd/ for the command definitions, pkg/ for the implementation, scripts/ for helper scripts, plus a Makefile, a .goreleaser.yml for release builds, a .golangci.yaml for linting, and a Dockerfile plus a Dockerfile.goreleaser for the container images. There is a CHANGELOG.md and a CONTRIBUTING.md, and the LICENSE and NOTICE files sit at the root.

The licence is Apache-2.0, which for a client tool of this kind is a permissive grant with an explicit patent clause, and the NOTICE file is the kind of attribution artefact that Apache licensed projects carry. That is a licensing note rather than legal advice, and it covers the tool rather than your infrastructure.

One last practical point. The tool talks to the Vultr API, so the account behind the key is subject to Vultr's own terms, quotas and abuse policies, and a command line interface makes it easy to script actions in bulk in a way that a dashboard does not. The API is the contract here, not the CLI.

Editorial conclusion

Adopt vultr-cli if you manage Vultr infrastructure from scripts or a terminal, since it covers the resource types a Vultr account actually has and takes its credential from the environment. Do not adopt it as a Terraform replacement or a general cloud CLI, because the command tree stops at Vultr resources and the project ships no state file. Verify first which of the thirty command groups covers the resources you use, that the API key in VULTR_API_KEY has the scope your automation needs, and whether you want the config file or the environment to be the source of the key, since the environment overrides the file.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. vultr/vultr-cli on GitHub