Contents
- Requirements
- Start devnet
- Auto-deploy
- Pre-funded accounts
- Development workflow
- Stop devnet
- When to use devnet
- Limitations
Requirements
Verify with:
Start devnet
- Bitcoin node
- Stacks node
- Frontend at
http://localhost:3000 - File watcher for auto-regeneration
- Chain health monitoring (prefixed
[dev]logs)
Auto-deploy
Deploy once the local chain is healthy. No second terminal required.Pre-funded accounts
Devnet includes pre-funded accounts incontracts/settings/Devnet.toml:
Development workflow
- Edit
.clarfiles. Bindings regenerate automatically. - ABI cache in
contracts/.cache/skips unchanged work. - Deploy with
--auto-deployorstacksdapp deploy --network devnet. - Test with pre-funded accounts.
NEXT_PUBLIC_NETWORK=devnet in frontend/.env.local. If you deployed to testnet instead, use stacksdapp dev --network testnet.
Stop devnet
- Ensure Docker is running
- Stop conflicting containers:
docker ps --filter name=devnet -q | xargs docker stop stacksdapp clean --force- Retry
stacksdapp dev --auto-deploy
When to use devnet
- Complex multi-contract interactions
- Bitcoin-specific features (sBTC, block data)
- Offline development
- Full stack simulation
Limitations
- Slower than testnet (Docker overhead)
- No real economic incentives
- Limited to local machine
- Long idle devnet sessions can stall around Stacks block ~71 (PoX / signer timeout). Prefer
--auto-deployor use testnet for deploy verification - Devnet
bitcoin_controller_block_timeis set to 45s to allow Nakamoto signer time through PoX reward-cycle transitions