from dynaconf import settings
Tags: python, django, flask, 12factorapp
Published: 2019-04-12 16:40:11

---
title: from dynaconf import settings
published: true
description: The only line of code you need to manage your Python 3 configurations
tags: python,django,flask,12factorapp
---


Often when starting a new Python project we need to spend some time thinking about how to manage the settings, decide on which module the configuration manager will be written, decide which name to give to this module, create a class or function to store the configuration keys, create the conditions for multiple environments and still need to worry about where these keys will be stored and in which file format?

No more! now you have [Dynaconf](http://github.com/rochacbruno/dynaconf)!

{% github rochacbruno/dynaconf %}

Spend your precious time developing your application, run `pip install dynaconf` and let Dynaconf take care of your settings.


## Quick start.


```python
from dynaconf import settings
```

And that's it! 

That is the only line of code you need, no complicated boilerplate, no [hadouken-ifs](https://i.imgur.com/rxxTUoe.jpg), no need to maintain config classes.

You must be wondering - **"What magic is this? Where does the setting values come from?"**

Well, there is no magic, and the values can come from wherever you want, by default and following the recommendations of the [12 factor apps]() Dynaconf has preference for environment variables.

```bash
# optionally you can save it in .env file
export DYNACONF_DEBUG=true
export DYNACONF_NAME=Bruno
```
```python
# app.py
from dynaconf import settings
if settings.DEBUG is True:
    print(settings.NAME)
```
```bash
$ python3 app.py
Bruno
```

> And the environment variables for Dynaconf are typed using the `toml` format so` true` has been evaluated to boolean `True` and this makes it possible to export lists, dictionaries, floats, booleans, and so on.

[Read more about envvars](https://dynaconf.readthedocs.io/en/latest/guides/environment_variables.html)


## More than environment variables

Well, that's cool, but your project will not have settings coming from just the environment variables, I'm sure you want to have a settings file where you can set  default values.


Dynaconf can read multiple file formats, out of the box it supports `.py`, `.toml`, `.ini` and `.json`. If `PyYAML` is installed then it will also support `.yaml` and you don't have to take care of finding and opening the files. The preferred format is `.toml` because it is currently the best configuration format, widely addopted, and you can use whatever file format you want.


```toml
# settings.toml
[default]
name = "Bruno"

[development]
debug = true

[production]
debug = false
```
```python
# app.py
from dynaconf import settings
if settings.DEBUG is True:
    print(settings.NAME)
```
```bash
$ python3 app.py
Bruno
```

And as you can see now using `settings.` file we can have separate `[environments]` by default dynaconf will always work on `[development]` which means only `[default]` and `[development]` variables will be loaded. At any time you can do `export ENV_FOR_DYNACONF=production` and then it starts using the values from `[production]` environment.

> If you don't want to have that separation by environment, you can simply put everything under `[default]` section.

Read more about [environments and settings file](https://dynaconf.readthedocs.io/en/latest/guides/usage.html#working-environments)


## Some values are secrets

A good practice is to not store your **secrets** like **passwords** and **tokens** directly on settings files, because you can make a mistake and commit that to a public git repository, so there are some alternatives to store **secrets**

### Environment Variables

> Not recommended

There are some people who [disagrees](https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/) and it is really a point of security failure. However, if you are sure that your machine is protected, you can leave the secrets in the variables, at your own risk, Dynaconf can read it normally.

### Secret files

This is a simple level of security for keeping secrets, and it is specially useful to keep `development` secrets. That **token** you use to access the development API etc.

It is very simple, together with your normal `settings.toml` you put a new file called `.secrets.toml` and store your sensitive data there. Dynaconf will read it after the read of the `settings.toml`

Wait.. how does it solve my security problem?

Well it does not (yet) but it make your life easier in 2 ways.

1. Put `.secrets.*` in your `~/.gitignore` so you will never commit the mistake of sending that data to a public git repository.
2. Dynaconf can output debug information when `DEBUG_LEVEL_FOR_DYNACON=DEBUG` is exported, all loaded values are printed but if the values comes from a `.secrets.*` file, then only the key is printed and the value is masked. It is useful to use on public CI.
3. You can setup a step on your Ansible deployment playbook that will safely copy or generate the secrets file to store there on your production environment.

You can also tell Dynaconf to load that file from somewhere else `export SECRETS_FOR_DYNACONF=/path/to/secrets/location/.secrets.yaml` (very useful for CI like Jenkins)

### Vault Project from Hashicorp

> Recommended!

Now we are really talking about **true security** 

Using **Vault** is the better way to protect your secrets dynaconf has built-in support:

```bash
export VAULT_ENABLED_FOR_DYNACONF=true
export VAULT_URL_FOR_DYNACONF=https://..../
export OTHER_VAULT_CONFIGS
```

And then if have for example the `TOKEN` stores on your vault server you can simply do:

```python
from dynaconf import settings
perform_your_authentication(settings.TOKEN)
```

Vault has lots of features like leases and sealed vaults.

[Read More](https://dynaconf.readthedocs.io/en/latest/guides/sensitive_secrets.html)


## Are you using Django or Flask?

Dynaconf provides extensions for those 2 frameworks, with 2 lines of code you enable it and then your framework will start reading settings from Dynaconf.

### Django


```python
# settings.py
import dynaconf  # noqa
settings = dynaconf.DjangoDynaconf(__name__, **options)
```

Now you if you do `export DJANGO_FOO=BAR` you can access inside your app via `django.conf.settings.FOO`

[read more](https://dynaconf.readthedocs.io/en/latest/guides/django.html)

### Flask


```python
# app.py
from dynaconf import FlaskDynaconf
FlaskDynaconf(app, **options)
```

Now you if you do `export FLASK_FOO=BAR` you can access inside your app via `app.config['FOO']`

[read more](https://dynaconf.readthedocs.io/en/latest/guides/flask.html)


## What if you are using a different settings file format? a different framework and a different external storage?

> You can extend Dynaconf adding new loaders!

Dynaconf already provides loaders for:

- `.py`
- `.json`
- `.yaml`
- `.toml`
- `.ini`
- Redis Server
- Vault Server
- `.env` files
- Environment variables

But if this is not a fit for your project you can still [create your own loader](https://dynaconf.readthedocs.io/en/latest/guides/extend.html)


## Conclusion

> Dynaconf is the only thing you need to manage your settings!


- Well tested
- Trusted by companies like Red Hat, Seek, Catho and others
- Well tested both on Linux and Windows environment
- Strict separation of settings from code (following [12-factor applications](https://12factor.net/config) Guide).
- Define comprehensive default values.
- Store parameters in multiple file formats (**.toml**, .json, .yaml, .ini and .py).
- Sensitive **secrets** like tokens and passwords can be stored in safe places like `.secrets` file or `vault server`.
- Parameters can optionally be stored in external services like Redis server.
- Simple **feature flag** system.
- Layered **[environment]** system.
- Environment variables can be used to override parameters.
- Support for `.env` files to automate the export of environment variables.
- Correct data types (even for environment variables).
- Have **only one** canonical settings module to rule all your instances.
- Drop in extension for **Flask** `app.config` object.
- Drop in extension for **Django** `conf.settings` object.
- Powerful **$ dynaconf** CLI to help you manage your settings via console.
- Customizable **Validation** System to ensure correct config parameters.
- Allow the change of **dyna**mic parameters on the fly without the need to redeploy your application.

## Read the docs

> Settings are simple but Dynaconf provides even more features like **Feature Flags**, **Settings Context Managers**, **Plugin Settings** etc..

**Documentation**: http://dynaconf.readthedocs.io/

Dynaconf is waiting for your [feedback](https://github.com/rochacbruno/dynaconf/issues/155) and [Contribution](https://github.com/rochacbruno/dynaconf/issues)


:)

```python
from dynaconf import settings
settings.THANKS_FOR_READING
```