Host bokeh server on Microsoft Azure App Service

I have a bokeh serve interactive app that works flawlessly locally. I now want to make this app available in the Microsoft Azure cloud since that is what my company is using. From what I understand, Azure App Service would be the best fit.

First of all, is there any obvious reason why this would not work? If not, is there any suggested way of doing this? I found that many sites suggest hosting bokeh together with flask, maybe packaged in a docker container (e.g. here), maybe this is the way to go? I haven’t found any examples of someone successfully running bokeh server on Azure, any pointers to tutorials or hints at how to start / what not to do are welcome.

Edit: I just found this thread about deploying bokeh server to AWS. It looks like some of this might be transferable to Azure, so I think I will try this and see where I fail.

2 Likes

Hi Thomas. Any success with Azure?

Hi thomas,

I’d like to do the exact same thing? Any updates on this?

No, in the end I went with hosting a local solution because of company-internal restrictions on cloud usage. It should be doable though.

Hey guys! For anyone still looking for instructions on how to deploy Bokeh Server natively on Azure Web Apps - here comes the solution I’ve shared on medium: Deploying Standalone Bokeh Server on native Azure Web App | Medium

3 Likes

I have been hosting Bokeh apps on Azure in my organisation. Works like a charm!
App Service for Linux Containers is the best choice in my opinion.

Just build a Docker container with your Bokeh app, upload it to ACR or DockerHub and run it in the App Service.
Make sure you enable WebSockets support and add the BOKEH_ALLOW_WS_ORIGIN=<app_name>.azurewebsites.net

1 Like

It all depends on whether you want to use Containers. I prefer using native Azure services and hate dealing with building custom containers…

To be honest I tried both. I have started with a native App Service, then moved to Containers. For me Containers approach turned to be more reliable to handle build/release cycles.

It depends on the project requirements. If you need to set up an App Service once and then just change the bokeh app code, then a native approach should be fine. In my project I have several environments for DEV, UAT, PROD, automated CI/CD pipelines, I need to deal with releases and rollbacks. For example, if I upgrade from SciPy v.X to SciPy v.Y I need to be able to set up a separate env to run comparison, then after release if by any chance there is some incompatibility I need to be able to roll back to exactly the same version as before with SciPy v.X. All of these scenarios are possible to implement with the native approach, but Docker is just a more eficient and stable tool for it.

Plus with Docker I have significantly decreased my build time: from 30-40 min to 6-7min. My apps use a lot of scientific packages, so building a conda env takes a lot of time. With Docker containers it turned much easier to solve it. One “heavy” base image with dependencies. Application image is built on top of it, so it is possible to use docker layers caching. This allowed me to minimize build time to 6 min and release time to 1 min. Base image takes around 30 min to build, but it doesn’t happen often.

With Bokeh running on App Service in a Container one thing to monitor is MEMORY. If your Python process hits a memory limit, Azure will restart the container. This will terminate all connections to the Bokeh clients. And users will just see that their Bokeh apps stopped being interactive.
Memory threshold is determined by the app price tier.

In my apps I added a JS hook that shows a popup asking to refresh if connection with the server is lost.