Four commands cover the Solidity development loop
Foundry packages 4 tools around the work a Solidity team repeats every day. Forge builds, tests, fuzzes, debugs, and deploys contracts. Cast reads chain data and sends transactions. Anvil supplies a local Ethereum node, including a fork of a live network, while Chisel is an interactive Solidity shell. Keeping these jobs in one release is the main reason to choose Foundry over assembling a compiler, test runner, node, and transaction utility separately.
The suite reaches deeper than a quick forge test demo. Forge has invariant testing, cheatcodes, gas snapshots, scripting, verification, formatting, and linting. The README also documents forge lsp: it can open a bundled VS Code extension host or run as a standard language server over stdio. That breadth pays off when contracts are the product. A small team that only compiles a few examples may use a fraction of it.
The release installer is easier than the 540,056-line source tree
Foundry's documented install is 2 commands: pipe the installer into a shell, then run foundryup. That version manager obtains the current Forge, Cast, Anvil, and Chisel binaries. It can also select a numbered release, a nightly build, or a branch. Release v1.8.3 was published on September 15, 2026, and the installer verifies downloaded binaries against GitHub attestations.
Contributing is a different job. Our checkout contained 2,035 files and roughly 540,056 lines of source before dependencies. The install step brought in 1,257 packages, and the repository carries 20 CI workflow files plus a Dockerfile. That is evidence of substantial release machinery, though it does not make a local source cycle cheap. Teams writing contracts should start with the release binaries unless they need to change Foundry itself.
What happened when we ran it
Our sandbox installed the Rust dependencies in 139 seconds, then completed the build in 886 seconds. The test command ran for another 900 seconds before our limit stopped it. Cargo never printed a final aggregate, so the harness recorded 0 passed and 0 failed out of 0 rather than a completed result. The last log lines showed a run of Tempo and Tempo Canary cases ending in ok.
Our test method used commit 0f73bdb in an unprivileged Debian container with 3 CPUs and 12 GB of RAM. Those results establish that the source compiled under that setup. They do not establish that the full suite passes, because it did not finish. They also say nothing about Forge's contract-test speed or Anvil's RPC performance. The useful planning figure is the wall clock: install, build, and the unfinished test step occupied more than 31 minutes together.
The missing final count matters. A timeout is different from a failing assertion, and the log tail did not show a failed Tempo case. It is still a failed validation step for a contributor who needs a complete green run. If your pull-request gate has a 15-minute ceiling, our 900-second test result says you should split the workspace, reuse caches, or provision a longer job before assuming the default command will fit.
Windows needs WSL or Git Bash for foundryup
The official installation guide says foundryup does not support PowerShell or Command Prompt. Windows users need Git Bash or WSL. Direct release archives and Docker are alternatives, while a Windows source build also needs Visual Studio with the C++ desktop workload. The guide separately warns that locally building the Docker image can have problems on some systems, including Apple Silicon. Those are concrete setup limits, not reasons to avoid the released Linux and macOS binaries.
Local contract work can stay self-contained with Anvil. The README's live-network examples pass an RPC URL to Cast and Anvil, so forks and chain queries depend on an endpoint you trust and can afford. Broadcasting a deployment adds wallet handling. Foundry places the commands in one suite, but your team still owns secret storage, RPC availability, chain selection, and a review process before a script sends transactions.
Open broadcast reports deserve a deployment check
Open issue 17012 describes a specific Forge script risk in version 1.8.1: later transactions may use return values from the initial local simulation even if earlier chain state changes before mining. The report says --slow serializes sending but does not rebuild later transactions from newly mined state. That claim is not a finding from our sandbox, and it remains an open report. It is concrete enough to reproduce against any deployment script whose later calls depend on earlier return values.
Issue 16566 covers a narrower recovery path. Its author reports that forge script --resume can confuse progress when a transaction passes estimation, reverts when mined, and a later transaction still succeeds. The issue explicitly says most ordinary reverts stop earlier during gas estimation, so the trigger is limited. Both reports point to one practical rule: rehearse valuable multi-transaction broadcasts on representative state instead of treating the presence of --slow or --resume as proof of safe recovery.
Current maintenance supports adoption, with upgrade review
GitHub recorded Foundry's last push on September 27, 2026. The repository had 10,626 stars, 210 open issues, and 45 open pull requests when checked. Release v1.8.3 had arrived 12 days earlier with fixes across fork execution, scripting, cheatcodes, formatting, linting, and Chisel sessions. Its notes also say v1.8.2 was left unpublished after a rustls advisory and that v1.8.3 contains patched binaries.
That combination supports using the stable release while still reading its notes. Foundry changes alongside Ethereum hard forks, new transaction types, and multiple EVM networks, so upgrades can alter gas snapshots or script behavior. For a Solidity-heavy team, the 4-tool package is worth standardizing on. For an occasional contract or a TypeScript shop built around npm plugins, Hardhat or a browser-first Remix workflow may impose less change.