Masonite Documentation
v4.0
v4.0
  • Introduction and Installation
  • Prologue
    • Creating A Blog Tutorial
    • Release Cycle
    • Contributing Guide
    • How To Contribute
  • The Basics
    • Routing
    • Controllers
    • Middleware
    • Response
    • Request
    • Static Files
    • Views
    • Environments
    • Configuration
    • Error Handling
  • Features
    • API Development
    • Authentication
    • Authorization
    • Broadcasting
    • Caching
    • Compiling Assets
    • Commands
    • CSRF Protection
    • Events
    • Facades
    • Filesystem and Uploading
    • Hash ID's
    • Helpers
    • Mail
    • Notifications
    • Package Development
    • Queues and Jobs
    • Rate Limiting
    • Sessions
    • Task Scheduling
    • Tinker Shell (REPL)
    • Validation
  • Architecture
    • Service Providers
    • Service Container
  • Security
    • CORS
    • Hashing
  • Masonite ORM
    • To Masonite ORM Docs
  • Testing
    • Getting Started
    • HTTP Tests
    • Database Tests
    • Commands Tests
    • Console Tests
    • Mocking
    • Extending
  • Official Packages
    • Masonite Debugbar
  • How-to Guides
    • Handling AJAX requests with expired authentication
    • Build Email Verification from Scratch With Masonite Framework and JSON Web Tokens
    • Deploying a Masonite Application to Heroku
    • How To Deploy Masonite to PythonAnywhere
    • How-To: Use RabbitMQ with Masonite 2.0 queues
    • How To Use The Repository Pattern with Masonite
    • Making Masonite and Laravel Mix work together
  • What's New
    • Masonite 1.3
    • Masonite 1.4
    • Masonite 1.5
    • Masonite 1.6
    • Masonite 2.0
    • Masonite 2.1
    • Masonite 2.2
    • Masonite 2.3
    • Masonite 3.0
  • Upgrade Guide
    • Masonite 1.3 to 1.4
    • Masonite 1.4 to 1.5
    • Masonite 1.5 to 1.6
    • Masonite 1.6 to 2.0
    • Masonite 2.0 to 2.1
    • Masonite 2.1 to 2.2
    • Masonite 2.2 to 2.3
    • Masonite 2.3 to 3.0
    • Masonite 3.0 to 4.0
Powered by GitBook
On this page
  • Getting Started
  • Getting Value
  • Setting Value
  • Overriding Value
Edit on GitHub
Export as PDF
  1. The Basics

Configuration

Configuration files in Masonite are gathered in one folder named config in default projects.

Each feature can have some options in its own file named after the feature. For example you will find mail related options in config/mail.py file.

Getting Started

The Configuration class is responsible for loading all configuration files before the application starts.

It will load all files located at path defined through config.location binding which default to config/.

Then values are accessed based on the file they belong to and a dotted path can be used to access nested options.

Given the following config/mail.py file:

from masonite.environment import env

FROM_EMAIL = env("MAIL_FROM", "no-reply@masonite.com")

DRIVERS = {
    "default": env("MAIL_DRIVER", "terminal"),
    "smtp": {
        "host": env("MAIL_HOST"),
        "port": env("MAIL_PORT", "587"),
        "username": env("MAIL_USERNAME"),
        "password": env("MAIL_PASSWORD"),
        "from": FROM_EMAIL,
    }
}
  • Accessing mail will return a dictionary with all the options.

  • Accessing mail.from_email will return the FROM_EMAIL value

  • Accessing mail.drivers.smtp.port will return the port value for smtp driver.

Getting Value

To read a configuration value one can use the Config facade:

from masonite.facades import Config

Config.get("mail.from_email")
# a default value can be provided
Config.get("database.mysql.port", 3306)

or the config helper:

from masonite.configuration import config

config("mail.from_email")
# a default value can be provided
config("database.mysql.port", 3306)

Setting Value

Setting configuration values is achieved through projet configuration files.

Overriding Value

However, you can override on the fly a configuration value with the Config facade:

Config.set("mail.from_email", "support@masoniteproject.com")

This should be done sparingly as this could have unexpected side effects depending at which time you override the configuration option.

This is mostly useful during tests, when you want to override a configuration option to test a specific behaviour:

    def test_something(self):
        old_value = Config.get("mail.from_email")
        Config.set("mail.from_email", "support@masoniteproject.com")

        # test...

        Config.set("mail.from_email", old_value)
PreviousEnvironmentsNextError Handling

Last updated 2 years ago

But if you simply want to have different configuration depending on the environment (development, testing or production) you should rely instead on used to define configuration options.

environment variables