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 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. Anvil is, per the README, a fast local Ethereum development node, and it can fork a live network with anvil --fork-url. 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 try an expression 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,

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 recent release list mixes nightlies with a tagged version: nightly-430523103f3e2f9ba432ffdd2031a9f966153d0d (Nightly 2026-11-03), v1.9.0 on 2026-11-02, and nightly-a577a1142515f5a96935a525935936a2281b4c75 (Nightly 2026-11-02). The workspace version in Cargo.toml is 1.9.1, while the newest tagged release in the list is v1.9.0.

Nightlies are identified by commit hash, so pinning one means recording that hash, while the tagged v1.9.0 gives you a version number to pin. The nightly releases listed are dated daily (2026-11-02 and 2026-11-03), 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 workspace Cargo.toml sets rust-version = 1.98 and edition 2024, so building from source requires a very 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 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, many published releases are nightlies identified by commit hash, which can be an obstacle for regulated or slow-moving environments where every artifact needs a stable identifier; the tagged v1.9.0 release is the one with a version number.

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 many published builds are nightlies identified by commit hash alongside occasional tagged versions such as v1.9.0. Do not adopt it if you need a graphical deployment console or a language other than Solidity. 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