Anchor.toml Configuration
Anchor workspace config reference documentation
provider (required)
A wallet and cluster that are used for all commands.
Example:
scripts (required for testing)
Scripts that can be run with anchor run <script>. The test script is
executed by anchor test.
Example:
features
resolution
This tells the IDL to support account resolution. The default is true.
Example:
workspace
types
Adds a directory where you want the <idl>.ts file to be copied when running
anchor build. This is helpful when you want to keep this file in version
control, like when using it on the frontend, which will probably not have access
to the target directory generated by anchor.
Example:
members
Sets the paths --relative to the Anchor.toml-- to all programs in the local
workspace, i.e., the path to the Cargo.toml manifest associated with each
program that can be compiled by the anchor CLI. For programs using the
standard Anchor workflow, this can be omitted. For programs not written in
Anchor but still want to publish, this should be added.
Example:
exclude
Opposite of workspace.members.
Example:
programs
Example:
The addresses of the programs in the workspace.
programs.localnet is used during testing on localnet where it's possible to
load a program at genesis with the --bpf-program option on
solana-test-validator.
test
startup_wait
Increases the time anchor waits for the solana-test-validator to start up.
This is, for example, useful if you're cloning (see test.validator.clone) many
accounts which increases the validator's startup time.
Example:
genesis
Makes commands like anchor test start solana-test-validator with a given
program already loaded.
Example
upgradeable
Deploys the program-to-test using --upgradeable-program. This makes it
possible to test that certain instructions can only be executed by the program's
upgrade authority. The initial upgrade authority will be set to
provider.wallet.
If unspecified or explicitly set to false, then the test program will be
deployed with --bpf-program, disabling upgrades to it.
Example:
test.validator
These options are passed into the options with the same name in the
solana-test-validator cli (see solana-test-validator --help) in commands
like anchor test.
test.validator.clone
Use this to clone an account from the test.validator.clone.url cluster to the
cluster of your test. If address points to a program owned by the "BPF
upgradeable loader", anchor (>= 0.23.0) will clone the program data account of
the program for you automatically.
Example:
test.validator.account
Use this to upload an account from a .json file.
Example:
surfpool
Configuration for the Surfpool validator,
which is the default local validator used by anchor test. Surfpool provides a
lightweight Solana simulator with features like automatic account cloning and
runbook execution. All fields are optional and have sensible defaults.
Example:
startup_wait
Time in milliseconds to wait for Surfpool to start up. This is useful when
loading many accounts or running runbooks at startup. Default: 5000.
shutdown_wait
Time in milliseconds to wait for Surfpool to shut down gracefully.
Default: 2000.
rpc_port
The port on which Surfpool exposes its JSON RPC endpoint. Default: 8899.
ws_port
The port for the WebSocket endpoint. If not specified, it is derived automatically.
host
The IP address to bind the Surfpool validator ports to. Default: "127.0.0.1".
online
When set to true, Surfpool operates in online mode, allowing it to clone
accounts from a remote cluster specified by datasource_rpc_url. Default:
false (offline mode).
datasource_rpc_url
The RPC URL of the remote cluster used as a data source when online is
enabled.
Example:
airdrop_addresses
A list of base58-encoded addresses that will receive an airdrop of SOL when Surfpool starts.
Example:
manifest_file_path
Path to the Cargo.toml manifest file for the workspace. Typically not needed
since Anchor resolves this automatically.
runbooks
A list of file paths to runbooks that Surfpool will execute on startup. Runbooks allow you to set up initial state (deploy programs, create accounts, etc.) before tests run.
Example:
slot_time
The simulated slot time in milliseconds. Controls how fast slots advance in the Surfpool simulator.
log_level
Sets the log verbosity level for the Surfpool process. Common values include
"none", "info", "debug", "warn", and "error". Default: "none".
block_production_mode
Controls how Surfpool produces blocks. Default: "transaction". Known values
include:
"clock"-- Produces blocks at regular time intervals based onslot_time."transaction"-- Produces a new block for each incoming transaction.
Example:
toolchain
Override toolchain data in the workspace similar to
rust-toolchain.toml.
package_manager
The package_manager field indicates which package manager Anchor should use
for all of its client and workspace commands.
Valid values
include npm, yarn, pnpm, and bun.
Anchor will default to yarn, if a value is not specified. Note values should
be in lowercase, since values are deserialized with
serde(rename_all = "lowercase").
Example:
hooks
The hooks table allows you to configure commands that may be run at specific
stages of the build/test/deploy pipeline.
Example:
registry (removed)
The [registry] section is no longer supported and has been removed in 1.0.0.
If your Anchor.toml contains this section, remove it: