This documentation is for Dash Enterprise.
Dash Enterprise is the fastest way to write & deploy Dash apps and
Jupyter notebooks.
10% of the Fortune 500 uses Dash Enterprise to productionize AI and
data science apps. Find out if your company is using Dash Enterprise.
Environment variables are config values that affect the way your app behaves. They are helpful
for situations when you need your app to behave differently depending on the environment. For example,
you might want your app to use one database when running in a certain environment, and a different database otherwise.
Dash Enterprise provides a way for you to set environment variables in the App Manager. By entering the environment variable name and value in Dash Enterprise, your app can use it without storing the value in code.
We recommend storing sensitive information like API keys as environment variables.
Because the key is not hardcoded in your app’s code, you don’t run the risk of mistakenly exposing or sharing it.
There are two types of environment variables: App environment variables and global environment variables. App environment variables are specific to an app (and its workspace, if applicable) while global environment variables are available to all apps and workspaces on Dash Enterprise. App environment variables can be managed by app owners, co-owners, and administrators, while global environment variables can only be managed by administrators.
All environment variables are used by your app at build time as well as at runtime.
Some app environment variables are created automatically when you perform certain actions. In addition to these, you can add and manage your own app environment variables.
This page describes how to manage app environment variables using the Settings in the App Info, but you can also use the Dash Enterprise CLI.
The following app environment variables are created automatically by the system. They cannot be edited or deleted.
DASH_APP_NAME, DASH_REQUESTS_PATHNAME_PREFIX, DASH_PATH_ROUTING, and DASH_ROUTES_PATHNAME_PREFIX are
created automatically when you create an app. These environment variables are used by Dash when you construct paths using
dash.get_relative_path, dash.strip_relative_path, or dash.get_asset_url. You don’t need to reference them anywhere in your code.
GIT_REV is created automatically the first time you update your code and stores your app’s latest Git revision.
It’s the long-form version of the git revision displayed in your app Overview. You can use this environment variable in conjunction with cache_by
to enable advanced functionalities like persisting the cache across redeploys and invalidating it when the app’s source changes.
Learn more in Background Callback Caching.
REDIS_URL and DATABASE_URL are created automatically when you add a managed Redis or Postgres database to your app,
respectively. You’ll need to reference these environment variables in your code for your app to use these databases. Learn more in
Redis and Postgres.
DASH_SECRET_KEY is created automatically when you create an app. It is used by the system to allow requests that originate from Snapshot Engine background tasks
when the app is protected by dash-enterprise-auth.
GUNICORN_CMD_ARGS is created automatically with the value --limit-request-field_size=16384, which sets the header size limit to 16 KB.
You can override this limit by specifying one in your Procfile. For example, to set it back to the Gunicorn default of 8 KB:
```
web: GUNICORN_CMD_ARGS=”–limit-request-field_size=8190” gunicorn app:server –workers 4
```
Learn more about this flag in the Gunicorn documentation.
DASH_ENTERPRISE_ENV is created automatically with the value WORKSPACE when you create a workspace for your app.DASH_ENTERPRISE_ENV when deploying your app, so it does not appear in your app’s Environment Variables settings.The environment variable for specifying a pip version,
BP_PIP_VERSION, can also be set in a project.toml file. When it is set in both your app Settings and aproject.tomlfile, the values in the Settings take precedence.
To add an environment variable to your app:
<img>
If your environment variable names contain more than one
word and you want to separate them, be sure to use underscores. Spaces are not supported.
<img>
In this example, we’ve added credentials for a service using environment variables named SERVICE_USER and SERVICE_PASSWORD.
Select Save. You are prompted to restart the app and its workspace (if one exists).
Select Restart App and Workspace.
Once added, the values for your environment variables are hidden unless you
select Show Values.
You can now reference your environment variables in your app’s code with the os.environ module:
import os
service_username = os.environ['SERVICE_USER']
If you want to fall back to another value when the variable isn’t in your
environment, use:
import os
service_username = os.environ.get('SERVICE_USER', 'my-default-service-username')
Tip: Environment variables are case sensitive. Be sure to reference them exactly as they appear in the App Info.
If you’re working locally, the variables won’t be in your environment
unless you define them. You can define them on-the-fly when you run python app.py.
That is, instead of running python app.py, run:
$ SERVICE_USER=admin SERVICE_PASSWORD=my-password python app.py
replacing the example environment variables with the environment variables you want to define.
Alternatively, you can define them for your session with the export command.
For example:
$ export SERVICE_USER=admin
$ export SERVICE_PASSWORD=my-password
$ python app.py
Tip: Environment variables are case sensitive. Be sure to reference them exactly as they appear in the App Info.
To edit an app environment variable:
If your environment variable names contain more than one
word and you want to separate them, be sure to use underscores. Spaces are not supported.
To delete an app environment variable:
<img>
Under your app environment variables, you’ll see Global Environment Variables. These environment variables are managed by your administrator. You can use them in your app in the same way that you would use your own app environment variables.
However, you cannot see their values.
<img>
If your app has an app environment variable that shares a name with a global environment variable, your app environment variable takes precedence.
When your administrator edits or deletes a global environment variable, a notification is displayed at the top of the App Info. The updated global environment variables are identified with a blue dot and bold font in the global environment variables list. Restart or redeploy your app, or rebuild your workspace for them to get the latest changes. When your administrator deletes a global environment variable, it is displayed in Recently Deleted until you restart or redeploy your app.
Adding, editing, and deleting global environment variables are administrator actions and require the admin role.
Global environment variables are available to all apps and workspaces on Dash Enterprise.
App developers can use global environment variables in the same way that they use app environment variables.
If you need to define a private Python package index using
PIP_EXTRA_INDEX_URL, do not add it as a global environment variable. Instead, use the provided setting in the KOTS Admin Console. See Configuring a Private Python Package Index for All Apps.
To add a global environment variable:
DASH_ or DE_ are reserved by Plotly and cannot be used.<img>
When editing global environment variables, only the values and descriptions can be modified. If you need to modify a global environment variable’s name, delete it and create a new one.
To edit a global environment variable:
<img>
Information about recently updated global environment variables is displayed to app developers so that they know to restart any apps or workspaces that are using them.
To delete a global environment variable:
<img>
Information about recently deleted global environment variables is displayed to app developers so that they understand why their app might behave differently or clean up unused code.
Deleted global environment variables stop being available to apps when the apps are restarted or redeployed. They stop being available to workspaces when the workspaces are rebuilt.