Foundry for Ethereum development: Forge, Cast, Anvil and Chisel

What Foundry actually replaces in an Ethereum workflow

Foundry is a command line toolkit for Ethereum application development, written in Rust and licensed under Apache-2.0 or MIT at your option. The README splits it into four programs rather than one monolith. Forge builds, tests, fuzzes, debugs and deploys Solidity contracts. Cast interacts with EVM smart contracts, sends transactions and reads chain data. Anvil is a local Ethereum development node. Chisel is a Solidity REPL.

The audience is narrow and specific: people who write Solidity or Vyper and are comfortable in a terminal. If your workflow depends on a browser IDE or a graphical deployment wizard, none of these four binaries is aimed at you. The payoff for the terminal user is that contract compilation, test execution and chain interaction come from a single installation, so the toolchain does not have to be assembled from separate npm packages and a separate node implementation.

The repository layout confirms the split. The Cargo workspace lists crates/forge/, crates/cast/, crates/anvil/ (itself divided into core, rpc and server sub-crates), and crates/chisel/ as separate members, alongside shared crates for the EVM, fuzzing, tracing, formatting, linting and configuration. That is a real modular boundary, not a marketing description: Anvil can be reasoned about as a node with its own RPC and server layers.

How the four binaries divide the work

The data flow is conventional for a smart contract toolchain, with one notable addition. Forge compiles Solidity sources into bytecode and ABI, then runs tests against an EVM. Those tests can be executed against Anvil, which the README describes as a fast local Ethereum development node, or against a fork of a live network. Cast sits outside the test loop entirely: it is for reading state and sending transactions to whatever RPC endpoint you point it at. Chisel is for evaluating Solidity snippets interactively, which is useful when you want to check what an expression compiles to without creating a file and a test.

The addition is the language server. The README states that running forge lsp with VS Code installed opens the project in a VS Code Extension Development Host with a bundled Solidity extension, and that no Foundry checkout, extension build or separate Solar installation is needed. For other editors, the language server command is forge lsp --stdio. Solar, the Solidity language server in the workspace, picks up foundry.toml, workspace folders, remappings and evm_version from the project automatically. Solar's default flycheck runs forge lint --json using the same Forge executable that started the server, and the existing initializationOptions.forgePath option overrides that executable.

One detail worth noting for anyone wiring this into an editor: the README says that in server mode, project dotenv warnings go to stderr, leaving stdout reserved for the LSP transport. That is the correct choice, but it also means a misconfigured .env will not break the protocol, it will just print on a channel your editor may not surface.

Installing Foundry and running a first test

The README gives a two-step install. The first command downloads the installer script from foundry.paradigm.xyz and pipes it to bash; the second runs foundryup, which is the updater that fetches the toolchain.

curl -L https://foundry.paradigm.xyz | bash
foundryup

The README points to the installation guide at getfoundry.sh/getting-started/installation for more detail, and to SECURITY.md for verifying a downloaded release archive or container image. If you are installing on a machine that handles real keys, read the verification section before running the installer.

With the toolchain in place, the README's getting started sequence initializes a project, builds it and runs the tests:

forge init counter && cd counter
forge build
forge test

You should end up with a project directory named counter containing the scaffolded contract and test files, a successful compilation, and a test summary printed by forge test. If forge test reports failures on a freshly initialized project, the problem is the installation or the compiler resolution, not your code.

Chain queries use Cast against an RPC URL. The README's examples read the current block number and a balance:

cast block-number --rpc-url https://eth.merkle.io
cast balance vitalik.eth --ether --rpc-url https://eth.merkle.io

The first prints a block height, the second prints a balance denominated in ether because of the --ether flag. The .eth name is resolved through the RPC endpoint rather than a local address book.

Finally, Anvil starts a local node that forks a live network:

anvil --fork-url https://eth.merkle.io

This launches a development node whose state is seeded from mainnet at the fork URL. It is the piece you would point Forge tests at when you need realistic contract state instead of a blank chain.

Nightly releases and what that means for pinning

The release list is the clearest limitation in the published artifacts. The recent releases are all nightlies: nightly-cc29fe1ce8ba9366dc3bdb57ddf790d51420cfd5 dated 2026-09-21, nightly-6f11b0156c1b3caa95215b7ff446d8c27d6a0506 dated 2026-09-18, and nightly-e064a2a246ebbf8a11ba0ef2ad1ac19bee85ce09 dated 2026-09-16. There is no tagged stable release in that list. The workspace version in Cargo.toml is 1.8.4, so a version number exists in the source tree, but the published artifacts the README tells you to install through foundryup are nightly builds identified by commit hash.

For a team, that changes the upgrade conversation. You cannot point at a semantic version and reason about compatibility; you point at a commit and either pin it or move forward. The nightly cadence shown here is roughly every two to three days, which is fast enough that a bug fix arrives quickly and also fast enough that an unplanned change can arrive quickly. The README does not document rollback through foundryup, so if you need reproducible builds across machines, pinning the commit hash in your own tooling is the practical step, and the README does not describe how to do that.

A second constraint is the build itself. The Makefile sets rust-version = 1.89 in the workspace package metadata and uses edition 2024, so building from source requires a recent Rust toolchain. The default feature set in the Makefile includes jemalloc on non-Windows platforms plus aws-kms, gcp-kms, turnkey, cli, asm-keccak, base, monad and optimism, which tells you the intended build is not minimal. The Dockerfile builds through cargo-chef and sccache with pinned base image digests, so container builds are reproducible in the sense that the base layers are pinned, though the dependency graph still resolves from Cargo.lock.

Foundry versus a JavaScript-first framework such as Hardhat

The obvious alternative for Solidity work is a JavaScript or TypeScript framework, and Hardhat is the common one. The difference in approach is not speed claims, it is where the test and script code lives. Foundry tests are written in Solidity and run inside the EVM, which means a test can call internal functions, use cheatcodes, and fork mainnet state without a translation layer. A JavaScript framework runs tests in Node and talks to the EVM through a provider, which means your test assertions are JavaScript and your contract calls cross a boundary.

That boundary is not free, but it buys things Foundry does not have. A JavaScript test suite can use the entire npm ecosystem for fixtures, mocking and reporting, and deployment scripts written in TypeScript are familiar to teams that already write TypeScript. If your project already has a substantial TypeScript test harness, moving to Solidity tests is a rewrite, not a migration.

The other practical difference is the local node. Anvil is part of the same installation as Forge and Cast, so starting a fork and querying it uses one toolchain. A JavaScript stack typically pairs with a separate node implementation, which is an extra dependency to version and keep in step. Neither arrangement is strictly better; they fail in different places.

Licensing and what the dual licence asks of you

Foundry is dual licensed under Apache-2.0 and MIT, at your option, per the README and the LICENSE-APACHE and LICENSE-MIT files in the repository root. The workspace metadata in Cargo.toml records license = "MIT OR Apache-2.0". Both are permissive licences that allow commercial use and modification; the choice between them is yours, and the Apache-2.0 option carries an explicit patent grant that some legal teams prefer.

The README also states that unless you explicitly state otherwise, any contribution you intentionally submit for inclusion in the crates is dual licensed under the same terms, with no additional conditions. If you plan to contribute, that is the inbound licence you are agreeing to. This is a description of what the repository says, not legal advice; if your organisation has rules about inbound contribution licences, route the question to whoever handles that.

Where Foundry is the wrong tool

Foundry assumes you are comfortable constructing commands and reading terminal output. There is no graphical interface described anywhere in the README. A developer who needs to click through a deployment, inspect a contract in a block explorer style view, or hand a deployment task to a non-engineer will not find that here.

The second mismatch is language. The topics list includes Solidity and Vyper, and the README describes Forge as building, testing and deploying Solidity contracts. If your contracts are in a language outside that set, the toolchain is not aimed at you.

The third is operational. Anvil is described as a local development node. Nothing in the README presents it as a production node, and treating a development node as production infrastructure would be a category error. If you need to run a node for real traffic, that is a different piece of software.

Finally, the nightly-only release pattern is a genuine obstacle for regulated or slow-moving environments where every artifact needs a stable identifier. The published releases do not show a stable release channel, so plan for that constraint rather than discovering it during an audit.

Editorial conclusion

Adopt Foundry if you write Solidity and want tests, a local node and chain queries behind one installer, and if you accept that the published builds are nightlies rather than tagged versions. Do not adopt it if you need a graphical deployment console or a language other than Solidity and Vyper. Verify first that foundryup resolves on your platform, that forge build and forge test pass on a throwaway project, and that the nightly cadence fits your release process.

Frequently asked questions

Official sources

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