In the docs section discussing deployment, there are examples to which I have contributed, regarding reverse proxying with both nginx and Apache.
As things stand currently, bokeh static resources are always accessed by the browser on the
/static path. It is then advised to let the web server handle requests for these files by aliasing the
/static to wherever the bokeh/server/static directory happens to be on disk.
This is fine if your apps share the same bokeh version and thus the same expected bokeh/server/static files. But this approach breaks down if they don’t. This means that whenever you update your bokeh version for one app which is deployed on a server with other apps behind the same reverse proxy, you have to ensure the compatibility of all apps with the new version of bokeh and update their environment too. In a situation where multiple developpers work on apps hosted together, this will soon get wildly unpractical.
To my knowledge the only way to solve this issue is with a pretty unorthodox use of prefixes, since static resources will then be accessible at http://host/prefix/static, which can point to different locations depending on the app. Then you could either let bokeh serve them (suboptimal) or add multiple aliases in your web server configuration.
This is rather convoluted though. My understanding is that the request path to static files is pretty fundamental to how bokeh server works. For example one could not imagine that these resources could be served at
/app/static instead (this would actually lead to conflicts with a potential directory named
static in the app directory). But maybe other options could be discussed?