# Tenderly CLI pushes and verifies contracts, and stops short of the rest

> Tenderly CLI is a Go command line tool for smart contract error tracking, monitoring and alerting, with commands to log in, link a local project, push deployed contracts and verify sources. Its scope is deliberately narrow: the Hardhat plugin is the recommended path for monitoring, and the CLI handles the dashboard-facing operations.

**Tenderly/tenderly-cli** — CLI tool for Smart Contract error tracking, monitoring and alerting.

- Repository: https://github.com/Tenderly/tenderly-cli
- Website: https://tenderly.co
- Stars: 591 · Forks: 183
- Language: Go
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/tenderly-tenderly-cli

## A CLI with a narrow job, and an explicit boundary

Tenderly CLI is described as a suite of development tools that allows you to debug, monitor and track the execution of your smart contracts. It is written in Go, and the tool's own description frames it as error tracking, monitoring and alerting for contracts.

The scope is narrower than that description suggests, and the documentation is careful to say so. For smart contract verification, the readme sends you to the Foundry verification guide and the Hardhat verification guide rather than describing an equivalent flow here. For the push command, it points Hardhat users at the plugin documentation. Those are the two places where the documentation says a different tool is the right tool, and they are the two things most people would want from a contract monitoring CLI.

What remains is the set of operations that genuinely need a command line: authenticating against the Tenderly Dashboard, linking a local directory to a dashboard project, pushing contracts that are already on a public network, verifying sources, and checking for updates.

The audience is a Solidity developer working on a real deployment who wants the dashboard-side bookkeeping scripted rather than done by hand in a browser. It is not a development environment, a test runner, or a local node, and it does not try to be.

The topics on the repository place it in the same world: alerting, cli, developer-tools, error-tracking, ethereum, monitoring, real-time-analytics and smart-contracts.

## Three install paths, and one of them pipes a script to a shell

The install instructions differ per platform, and the differences matter more than the usual ones.

On macOS the documented route is Homebrew:

```
brew tap tenderly/tenderly
brew install tenderly
```

The alternative on any platform is a cURL pipe to an installation script, and for macOS the documented form is:

```
curl https://raw.githubusercontent.com/Tenderly/tenderly-cli/master/scripts/install-macos.sh | sh
```

On Linux the cURL route is the only one given, in two variants depending on whether you have root or use sudo:

```
curl https://raw.githubusercontent.com/Tenderly/tenderly-cli/master/scripts/install-linux.sh | sh
```

and:

```
curl https://raw.githubusercontent.com/Tenderly/tenderly-cli/master/scripts/install-linux.sh | sudo sh
```

On Windows there is no script at all. The instruction is to go to the release page, download the latest version and put it somewhere in your $PATH.

The piping pattern deserves a note. Downloading a script over the network and executing it in the same command means you are trusting whatever that URL serves at the moment you run it, and the URL points at the master branch rather than a tag, so the content is not pinned to the release you think you are installing. A security-conscious team will prefer the Homebrew route on macOS and the release page on Windows, and will read the script before running it on Linux. The repository does contain a scripts/ directory, so the scripts are available to inspect, which is the mitigation.

Upgrading follows the same split. tenderly version prints the current version, and brew upgrade tenderly upgrades the Homebrew install. The update-check command checks whether a newer version exists and gives update instructions and changelog information.

## Login and init, the two commands that set everything up

Authentication is handled by the login command, which authenticates the CLI with your Tenderly Dashboard:

```
tenderly login
```

The command flags table shows there is more than one way in. The --authentication-method flag picks between email and access-key. The --email and --password flags supply credentials for the email path, and --access-key supplies the token for the other. The --force flag skips the check for whether you are already logged in, and --help is available as usual.

The init command connects your local project directory with a project in the Tenderly Dashboard:

```
tenderly init
```

Its flags are --project for the project name used when generating the configuration file, --create-project to create that project if it does not exist, and --re-init to force initialisation when the project was already initialised.

The init command has a precondition that the documentation spells out: for the CLI to work you need a deployments directory inside your project, and you can generate one using hardhat-tenderly. The example then shows the npm install:

```bash
npm install --save-dev @tenderly/hardhat-tenderly
```

and the require line in hardhat.config.js:

```js
require("@tenderly/hardhat-tenderly");
```

or, for TypeScript:

```js
import "@tenderly/hardhat-tenderly"
```

The script side then calls persistArtifacts with the contract name and address:

```js
const Greeter = await ethers.getContractFactory("Greeter");
const greeter = await Greeter.deploy("Hello, Hardhat!");

await greeter.deployed()

await hre.tenderly.persistArtifacts({
    name: "Greeter",
    address: greeter.address,
})
```

persistArtifacts accepts variadic parameters, so several contracts can be passed at once. The documented sequence ends with compiling, starting a local node, running a script, and then running tenderly init once the deployments directory exists.

## push is for public networks only, and verify is a separate command

The push command adds your contracts to the Tenderly Dashboard, and it carries one restriction that is stated in bold in the documentation: the push command is used only for adding contracts that are deployed to a public network.

```
tenderly contracts push
```

Its flags are --networks for a comma separated list of network ids to push, --tag for an optional tag used for filtering and referencing pushed contracts, and --project-slug to pick only one project to push.

There is an advanced path through the tenderly.yaml file, and the documentation explains the trade-off clearly. To push to multiple projects you remove the project_slug property and replace it with a projects property, where each project maps to a list of networks. The comments in the example are worth reading, because they describe the fallback behaviour: if the networks property is not provided or is empty, the project is pushed to all of the migrated networks, and if you want to push to a shared project you provide the full project identifier, which can be found in the Tenderly dashboard under the project name.

The verify command is separate, and it uploads your smart contracts and verifies them on Tenderly:

```
tenderly contracts verify
```

with a --networks flag for the network ids to verify.

The separation between push and verify is the shape of the tool. Pushing is a bookkeeping operation for contracts that already exist on chain, and verification is a source-matching operation. Both are the kind of thing you want in a deploy script, which is why they are in a CLI at all, and both are things that a framework plugin can also do, which is why the documentation points you there when your project already has one.

## A Go codebase that still carries framework adapters

The repository layout is unusual for a modern Go CLI, and it explains the scope.

There are top-level directories named after the frameworks the tool knows about: brownie/, buidler/, hardhat/, truffle/, typescript/ and openzeppelin/. There is also a demo/ directory with its own contracts, migrations, scripts, test folder and a truffle.js, plus a package.json and a yarn.lock, so the demo is a JavaScript project that lives inside the Go repository.

Alongside those are the parts you would expect: commands/, config/, model/, providers/, rest/, git/, types/, userError/ and zip/. The git/ and zip/ directories suggest the tool deals with archived sources and repository metadata, and go-git and go-github in the dependency list support that.

The dependency set tells you the age and the compromises. go-ethereum is at v1.10.26, cobra and viper provide the command and configuration layers, and there is a long tail of smaller libraries: logrus for logging, aurora for coloured terminal output, promptui for interactive prompts, a spinner for progress, ghodss/yaml and yaml.v3 for configuration, jsonschema for validation, and robfig/cron for scheduling.

The go.mod declares go 1.18, and the Makefile sets CGO_ENABLED=0 for the test target, with a comment explaining that CGO is disabled to match release builds and that on recent macOS, cgo-linked test binaries built with older Go toolchains are killed for missing LC_UUID. That is a small, real-world piece of build friction, and the fact that it is commented in the Makefile rather than discovered means the project has already been bitten by it.

## GPL-3.0 on the tool, and a company behind the product

The licence is GPL-3.0, with the LICENSE file at the repository root. That is the one detail in this project that deserves a decision rather than an assumption, because it is the odd one out in the Tenderly tooling.

Consider what the CLI does. It reads your contract sources, your build output and your configuration, and it talks to the Tenderly Dashboard API on your behalf. It does not link into your application, and it is not distributed as part of your product, so a GPL obligation on your shipped code is unlikely to arise. The risk is narrower and more practical: a GPL-3.0 binary distributed to a team, and the operational question of whether an organisation's legal review of its developer tooling has a process for that.

The comparison to make is with the framework plugins the documentation steers you toward. The hardhat-tenderly package is a JavaScript library that runs inside your build, and that is a different licence and a different integration model. If your reason for wanting the CLI is that you need a terminal workflow, be clear that you are choosing a copyleft tool over a permissively licensed plugin, and that is a choice you can defend or avoid.

The project is clearly a company product rather than a community project. The homepage is tenderly.co, the release pipeline uses .goreleaser.yml for cross-platform Go releases, and there is a CircleCI directory for continuous integration. The recent releases show v1.7.1 and v1.7.0 both on 2026-08-05, v1.6.10 on 2026-04-27, and the last push was on 2026-08-05. The versioning is pre-1.0 in appearance but the numbers have been climbing for a while, and the release cadence of a 1.6 and a 1.7 in the same year suggests the tool is not abandoned.

## Conclusion

Tenderly CLI suits a team that wants to link a local Hardhat or Foundry project to a Tenderly dashboard, push contracts that are already deployed to a public network, and verify sources, without leaving the terminal. It is the wrong tool for monitoring, because the documentation points Hardhat users at the plugin and the Foundry and Hardhat verification guides for that work. Before adopting it, run tenderly init on a project that already has a deployments directory, and check the licence implications of GPL-3.0 against the rest of your toolchain, since this is the one part of the Tenderly ecosystem that carries copyleft.

## FAQ

### How do I install the Tenderly CLI on macOS, Linux and Windows?

On macOS the documented route is Homebrew, with brew tap tenderly/tenderly followed by brew install tenderly, and the alternative is a cURL pipe to scripts/install-macos.sh. On Linux the cURL pipe to scripts/install-linux.sh is given in root and sudo variants, and on Windows the instruction is to download the latest version from the release page and put it on your $PATH.

### What does tenderly init require before it will work?

For the CLI to work you need a deployments directory inside your project, and the documentation says you can generate one using hardhat-tenderly. The example installs it with npm install --save-dev @tenderly/hardhat-tenderly, requires it in hardhat.config.js, and calls hre.tenderly.persistArtifacts with the contract name and address.

### Can I push contracts that are not on a public network with tenderly contracts push?

No. The documentation states the push command is used only for adding contracts that are deployed to a public network. For verification, the readme points to the Foundry and Hardhat verification guides, and Hardhat users are directed to the plugin documentation instead of the push command.

## Sources

- [License: GPL-3.0](https://github.com/Tenderly/tenderly-cli/blob/master/LICENSE)
- [Project website](https://tenderly.co)
- [README](https://github.com/Tenderly/tenderly-cli/blob/master/README.md)
- [Releases](https://github.com/Tenderly/tenderly-cli/releases)
- [Tenderly/tenderly-cli on GitHub](https://github.com/Tenderly/tenderly-cli)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tenderly-tenderly-cli