This section describes three different approaches to embedding a Dash app
within an existing web application.
Heads up! If you are a Dash Enterprise customer,
then you can use the
Dash Embedded Middleware library that is included in your license.
dash-embeddedprovides a secure mechanism for embedding Dash apps
into an existing website without iframes. It also provides hooks into
your existing website’s login and authentication logic so that only
users who have logged into the existing host web application can view
the embedded Dash application.
The simplest approach to embedding Dash in an existing web application is to
<iframe> element in your HTML whose
src attribute points
towards the address of a deployed Dash app. This allows you to place your
Dash app in a specific location within an existing web page with your
As discussed in the Deployment Chapter, Dash uses the Flask
web framework under the hood. This makes it fairly straightforward to
embed a Dash app at a specific route of an existing Flask app.
In the following example, a Dash app is mounted at the
/dash route (eg
http://localhost:8050/dash) of a Flask app:
Note: it is important to set the
nameparameter of the Dash instance
to the value
__name__, so that Dash can correctly detect the location of
any static assets inside an
assetsdirectory for this Dash app.
This approach uses Werkzeug’s
to combine one or more Dash apps with existing WSGI apps (including
Flask). It is useful when you want to combine multiple Dash apps or when
your existing app is a non-Flask WSGI app.
The following example illustrates this approach by combining two Dash apps
with a Flask app.
In this example, the Flask app has been mounted at
/ and the two Dash apps
have been mounted at
/app2. In this approach, we do not pass
in a Flask server to the Dash apps, but let them create their own, which the
DispatcherMiddleware routes requests to based on the prefix of the
incoming requests. Within each Dash app,
requests_pathname_prefix must be
specified as the app’s mount point, in order to match the route prefix
set by the
Note that the
application object in
wsgi.py is of type
werkzeug.wsgi.DispatcherMiddleware, which does not have a
method. This can be run as a WSGI app like so:
Alternatively, you can use the Werkzeug development server (which is not
suitable for production) to run the app:
If you need access to the Dash development tools when using this approach
(whether running with a WSGI server, or using the Werkzeug development
server) you must invoke them manually for each Dash app. The following lines
can be added before the initialisation of the
DispatcherMiddleware to do this:
Note: debug mode should not be enabled in production. When using debug
mode with Gunicorn, the
--reloadcommand line flag is required for hot
reloading to work.
In this example, the existing app being combined with two Dash apps is a
Flask app, however this approach enables the combination of any web
application implementing the WSGI
specification. A list of WSGI web frameworks
can be found in the WSGI
one or more Dash apps.