App Structure, Buildpacks, and Deployment Lifecycle

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

The deployment and release lifecycle begins when you git push to Dash Enterprise —
Dash Enterprise creates a new image based off of the changes that you pushed
and runs the image as containers.

The files you include in your project folder determine how Dash Enterprise builds,
deploys, and releases your apps and workspaces.

Buildpacks are the technology responsible for transforming deployed code into the image
that is then run as containers on Dash Enterprise. Dash Enterprise supports pip and Conda buildpacks.

Pip Versus Conda

Pip and Conda are package managers that you can use to handle your app’s
Python dependencies.

We recommend using pip because it allows for faster app deployments. Conda’s dependency resolver increases the time it takes to install dependencies during development and deployment (15 mins compared to 7 mins).
Use Conda if mandated by your organization or if your app requires packages that cannot be installed with pip, like cupy or cuda.

Note that the Conda buildpack is not currently compatible with internet-restricted Dash Enterprise instances.

For an example of an app that uses the Conda buildpack, see the Conda app in the App Catalog.

Project Folder Overview

Required Files

By convention, this is usually called or This file is
called by the command you specify in your Procfile. It contains your Python
code and must be placed in your project’s root directory. This file must also contain a
line that defines the server variable so that it can be exposed for the

from dash import Dash

app = Dash(__name__)
server = app.server

requirements.txt or environment.yml

Describe your app’s Python dependencies in a requirements.txt file if you want Dash Enterprise to use the pip buildpack, or describe them in
an environment.yml file if you want Dash Enterprise to use the Conda buildpack.

Note that adding both requirements.txt and environment.yml to your app currently causes Dash Enterprise to detect only the pip buildpack, so it
is not possible to use both sets of features from these files in the same app.


A Procfile is a required text file that tells Dash Enterprise which processes to run on
startup, like starting your app’s web server, scheduling jobs, and running background processes.

This file is always named Procfile—with no file extension. It must be placed in your app’s root
directory and uses the following format:

<process>: <command>


Dash app Procfile examples

A simple Dash app Procfile looks like this:

web: gunicorn app:server --workers 4

A Dash app running a background task queue might have a Procfile similar to this:

web: gunicorn app:server --workers 4
worker: celery -A app:celery_instance worker

Note: Process type names are arbitrary except for web—a special process.
In the example above, worker could be anything, but we recommend using descriptive names as they appear in logs.

A Dash app periodically generating reports with the Snapshot Engine might have a
Procfile like this:

web: gunicorn index:server --workers 4
worker: celery -A index:celery_instance worker --concurrency=2
scheduler: celery -A index:celery_instance beat

A Dash app whose file is not located at the root, but rather inside a folder, might have a Procfile like this:

web: gunicorn app:server --workers 4 --chdir <folder_name>

Known issue: If you use the above pattern, you’ll need to add an empty Python file at the root of your app. Otherwise, Dash Enterprise will fail to deploy your app.


More on web processes

web is the only process type that can receive external HTTP traffic. Use this
to run your Dash app with gunicorn, your Dash app’s web server. In the following
example we declare gunicorn as our web server with web: gunicorn:

web: gunicorn app:server --workers 4 --preload

This command is a standard gunicorn command
used to run your Dash app. It’s the production alternative to running your app with python

app refers to a file named and server refers to the variable named server
inside that file (see the section in this document). If the entry point to your
app is instead of, then this would be web: gunicorn index:server --workers 4 --preload.

gunicorn accepts a wide variety of settings.
Here are a few common flags:

web: gunicorn app:server –workers 4


web: gunicorn app:server --workers 4 --preload

web: gunicorn app:server --workers 4 --timeout 240

See the Gunicorn docs on timeout for more information.

Do not increase the --timeout to resolve an issue with a callback taking more than 30 seconds to execute; use


.gitignore is a text file that determines which files and folders are ignored by Git.
Files listed in the .gitignore are not copied to the server when you deploy your app.



An Aptfile can be used to install system-level packages via the APT package manager. It supports:

If an Aptfile is included in your project, an apt-get update is triggered before installing the packages.


Packages from standard APT repositories

Packages from APT repositories might include database drivers that your app requires.
In the following example we are installing unixodbc and unixodbc-dev:



Specific .deb files

You can also add links to specific .deb files to be installed:

<a href=""></a>


Custom APT repositories

Your Aptfile can also contain additional APT

:repo:deb <a href=""></a> example-distro main

Important: Dash Enterprise requires that custom APT repositories have a TLS/SSL certificate from a globally trusted certificate authority (CA).

To use APT packages in your apps when Dash Enterprise is internet-restricted, you need to specify a custom APT repository that Dash Enterprise has network access to. See an example in
Developing Apps when Dash Enterprise Is Internet-Restricted.

App Lifecycle