eth-brownie/brownie: A Python Smart Contract Framework That Is No Longer Actively Maintained

The gap Brownie fills for Python developers on the EVM

Most Ethereum tooling is JavaScript-first. Hardhat, Truffle and Foundry each assume a particular language ecosystem for tests and scripts. Brownie targets teams whose existing code, data pipelines and CI are already Python. It compiles Solidity contracts from version 0.4.22 upward and Vyper contracts from 0.1.0-beta.16 upward, then exposes them to pytest as fixtures. The README lists trace-based coverage evaluation, property-based and stateful testing through hypothesis, python-style tracebacks with custom error strings, and a built-in console for quick project interaction. That combination is the pitch: you write tests in the same language as the rest of your stack, and when a transaction reverts you read a Python traceback rather than decoding a raw revert payload by hand. The audience is narrow but real. If your team already runs pytest and wants contract tests to sit alongside the rest of the suite, Brownie removes a language boundary. If your team is JavaScript-native or wants the fastest possible local EVM, this is not the tool the README recommends.

How the compile, test and console loop actually fits together

The architecture visible in the repository is a Python package that wraps several external pieces. Compilation goes through py-solc-x and py-solc-ast, with vvm and vyper pinned for Linux installs according to pyproject.toml. Chain interaction goes through web3.py, pinned at 7.15.0 for macOS and Linux. Testing is delegated to pytest, and the project ships a pytest plugin, which is why the README tells contributors running the suite directly to pass -p no:pytest-brownie to prevent the plugin from loading. Hypothesis is pinned below 6.28.0 in the runtime dependency group, which is what backs the property-based and stateful testing features. The console and CLI are compiled with mypyc for CPython users, and setup.py shows that BROWNIE_NOCOMPILE switches the install to interpreted Python. The data flow is conventional: source files compile to artifacts, artifacts load into a project object, tests and scripts call contract methods through web3.py, and the RPC client executes them. The interesting design choice is that Brownie does not ship its own EVM. It expects hardhat or ganache to be present, and the README states it is tested with ganache 7.9.2 while recommending hardhat because ganache has been sunsetted. That dependency is the framework's soft spot, not its contract handling.

Installing eth-brownie with pipx and running a first project

The README recommends pipx because it installs Brownie into its own virtual environment and exposes the command directly, so you never activate an environment before using it. First install pipx itself, then Brownie.

python3 -m pip install --user pipx
python3 -m pipx ensurepath
pipx install eth-brownie

After that, brownie should be on your PATH. Upgrades go through the same tool.

pipx upgrade eth-brownie

If you prefer pip, the README gives that route as well, and it is the simpler one inside an existing virtual environment.

pip install eth-brownie

There is also a library mode for embedding Brownie in another project. Setting BROWNIE_LIB=1 before the pip install loosens the pins on all dependencies, and the README warns that you should maintain your own requirements.txt so upstream upgrades do not surprise you. That warning is worth taking literally: the pinned set in requirements.txt is large and includes eth-account, eth-event, faster-eth-utils and web3, so unpinning them shifts a lot at once.

export BROWNIE_LIB=1
pip install eth-brownie

With the CLI installed, create a folder and initialize a project inside it. The README's quick usage is two commands.

brownie init
brownie --help

brownie init creates the project skeleton, and brownie --help lists the available subcommands. From there the console is the fastest way to confirm that Brownie can reach a chain.

brownie console

If you are running an RPC client in Docker, the README shows how to attach to it. Start the client, then point Brownie at it, either directly through the console or by registering a named network.

docker run -p 8545:8545 trufflesuite/ganache-cli
brownie networks add Development dev cmd=ganache-cli host=http://ganache:8545
brownie console --network dev

The named network is the part worth remembering. Once dev is registered, every later brownie console --network dev call reuses the same host and command, which keeps test invocations consistent across machines.

The maintenance question the README answers directly

The README contains an unusual sentence for a project page: Brownie is no longer actively maintained, and future releases may come sporadically or never at all. It then points readers to Ape Framework. That is the project's own position, and it should outweigh any inference from release timing. The repository is not archived, and the last push was on 2026-08-05, with releases v1.22.0 on 2026-05-25, v1.22.1 on 2026-06-06 and v1.22.2 on 2026-06-21. So there is recent activity. But recent commits are not the same claim as a maintained project, and the maintainers have explicitly declined the latter. For a team choosing a framework for a multi-year codebase, that statement is the deciding fact. It does not mean the code stops working. It means nobody has committed to fixing it when a dependency breaks, and the dependency graph here is deep: web3, eth-account, eth-event, eip712 and a set of faster-* packages that are pinned to exact versions in the build requirements. A breaking change in any of them is now the user's problem.

Where Brownie is the wrong choice

The clearest failure mode is greenfield adoption. Starting a new project on a framework whose own README says it is no longer actively maintained means accepting that upstream breakage may go unfixed, and the README itself redirects you to Ape Framework. A second limitation is platform coverage. The build configuration in pyproject.toml excludes ckzg and pydantic-core on Windows and on 32-bit Linux in specific cases, and several pins (web3, vyper, vvm) apply only to macOS or Linux. If your developers are on Windows, the install path is less certain than the README's short pipx instructions suggest. A third issue is the RPC client. Brownie does not include an EVM. It expects hardhat or ganache to be installed and running, and the README notes ganache has been sunsetted while still being the version Brownie was tested against. That leaves you with a supported recommendation (hardhat) and a tested configuration (ganache 7.9.2) that do not match. Finally, the dependency pins are tight by design. The README's own development notes say even small upgrades of patch versions have broken things in the past, which is a candid admission that the pinned set is load-bearing rather than incidental.

Ape Framework and the difference in approach

The README names Ape Framework as the destination for Python Ethereum development. The practical difference is one of scope and packaging. Brownie is a framework that wraps web3.py and delegates compilation and execution to external tools, with pytest as the test runner and a pinned dependency set to keep the combination stable. Ape is positioned by the Brownie README as the continuation of the same Python-first idea, and it has its own plugin system for compilers, chain providers and account handling. The distinction that matters for a migration decision is that Brownie's plugin surface is not the same as Ape's, so existing brownie-config.yaml settings, custom network definitions and any project scripts that import Brownie internals do not carry over unchanged. The README does not document a migration path, so treat the move as a port rather than an upgrade. For teams with a small, self-contained test suite that only uses the fixture API and the console, the port is bounded. For teams that have built tooling on top of Brownie's internals, it is a project.

Licence and the cost of staying on a pinned dependency set

Brownie is licensed under the MIT license, per the README and the LICENSE file in the repository root. MIT is permissive: it allows commercial use, modification and redistribution, and it requires that the copyright notice and licence text be preserved. It does not impose copyleft obligations on your own code. This is not legal advice, and the usual caveat applies: if you are redistributing Brownie itself or bundling it into a product, have counsel read the LICENSE file rather than this summary. The upgrade cost is the more practical concern. The build requirements pin mypy to 1.19.0, hypothesis to 6.27.3, web3 to 7.15.0 on macOS and Linux, and a long list of eth-* packages to exact versions. The README describes the upgrade procedure for maintainers: uv lock --upgrade followed by uv export to regenerate requirements.txt, with a warning to run all tests afterwards because patch-level bumps have broken things before. If you are a consumer rather than a maintainer, that procedure is not available to you in the same way. You either accept the pinned set as it ships or you fork and run the upgrade yourself, and the second option means owning the test run that the maintainers used to own.

Editorial conclusion

Adopt Brownie for existing projects that already depend on its pytest fixtures, console and traceback output, and for developers who want a Python-first EVM workflow without rewriting a working suite. Do not adopt it for greenfield work: the README states it is no longer actively maintained and points to Ape Framework. Before committing, verify that the pinned dependencies in requirements.txt still resolve on your Python version, that your chosen RPC client (hardhat or ganache) is installed, and that a small brownie test run passes end to end.

Frequently asked questions

Official sources

1. eth-brownie/brownie on GitHub
2. License: MIT
3. Project website
4. README
5. Releases