What's New
Upgrade Guide
The Basics
The Craft Command
The Craft Command
Architectural Concepts
Useful Features
Orator ORM
Managers and Drivers
Official Packages
Masonite Essentials
How-to Guides

Masonite 1.6 to 2.0

Masonite 2 brings an incredible new release to the Masonite family. This release brings a lot of new features to Masonite to include new status codes, database seeding, built in cron scheduling, controller constructor resolving, auto-reloading server, a few new internal ways that Masonite handles things, speed improvements to some code elements and so much more. We think developers will be extremely happy with this release.

Upgrading from Masonite 1.6 to Masonite 2.0 shouldn't take very long although it does have the largest amount of changes in a single release. On an average sized project, this upgrade should take around 30 minutes. We'll walk you through the changes you have to make to your current project and explain the reasoning behind it

Application and Provider Configuration

Masonite 2 adds some improvements with imports. Previously we had to import providers and drivers like:

from masonite.providers.UploadProvider import UploadProvider

Because of this, all framework Service Providers will need to cut out the redundant last part. The above code should be changed to:

from masonite.providers import UploadProvider

Masonite 2 brings a more explicit way of declaring Service Providers in your application. You'll need to take your current PROVIDERS list inside the config/ file and move it into a new config/ file.

Now all Service Providers should be imported at top of the file and added to the list:

from masonite.providers import (
# Framework Providers

String providers will still work but it is not recommended and will not be supported in current and future releases of Masonite.

WSGI changes

There are a few changes in the file and the bootstrap/ file.

In the file we should add a new import at the top:

# from pydoc import locate - Remove This
from config import application, providers
container.bind('WSGI', app)
container.bind('Application', application)
# New Additions Here
container.bind('ProvidersConfig', providers)
container.bind('Providers', providers)
container.bind('WSGIProviders', providers)

Then change the code logic of bootstrapping service providers from:
for provider in container.make('Application').PROVIDERS:
for provider in container.make('Application').PROVIDERS:
located_provider = locate(provider)().load_app(container)
if located_provider.wsgi is False:

for provider in container.make('ProvidersConfig').PROVIDERS:
located_provider = provider()
if located_provider.wsgi:

and change the logic in bootstrap/ to:

for provider in container.make('WSGIProviders'):

Notice here we split the providers list when the server first boots up into two lists which significantly lowers the overhead of each request.

This change should significantly boost speed performances as providers no longer have to be located via pydoc. You should see an immediate decrease in the time it takes for the application to serve a request. Rough time estimates say that this change should increase the request times by about 5x as fast.

Duplicate Class Names

Again, with the addition of the above change, any place you have a duplicated class name like:

from masonite.drivers.UploadDriver import UploadDriver

You can change it to:

from masonite.drivers import UploadDriver


Renamed Request.redirectTo to Request.redirect_to. Be sure to change any of these instances accordingly.

All instances of:

return request().redirectTo('home')

should be changed to:

return request().redirect_to('home')

Redirect Send Method

Also removed the .send() method completely on the Request class so all instances of:

def show(self):
return request().redirect('/dashboard/@id').send({'id':})

Need to be changed to:

def show(self):
return request().redirect('/dashboard/@id', {'id':})

CSRF Middleware

Some variable internals have changed to prepend a double underscore to them to better symbolize they are being handled internally. Because of this we need to change any instances of csrf_token to __token in the CSRF Middleware file.

You can check for what the class should look like from the MasoniteFramework/masonite repository


Masonite 2 comes with a new autoloader. This can load all classes in any directory you specify right into the Service Container when the server first starts. This is incredibly useful for loading your models, commands or tasks right into the container.

Simply add a new AUTOLOAD constant in your config/ file. This is the entire section of the autoload configuration.

| Autoload Directories
| List of directories that are used to find classes and autoload them into
| the Service Container. This is initially used to find models and load
| them in but feel free to autoload any directories

By default this points to the app directory where models are stored by default but if you moved your models to other directories like app/models or app/admin/models then add those directories to your list:


Be caution that this will autoload all models into the Service Container with the class name as the key and the class as the binding.


Because of a minor rewrite of the Request class, we now do not need the RedirectionProvider. You can remove the RedirectionProvider completely in your PROVIDERS list.


There is a new status code provider which adds support for adding custom status codes and rendering better default status code pages such as 400 and 500 error pages. This should be added right above the StartResponseProvider:

# Framework Providers
# New provider here above StartResponseProvider

.env File

The .env got a small upgrade and in order to make the APP_DEBUG variable consistent, it should be set to either True or False. Previously this was set to something like true or false.

# or

Masonite 2 also removed the APP_LOG_LEVEL environment variable completely.


That's it! You're all done upgrading Masonite 1.6 to Masonite 2.0. Build something awesome!

Be sure to read about all the changes in Masonite 2 to ensure that your application is completely up to date with many of the latest decisions and be sure to thoroughly test your application. Feel free to open an issue if any problems arise during upgrading.