Stripe CLI: webhook forwarding, log tailing and live API calls from a terminal

Six package managers and one binary

The README covers macOS, Windows and Linux with a per-platform install command, and the choice is worth making deliberately because the auto-update story differs between them. npm is first and needs Node.js 18 or newer:

npm install -g @stripe/cli
npx @stripe/cli login

The `npx` form runs a single command without adding `stripe` to your `PATH`, which the README calls out explicitly. On macOS the short version is `brew install stripe`. On Linux there are two repository setups, one apt repository for Debian and Ubuntu and one yum repository for RedHat, Fedora and CentOS, each of which writes a keyring or repo file first. Windows gets both `winget install Stripe.StripeCLI` and a Scoop bucket pointed at `https://github.com/stripe/scoop-stripe-cli.git`.

If you would rather not involve a package manager, the README gives tarball names with a version placeholder in them, `stripe_X.X.X_linux_x86_64.tar.gz` among them, plus a note to move the binary onto your `PATH` yourself.

One warning is worth repeating because it wastes people an afternoon: the README says anti-virus software may flag the binary as unsafe, calls it a false positive, and links issue 692 for the details. On Windows, expect it.

The upgrade section mirrors the install section one for one, which is the signal that matters for the newest feature. v1.52.0 added automatic updates for CLIs installed with the install script, and the same release bounded the update download and made it refuse to stage what it could not verify. A tarball install therefore updates itself now; a brew or apt install keeps being managed by that package manager instead.

Webhooks to localhost without third-party software

The README's feature list is four bullets and the first is the one that keeps developers: securely test webhooks without relying on third party software. The mechanism is `stripe listen`, which the repository's own release history shows is not a stable command shape. v1.51.0 redesigned the `stripe listen` event selection flags and added error handling for when fetching endpoints fails during `stripe listen -a`, which suggests `-a` was doing endpoint discovery under the hood.

That same release added refresh of expired UAT in `stripe whoami`, which is a small fix that tells you the tool holds a short-lived test-mode credential and knows it has gone stale.

The other three bullets cover the rest of the loop. Trigger webhook events or resend events for easy testing covers `trigger` and `events resend`. Tail your API request logs in real time covers `logs tail`. Create, retrieve, update or delete API objects covers the general object commands. The README's own command list names `login`, `listen`, `trigger`, `logs tail` and `events resend` as the most used, and points to docs.stripe.com for the rest.

One command from v1.51.0 deserves attention: unused CLI commands were removed. That release is a cleanup with a real cost. If you scripted against a command that has since gone, the fix is not a flag change but finding the current equivalent in the documentation.

Docker works for test mode and needs real work for live mode

The Docker path is the least straightforward part of the README and the reason is stated clearly: because containers are ephemeral, `stripe login` is not supported there. Use the `--api-key` flag instead.

The image is `stripe/stripe-cli`, and the smoke test in the README is short:

docker run --rm -it stripe/stripe-cli version
stripe version x.y.z (beta)

The output shape is interesting on its own. It prints a version with a `(beta)` marker, so you cannot assume a tagged image is a stable release of the CLI.

For live mode without typing a key on every command, the README provides a four-step password store setup. An `entrypoint.sh` generates a GPG key called `stripe-live` if the trust database is missing, initialises a password store record of the same name, and then inspects its arguments for `--live`; when it finds that substring it appends `--api-key` with the value from `pass show stripe-live`. The Dockerfile builds `FROM stripe/stripe-cli:vx.x.x`, adds `pass` and `gpg-agent`, and copies the entrypoint in. Running it mounts three volumes: `stripe-config://root/.config/stripe/`, `stripe-gpg://root/.gnupg/` and `stripe-pass://root/.password-store/`.

That is a fair amount of machinery for one flag, and the README says as much by presenting `--api-key` as the simpler per-command alternative. It also makes an incorrect argument in passing: if your command contains the string `--live` anywhere, including as an argument value, the key gets injected. Worth reading the script before trusting it with a live secret.

Plugins outlive the binary, so uninstall in the right order

The uninstall section has an ordering requirement that is easy to miss and impossible to recover from afterwards, because the step that removes plugins needs the CLI still installed. The README is explicit that package managers remove only the `stripe` binary and leave installed plugins behind:

stripe plugin uninstall --all

After that, remove the CLI with whichever of `npm uninstall -g @stripe/cli`, `brew uninstall stripe`, `sudo apt remove stripe`, `sudo yum remove stripe`, `winget uninstall Stripe.StripeCLI`, `scoop uninstall stripe` or `docker rmi stripe/stripe-cli` matches how you installed it.

The third step is the interesting design decision. Uninstalling intentionally keeps your configuration, so reinstalling preserves your projects and settings. Credentials are cleared separately with `stripe logout --all`, and leftover configuration is removed by hand:

stripe logout --all
rm -rf "${XDG_CONFIG_HOME:-$HOME/.config}/stripe"

That quoted path also tells you where state lives, honouring `XDG_CONFIG_HOME` and falling back to `~/.config`. If you are auditing a machine for stored credentials, that directory plus `stripe logout --all` is the pair to run.

A Go repository with canary tests against the compiled binary

The tree shows a conventional Go layout with `cmd/`, `pkg/`, `internal/`, `api/`, `rpc/`, `canary/`, `docs/` and `npm/`, plus `ARCHITECTURE.md`, `CLAUDE.md` and `CODEOWNERS`. The module is `github.com/stripe/stripe-cli` and `go.mod` requires Go 1.26.5. Dependencies include cobra and viper for command and config handling, logrus for logging, gorilla/websocket, gRPC and protobuf, and a `charm.land` set of terminal UI libraries.

The interesting part is the testing setup in the `Makefile`. `go test` runs with `-failfast`, `-race`, atomic coverage mode and a two-minute timeout. There is a `canary` target that first builds a production-like binary with `CGO_ENABLED=0 go build -ldflags="-s -w"` and then runs end-to-end tests against that compiled binary with a fifteen-minute timeout, and a `canary-offline` variant that runs only tests matching `TestOffline` and needs no API key.

Two details in the Makefile are worth quoting. On macOS the test target sets `CGO_ENABLED=0` to work around a Go 1.26.0 linker crash under `-race`, linking the Go issue. And `GOLANGCI_LINT_VERSION` is pinned to `v2.12.2`, with a `.golangci.yml` at the root.

The release pipeline is also automated: the v1.52.0, v1.51.1 and v1.51.0 notes each begin with a comment saying they were generated from configuration in `.github/release.yml` at that tag. v1.51.1 has no changelog entries at all under that header, so an empty patch release is a normal occurrence here. The last push was on 2026-09-28, four days after v1.52.0.

Editorial conclusion

Stripe CLI is the shortest route from a webhook you cannot test to a webhook you have seen arrive, and the `listen` and `logs tail` commands have no real substitute in the official SDKs. Install it from your existing package manager and stay on the current line: v1.52.0 added automatic updates for script installs and, in the same release, bounded the update download and refused to stage anything it could not verify, so an older binary is missing the safeguards a newer one has. Two things to check before wiring it into a workflow. In Docker, `stripe login` does not work because containers are ephemeral, so live mode needs the `--api-key` flag or a password store mount, which is a real difference from every other install path. And `stripe plugin uninstall --all` has to run before you remove the CLI, since package managers clean up the binary and leave installed plugins behind.

Frequently asked questions

Official sources

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