Preparing Your App for Dash Enterprise

Quickstart Checklist

Using FastAPI or Quart? Dash Enterprise supports these backends. See Server Backends for deployment instructions with uvicorn.

Consider the following items to ensure that your app will be successfully deployed to Dash Enterprise:

• Procfile: Ensure that your project folder has a Procfile. See App Structure for details. This is often:
  web: gunicorn app:server --workers 4
• requirements.txt: Ensure that your project folder has a requirements.txt file with the Python dependencies and versions. Don’t forget gunicorn! See App Structure for details.
• server = app.server: If your app uses Dash 3.0.4 or earlier, declare the underlying server variable to be referenced by the web command in your Procfile. See App Structure for details.
• Remove secrets and passwords: Remove sensitive passwords and API keys from your code and replace them with environment variables.
• System-Level dependencies: If your project requires system level dependencies like database drivers, then install those dependencies with a predeploy script and an Aptfile file. See App Structure.
• Self-contained: Ensure that all files and datasets that the app code references or saves are within the same project folder.

Additional Considerations

There are often differences between your local environment and
the containerized environment Dash Enterprise runs your app in.

These differences may include:

• Operating system and, in turn, available drivers and packages
• Data handling
• Authentication logic
• Timeout configuration
• Networking
• Resources available to the app (RAM, CPU, disk)

Python Version

The Python version that you use locally may be different from the default version configured by your administrator for Dash Enterprise.

For details on how to override the default version for your app, see the Deployed App Environment page.

Package Versions

Ensure that your local environment is using the same Python package versions as the deployed app by
providing version numbers in your requirements.txt file. See App Structure
for details.

Working with Large Data Files

If your app can read directly from data files (rather than a database or an API), then you have three options for reading these files in a deployed app:

• Commit the files into your project folder. Projects with large data files can become difficult to share between systems & people and so we recommend trying to keep your project less than 100MB. We recommend trying the Parquet data format to make your data files smaller and faster to read. A 200MB CSV can be saved as a 40MB Parquet file and read in 50ms instead of 3.5s.
• Use Dash Enterprise’s persistent filesystem, which provides persistent, fast storage for data files for apps and workspaces.
• Store the data on a cloud service like AWS S3 or Azure Blob Storage. Download the data files on-the-fly within a callback, on deployment with a postdeploy command, or in a background schedule with Celery while mapping the directories between containers (see “Ephemeral File Systems” below).

Working with Redis or Postgres

Dash Enterprise enables you to create and link Redis and Postgres databases to your app.
via the App Manager user interface.

Once linked, these databases are accessible within your code via:

• The REDIS_URL environment variable for the Redis database
• The DATABASE_URL environment variable for the Postgres database

Private Packages

If your app depends on private dependencies, see our
Private Packages Doc
for details.

Ephemeral File Systems

Each command listed in your Procfile is executed in a separate
container and containers have isolated file systems.

When you deploy a Dash app, it is run in a set of new containers.
Data that is written to the file system won’t necessarily be available
during the next deployment, nor will it be available between processes (like between the web process and the worker process).

To work around this limitation, you have three options:

• Save the data to an external data store.
• Save the data to a Redis or Postgres database in Dash Enterprise.
• Use Dash Enterprise’s persistent filesystem.

Authentication and Authorization

Apps deployed on Dash Enterprise can access the username of the currently logged-in visitor of the Dash app
via the dash-enterprise-auth (dea) package:

```python
from dash_enterprise_libraries import dea

@callback(…)
def update(…):
username = dea.get_username() # only available within callbacks
user_data = dea.get_user_data() # only available within callbacks
```

This data can be used to create row-level-security logic where the username is used within the Python logic
or the database query to display data associated with that particular user.

Request Timeouts

Apps deployed to Dash Enterprise have a 30-second request timeout by default.
This is to prevent long-running or stuck requests from preventing further requests.
If you have callbacks that take longer than 30 seconds to complete, your app users will encounter request timeouts.
To avoid this, you have a few options:

• Speed up your app code so that callbacks take less than 30 seconds to run.
• Split up long-running callbacks into multiple chained callbacks, storing intermediate data in a dcc.Store or
  in a server-side cache (see background callbacks)
• Use deployed app environment to run callbacks in a job queue.
• Increase two timeouts:
  a. The built-in proxy timeout in the Dash Enterprise Server Manager. Your admin will need to adjust this setting.
  b. The default gunicorn timeout with, e.g. gunicorn app:server --timeout 120.

Be aware of this method’s performance limitations: more CPU processes and workers will be utilized while
handling long-running requests, and it will be more likely that your app will “run out” of the
available CPU processes and workers while multiple users interact with your app. You will likely need to increase
the number of workers with gunicorn’s --workers argument.

Startup Timeouts

gunicorn is used to run your app on deployments. gunicorn has a default worker startup timeout of 30 seconds.

If your app takes longer than 30 seconds to boot-up (that is, to be ready to handle new requests), then the workers will timeout and restart.

To get around this, increase the boot-up timeout with the --timeout argument in your Procfile:

web: gunicorn app:server --timeout 60

URL Routing

Apps deployed to Dash Enterprise are accessible under a different path. That is, instead of accessing the app on localhost, you access the app at https://<your-dash-enterprise>.com/<your-dash-app-name>.

When dealing with anything to do with URLs and paths, we recommend using built-in functions instead of constructing the /<your-dash-app-name> path manually.
These functions account for the differences between path-less URLs in local environments and path-aware URLs in the Dash API reference.

These functions include:
- dash.get_relative_path() or app.get_relative_path() for creating paths used in links or assets.
- dash.strip_relative_path() or app.strip_relative_path() for stripping the relative path out of the path name (useful for multi-page app callbacks that respond to dcc.Location).

See the Dash Dev Tools Callback Graph for more information.

Network and Performance

After deploying your app to Dash Enterprise, you may notice your app feels slower than when running it locally.

Dash apps deployed on Dash Enterprise are on a different network than Dash apps running locally.
This can affect the performance of callbacks and the performance of any data fetching being done within your callback.

Callback Performance

The input, output, and state of a callback are transferred over the network.
When working locally, this data transfer is very fast.
When the app is deployed on a server, it takes longer to
transfer the data from the user’s browser to your callback and from your
callback to the user’s browser.

This is usually not noticeable unless your callbacks have large data structures as inputs (e.g. a dataframe stored in dcc.Store or the contents of a dcc.Upload component) or as outputs (e.g. large figure properties of dcc.Graph or large data properties of DataTable).

Diagnosing Callback Network Performance Issues

To investigate whether the performance issues are related to the network, we recommend:
- Viewing the data transfer (avg bytes) and time - network of callbacks via the Dash with Datashader. You can turn this on for your deployed app with:

python app.enable_dev_tools( dev_tools_ui=True, dev_tools_serve_dev_bundles=True, )
- Using the Network panel of your browser’s Development Tools to view the network transfer speed of the requests. Each callback will correspond to a POST /_dash-update-component. The contents of the request will indicate the inputs and, therefore which callback the request is associated with.

Improving Callback Network Transfer Performance

There are two ways to improve callback network transfer performance:

• Reduce the size of the inputs, outputs and state of a callback. This can be done with strategies like:

  • Aggregating or binning your data in Python before displaying it a dcc.Graph or dash_table.DataTable.
  • Using an alternative visualization routine that displays an aggregate or summary of data instead of every individual data point.
  • Visualizing aggregated data via Clientside callbacks.
  • Replacing dcc.Store or hidden divs with a server-side cache via the State.

• Reduce the number of times a callback is fired. This can be done with strategies like:

  • multiple outputs
  • Changing the UI to update less frequently from user interaction. For example, instead of updating on every keypress of a dcc.Input, update the UI when the user clicks a button and pass the value of the dcc.Input via test this by using a Dash Enterprise workspace.
  • Replacing dcc.Store or hidden divs with a server-side cache via the

Streamlit Apps

Quickstart Checklist

Consider the following items to ensure that your app will be successfully deployed on Dash Enterprise:

• Procfile - Ensure that your project folder has a Procfile. See App Structure for details. This is often:
  web: streamlit run app.py
• requirements.txt: Ensure that your project folder has a requirements.txt file with the Python dependencies and versions. See App Structure for details.
• Remove secrets and passwords: Remove sensitive passwords and API keys from your code and replace them with Environment Variables.
• System-level dependencies: If your project requires system level dependencies like database drivers, then install those dependencies with a predeploy script and an Aptfile file. See App Structure.
• Self-contained: Ensure that all files and datasets that the app code references or saves are within the same project folder.

Python Version

The Python version that you use locally may be different from the Python version used by Dash Enterprise.

For details on how to override the default version for your app, see the Deployed App Environment page.

Package Versions

Ensure that your local environment is using the same Python package versions as the deployed app by
providing version numbers in your requirements.txt file. See App Structure
for details.

Django Apps

Quickstart Checklist

Consider the following items to ensure that your app will be successfully deployed on Dash Enterprise:

• Procfile - Ensure that your project folder has a Procfile. See App Structure for details. This is often:
  bash web: gunicorn <your-django-app>.wsgi
• requirements.txt: Ensure that your project folder has a requirements.txt file with the Python dependencies and versions. Don’t forget to add gunicorn. See App Structure for details.
• urls.py: Remove Django Admin urls from your project’s urls.py file. For example. path('admin/', admin.site.urls). The Django Admin site is not currently supported on Dash Enterprise
• settings.py: Add your Dash Enterprise hostname to ALLOWED_HOSTS, remove unsupported apps and middleware from INSTALLED_APPS and MIDDLEWARE, and turn off DEBUG for production apps. See App Structure for more details.
• Remove secrets and passwords: - Remove sensitive passwords and API keys from your code and replace them with Environment Variables.
• System-level dependencies: If your project requires system level dependencies like database drivers, then install those dependencies with a predeploy script and an Aptfile file. See App Structure.
• Self-contained: Ensure that all files and datasets that the app code references or saves are within the same project folder.

Python Version

The Python version that you use locally may be different from the Python version used by Dash Enterprise.

For details on how to override the default version for your app, see the Deployed App Environment page.

Package Versions

Ensure that your local environment is using the same Python package versions as the deployed app by
providing version numbers in your requirements.txt file. See App Structure
for details.