# Masonite 4, retired on purpose: reading a Python framework after the handoff

> The MasoniteFramework/masonite repository stopped at version 4.20.4 and moved development elsewhere. What the pinned dependencies, build targets and sunset notice actually say about picking it up.

**MasoniteFramework/masonite** — The Modern And Developer Centric Python Web Framework. Be sure to read the documentation and join the Discord channel for questions: https://discord.gg/TwKeFahmPZ

- Repository: https://github.com/MasoniteFramework/masonite
- Website: http://docs.masoniteproject.com
- Stars: 2,360 · Forks: 135
- Language: Python
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/masoniteframework-masonite

## A retirement notice that shipped alongside the final release

The first thing the README says is that the repository is no longer maintained. It states that development continues at masonitedev/masonite, that Masonite 5 is published on PyPI under a different distribution name, and that this repository covers Masonite 4 and earlier and will receive no further updates, security fixes included.

The last push recorded for the repository is 2026-06-07, and the final release v4.20.4 carries the same date. Those two facts sit next to each other without needing a contradiction: the last activity was the retirement itself. Release v4.20.3 predates it by more than a year, on 2025-03-01, and v4.20.2 is from 2024-10-25. A reader looking for signs of life will find exactly one, and it is the one announcing the end.

The release body is unusually specific about what the last version contains, which makes it the best single page in the repository. It lists fixes pending on the 4.0 branch since v4.20.2: response streaming, a queueable notifications fix, an add_query_params fix, a Vonage pin and the dropping of Python 3.7 support. It also records that importing the package now emits a FutureWarning pointing at the successor package and at an upgrade guide.

GitHub reports one open issue on a repository with 2,358 stars and 134 forks. That number is consistent with a codebase in maintenance-only mode: there is no backlog of unaddressed reports, and also no one working through new ones.

## Installing Masonite 4 and starting the craft server

The getting started section is four lines long and still installs the retired distribution. It asks for a working Python 3.11 or older installation, which matters because the successor targets newer interpreters.

```bash
pip install masonite
project start .
python craft serve
```

The distribution name is the important line. The README says Masonite 5 is published as masonite-framework, so `pip install masonite` gives you the frozen line, not the maintained one. A reader who copies these three lines without reading the banner gets a working but retired install, and the FutureWarning emitted at import time is the only signal they will get.

The second command, `project start .`, suggests a scaffolding step rather than a hand-written application. The repository tree supports that reading: it contains a `craft` file at the root, along with `wsgi.py`, `.env-example`, `pytest.ini` and a checked-in `database.sqlite3`. A starter project shape, not a framework package layout. The `src/` directory holds the actual importable code, and `setup.py` confirms it with `package_dir={"": "src"}`.

The repository also carries `WHITEPAPER.md` and `SECURITY.md` at the root. A security policy on a project that explicitly will not ship security fixes is worth reading for what it promised and what it now cannot keep.

## What the framework claims to do out of the box

The feature list in the README is short and specific, which is more informative than a long one. Mail support for sending mail, a queue for running jobs asynchronously, notifications, task scheduling for recurring work, an event system with listeners, and an Active Record style ORM that the README calls Masonite ORM.

Those six items map cleanly onto the dependency list. `masonite-orm` appears in requirements.txt with a constraint of `>=2,<3`, so the ORM is a separate distribution pinned to a major version that no longer receives updates from this repository. Queues and scheduling in most Python frameworks sit on a task backend, and the pinned `celery` alternative here is `cleo>=0.8.1,<0.9`, a small scheduler library. Mail goes through `vonage>=3,<4`, which also explains why the final release notes mention a Vonage pin as one of the last fixes.

The ORM being external is the single most consequential detail in the file. Masonite is not self-contained at the data layer, so a reader auditing the framework has to audit a second repository for the part of the stack most likely to touch a database. The README's own words, that many more features can be found in the docs, are true in the unhelpful direction: the list above is the summary, not the system.

Two documentation links reinforce the point. The banner points at docs.masonite.dev for the maintained documentation and at an upgrade guide covering the 4.0 to 5.0 move. The getting started section, further down the same file, still links to docs.masoniteproject.com, which is also the homepage recorded in the repository metadata. Two domains for one project in a single README is a small thing that costs a reader a search to resolve.

## Pinned dependencies describe a 2024 release line

requirements.txt is the most dated part of the repository, and reading it is how you get a real sense of what you would be inheriting. The constraints are not floor values with no ceiling. They are narrow ranges that lock major versions:

- `cryptography>=36,<37`, pinning the library to a single 3.x major
- `jinja2<3.2`, holding the template engine below a specific patch
- `pendulum>=2,<3` for date handling
- `python-dotenv>=0.15,<0.16`, a very tight range on the environment loader
- `pyjwt>=2.4,<2.5` for token work
- `hupper>=1.10,<1.11` and `dotty_dict>=1.3.0,<1.40` for HTTP and dictionary helpers
- `tldextract>=2.2,<2.3`, `watchdog>=2,<3` and `whitenoise>=5.2,<5.3`
- `argon2-cffi`, `bcrypt>=3.2,<3.3`, `inflection>=0.3,<0.4` and `hashids>=1.3,<1.4`
- `vonage>=3,<4` and `slackblocks` for outbound messaging

The werkzeug line is the interesting one, because it encodes the Python version story directly:

```
werkzeug>=2,<3; python_version < '3.8'
werkzeug>=3,<4; python_version >= '3.8'
```

That is a distribution still carrying support for interpreters below 3.8, which matches the final release note about dropping Python 3.7. The combination is consistent, and it is also the clearest statement of the project's age: the packaging was written to span interpreter versions that were already out of common use before the last release.

A reader who installs this today gets a resolver problem rather than a security problem. Those ranges will conflict with anything modern in the same environment, and `cryptography>=36,<37` in particular constrains a native dependency. This is the practical cost of the retirement, and it is worth checking before writing any code against it.

## Build, lint and coverage targets are still worth reading

The Makefile is short and it tells you how the project was actually worked on. The bootstrap target copies the environment template and installs the dependency file, then installs the project itself with its test extras:

```bash
init:
	cp .env-example .env
	pip install -r requirements.txt
	pip install '.[test]'
```

The test and continuous integration targets separate unit runs from integration runs, which is a mature convention:

```bash
test:
	python -m pytest tests
ci:
	python -m pytest tests -m "not integrations"
```

The lint target names a specific flake8 invocation and, more interestingly, a specific ignore list: `E501`, `F401`, `E203`, `E128`, `E402`, `E731`, `F821`, `E712`, `W503` and `F811`. Several of those, such as the line length exemption and the import shadowing rule, are choices a project makes when it values machine formatting over line discipline. The format target runs black over `src/masonite` and `tests/`, and the README badge confirms black as the code style.

The coverage targets are worth noting because they produce both a terminal report and an XML report, then pipe to coveralls, and a separate `show` target writes an HTML report. A project that had four coverage variants wired up was being tested seriously right up to the end.

The publish target shows the release shape: build an sdist with `python setup.py sdist`, upload with twine, then remove `build`, `dist` and the egg-info directory. There is no wheel step. For a package that declares itself Python 3.7 through 3.11 era, an sdist-only release is consistent, and it is also the reason an install from source may compile something on your machine.

## What this repository settles and what it leaves to the docs

The repository settles three things cleanly. First, the licensing: MIT, declared in both the README and setup.py, with a LICENSE file at the root. Second, the packaging shape: a src layout, a setup.py that reads the version out of `src/masonite/__init__.py` at build time, and a MANIFEST.in for non-Python files. Third, the retirement itself, which is documented in three places consistently, the README banner, the SECURITY.md reference and the final release body.

It leaves the interesting questions elsewhere. Whether Masonite 4 is the right choice over the successor, what breaking changes the upgrade introduces, and what the documented features do in practice are all answered on docs.masonite.dev, not here. The README points at an upgrade guide for the 4.0 to 5.0 transition and at contributor documentation, both hosted off the repository.

The metadata adds one more small inconsistency. setup.py lists the project URL as the GitHub repository, and the author as Joe Mancuso. The README closes with an in-memory dedication to Joseph Mancuso, described as the creator of Masonite, and lists three core maintainers including him. A framework whose README memorialises its creator and whose repository announces it will never ship another security fix is telling you something about the project's shape that no dependency list will.

For a reader deciding today, the practical test is narrow. If you already run Masonite 4 in production, this repository tells you exactly how far you are from the upgrade and what the last set of fixes contained. If you are choosing a framework, the README has already made its own argument for you.

## Conclusion

This repository is worth reading for two reasons and adopting for neither. As a record it is unusually complete: a pinned requirements list, a Makefile with real lint and coverage targets, a security policy and a whitepaper in the tree, and a final release note that names the exact fixes shipping. As a dependency it is closed. The four commands in the README still work for someone who must stay on Masonite 4, but anyone starting fresh belongs on the masonite-framework package that the same README points to. Start at the upgrade guide rather than the getting started section, because the README's own quick start installs the retired package.

## FAQ

### Is the Masonite Python web framework still maintained?

Not in this repository. The README states that development continues at masonitedev/masonite and that Masonite 5 ships on PyPI as masonite-framework, while MasoniteFramework/masonite covers version 4 and earlier and will receive no further updates including security fixes. The final release there is v4.20.4, dated 2026-06-07.

### What package name should I install for current Masonite?

Two different names, depending on which line you want. The retired line installs as masonite and is capped at version 4.20.4. The maintained line installs as masonite-framework and carries the upgrade path forward from Masonite 4. The README's quick start still shows the older name, so the banner at the top is the part to read first.

### Is Masonite ORM part of the Masonite framework repository?

No. requirements.txt lists masonite-orm as a separate distribution constrained to a version range of >=2,<3. That matters for anyone auditing the framework, because the data access layer lives in its own project rather than inside this codebase.

### Which Python versions does Masonite 4 support?

The README asks for a working Python 3.11 or older. The dependency file carries a werkzeug constraint split on python_version below 3.8, which is consistent with the final release note about dropping Python 3.7. Those narrow dependency ranges are the more likely obstacle to a modern install.

## Sources

- [License: MIT](https://github.com/MasoniteFramework/masonite/blob/4.0/LICENSE)
- [MasoniteFramework/masonite on GitHub](https://github.com/MasoniteFramework/masonite)
- [Project website](http://docs.masoniteproject.com)
- [README](https://github.com/MasoniteFramework/masonite/blob/4.0/README.md)
- [Releases](https://github.com/MasoniteFramework/masonite/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/masoniteframework-masonite