scaleway-cli: driving Scaleway infrastructure from a terminal

The whole platform, one namespace per product

Scaleway CLI is a tool to help you pilot your Scaleway infrastructure directly from your terminal, and the README points at cli.scaleway.com for a complete reference of the different commands.

The reference documentation is a table of namespaces, and the table is the map of the platform. account covers user related data, applesilicon the Apple silicon API, baremetal, billing, cockpit, container for serverless containers, dns, function for serverless functions, iam, instance, iot and ipam are all there, alongside the local ones for autocomplete, config, feedback, info and init.

Each namespace has two documentation links, one to the CLI page and one to the API page, and that pairing is the point. The CLI is a front end onto the public API, and the API documentation is where the semantics live. When a command does not do what you expected, the answer is usually in the API page, because the CLI is a thin and consistent wrapper over it.

The project is Apache-2.0 licensed, the module is github.com/scaleway/scaleway-cli/v2, and it requires Go 1.27.1. The releases move fast, with v2.65.1 and v2.65.0 both published on 2026-10-07 and v2.64.0 the day before, and the repository was last pushed to on 2026-10-15.

The argument style is uniform, and that is the trade

The basic commands section is where you see the argument model, and it is consistent everywhere.

# Create an instance server
scw instance server create type=DEV1-S image=ubuntu_noble zone=fr-par-1 tags.0="scw-cli"

# List your servers
scw instance server list

Every argument is a key equals value pair, and nested structure is expressed with dots in the key. The tag list is tags.0, and the Kubernetes example is more instructive because it stacks three levels of nesting into a single command.

scw k8s cluster create name=foo version=1.17.4 pools.0.size=3 pools.0.node-type=DEV1-M pools.0.name=default tags.0=tag1 tags.1=tag2

Here pools.0.size, pools.0.node-type and pools.0.name are three fields of the first element of the pools array, and tags.0 and tags.1 are two elements of the tags array.

The trade is real and it is worth naming. A uniform argument grammar means every command in every namespace is learned once, and a command that is not documented is still discoverable by convention. What you give up is per command flag help, since there is no place for a flag to describe itself, and shell completion has to derive everything from that same convention. For scripting, where the same pattern appears in a hundred places, that is a good deal. For discovery by reading help output, it is not.

Four install routes, and the recommended one

The installation section is organised by how you get the binary, and the project recommends a package manager for simplicity and reliability.

Homebrew installs the latest stable release on macOS and Linux.

brew install scw

Arch Linux has the CLI in the official repositories, so pacman installs it.

pacman -S scaleway-cli

And on Windows, Chocolatey has a package for it.

choco install scaleway-cli

Manually, the project provides static compiled binaries for darwin, GNU/Linux and Windows, and on Linux the convenience route is a shell script.

curl -s https://raw.githubusercontent.com/scaleway/scaleway-cli/main/scripts/get.sh | sh

That is a pipe from a raw URL into a shell, which is worth noticing for the same reason the earlier articles in this batch noticed similar patterns: the script is fetched at the moment you run it, not pinned to a version, and it runs with your privileges.

There is a fourth route, which is the one that matters for CI and for containers.

docker run -i --rm scaleway/cli:latest

And the README points at a dedicated document for running the CLI in Docker, which is where the detail about credentials and configuration lives.

scw init, and the credential you cannot avoid

After installing, the getting started section says to run the initialisation command and let yourself be guided, and the command is short.

scw init

It will set up your profile, the authentication and the auto-completion, in one interactive flow, which is a good design, because the three things you would otherwise have to configure by hand are exactly the three that are fiddly.

The requirement is stated plainly in a note. You will need to have an API key, an access key and an access secret, and you should create one on the Scaleway web console. The key is generated in the console, so the CLI does not create credentials for you, and the secret is a long lived credential that the init flow stores in your profile.

That is the single most important operational fact about this tool. The credential is a pair of static values, not a token that expires, and the profile it lands in is a file on your disk. A CI job that uses this CLI is using a long lived secret, and the usual advice applies: give the job only the permissions it needs, and rotate the key when somebody leaves.

The rest of the configuration is available through the environment. You can configure your config or enable functionalities with environment variables, the variables that override config are described in the config documentation, and beta features are turned on with a single variable.

export SCW_ENABLE_BETA=1

The dependency list is the feature list

The go.mod is worth reading, because the CLI is far more than a thin wrapper around an HTTP API, and the dependencies say what else it does.

The Scaleway SDK for Go is there for the platform itself, and cobra with pflag is the command line layer. But the rest of the list goes well beyond that. The AWS SDK for Go v2 with the S3 service is a client for object storage, and the container tooling is heavier still: buildpacks/pack, moby/buildkit, the moby client and the OpenContainers image spec and digest packages together mean the CLI can build and push container images without shelling out to a separate tool.

The interactive layer is charmbracelet/bubbletea, which is the framework behind the terminal user interface, with go-prompt and readline as well. The Model Context Protocol SDK for Go is in the list at version 1.8.0, which is what lets an agent drive the CLI. Sentry is there for error reporting, and gorilla/websocket for the parts of the platform that are event streams rather than request and response.

Two of the smaller entries are the most telling. dnaeon/go-vcr is a record and replay library for HTTP, which is how the CLI's own tests run without touching the real API, and karrick/tparse parses test output, which suggests the repository runs its own test suite through the same reporting machinery.

So the picture is a tool that covers a platform, not just an API client, and the top level of the repository backs that up with a core/ directory, a commands/ directory, an internal/ directory, a cmd/ entry point, a scripts/ directory, a docs/ tree with a page per namespace, and a wasm/ directory.

The container image is built FROM scratch

The Dockerfile in the repository is four lines of real content, and they are the interesting ones.

FROM scratch
COPY --from=alpine:latest /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
ARG TARGETPLATFORM
COPY $TARGETPLATFORM/scaleway-cli /usr/bin/scw
ENTRYPOINT ["/usr/bin/scw"]

The image contains exactly two things. The first is the certificate bundle, copied out of an Alpine image in a separate build stage, which is the standard way to get trusted roots into a scratch image without shipping a package manager or a shell. The second is the binary, which is placed by the build platform argument, so the same Dockerfile produces the right image for each target architecture.

What is not there is the point. There is no shell, no libc, no package manager and no core utilities, so the image is a single static binary and the attack surface is the binary itself. For a CLI that often ends up in a CI job with credentials in the environment, that is a sensible posture.

The build system around it is GoReleaser, configured by .goreleaser.yml, which is what produces those per platform binaries in the first place, and the static binaries are what the manual installation path offers. The repository also has a .devcontainer/ for development, a .mise/ directory with mise.toml and mise.lock for toolchain versions, a .golangci.yml for linting, a .skills/ directory, and both AGENTS.md and CLAUDE.md describing conventions for tooling that works on the repository.

Editorial conclusion

scaleway-cli fits an engineer who works with Scaleway and wants to script against the platform from a terminal or a CI job, rather than clicking through the console, and who is comfortable with a flat key equals value argument style. It does not fit a team that wants typed, discoverable commands with per flag help, because the argument model trades that for uniformity across every namespace. Verify three things before you build on it: which namespace and API version you are targeting, since the reference documentation table maps each namespace to both a CLI page and an API page and they are not the same thing, whether the beta features you need are enabled, since SCW_ENABLE_BETA has to be set and the beta surface can change, and how you handle the API key, because the credential is a long lived access key and secret that the init flow stores in your profile.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. scaleway/scaleway-cli on GitHub