Configuration
How foundry.toml profiles drive compiler settings, remappings, fuzz configuration, and per-network defaults.
Third-party documentation. This is independently authored analysis of the public Foundry codebase — not the official docs, and not reviewed or endorsed by the Foundry team.
Configuration
Everything Foundry does is driven by foundry.toml at the project root. The file is organized into sections that map to the tools: compilation, test running, fuzzing, scripting, and Anvil defaults. Profiles let one repo carry several named configurations (e.g. a CI profile with more fuzz runs) selected with --profile.
The compiler section
[profile.default.solc] pins compiler versions; [profile.default.optimizer] and optimizer_runs pass through to solc; EVM target versions are set explicitly rather than inferred. Because the config is per-profile, verifying production bytecode settings is a matter of diffing profiles, not remembering CLI flags.
Remappings
Import-path rewriting (@openzeppelin/=lib/openzeppelin-contracts/) lives in the same file or in a remappings.txt. Foundry resolves remappings from the lib/ dependency tree automatically, so git-submodule vendoring works without a package manager.
Fuzz and invariant sections
[fuzz] controls run counts, dictionary weights, and seeds; [invariant] controls call sequence depth and run counts for invariant tests. Seeds are recorded on failures — reproducing a flaky CI fuzz failure means pinning the same seed locally.
Ethereum endpoints
[rpc_endpoints] names remote networks referenced by tests and scripts via $-style environment interpolation, keeping secrets out of the TOML file. Anvil fork defaults follow the same pattern.