Deploying Bokeh Server apps to AWS / Google Cloud / Azure

May I ask that the website starts creating a comprehensive step-by-step tutorial of how to deploy bokeh server apps on at least one of these three major platforms, since this is almost unheard of online. I guess everyone would like to see which service (of each three providers) can be used and why, as well as complete configuration setup for Bokeh solo or Bokeh + Flask.

As for what is online now , for azure [ please let me know if anyone succeeded with Azure tutorial ] , Deploying Standalone Bokeh Server on native Azure Web App | Medium , for gcloud [too complex, but works] , Creating Custom Interactive Dashboards with Bokeh and BigQuery , for aws , official github bokeh repo for demos on bokeh website .

Having struggled myself, I think that without simple explained examples bokeh library is useless. As much potential as this library has, there is too little documentation on deploying it. I believe that it would be beneficial for many users to have straight-forward tutorials.

Concerning gcloud tutorial:
Note for this tutorial, it is rather old and will not work as is. You will need to use older environment, for that, simply modify this instruction

gcloud container clusters create dashboard-demo-cluster --tags dashboard-demo-node --num-nodes=2

to have this

gcloud container clusters create dashboard-demo-cluster --tags dashboard-demo-node --num-nodes=2 --cluster-version=1.15

Otherwise, you will have errors with yaml files afterwards.

People use Bokeh in Jupyter or nteract notebooks, to generate PNG or SVG images from scripts, to create static HTML files, to embed standalone content in Flask or Django pages, and run Bokeh server apps locally or on corporate networks. None of those uses have anything to do with cloud deployments. I don’t at all doubt the usefulness of cloud deployment guides, but the kind of usage you are concerned with here is not the primary (or even a major) use-case for Bokeh, and exaggeration like this is not really helpful as the basis of discussion.

However, the main problems is the same issue many OSS projects face: the amount of work is larger than the amount of available contributor effort.

There’s literally many dozens of directions guides could go in ^[1]. There is no possible way we could cover all of them, and at least speaking personally, I don’t have the experience to know which ones would be most important. That’s a huge disincentive to spending time on it, because the risk is wasting lots of effort writing the wrong thing. And unfortunately I don’t have the necessary time to do lots of experimentation and research to try and find out these answers, either.

What we do have is lots of Bokeh expertise, but very little cloud expertise. So realistically, the best way to move this needle would be for individuals with relevant cloud expertise to decide to to become OSS contributors and collaborate with us on guides for these topics. That is the promise of Open Source, that we can all do more together. Anyone wishing to take the lead on cloud deploy guides, lending their necessary expertise to the effort, will get lots of consultation attention from me on any Bokeh-specific questions.

1. On AWS should it be Elastic Beanstalk like the demo site? Bare EC2? Lambdas? Something else? That doesn’t even start to get into data connector options or authentication. Multiply these questions times GCP and Azure. I personally have very slight experience with EB on AWS and that’s it. ↩︎

To be concrete, we’d love to help, by supplying detailed Bokeh expertise, support, and infrastructure, to anyone who wants to work any or all of the following:

• Authoring Howto posts on our project publication on Medium.com.
• Owning the content in a new chapter in the user guide dedicated to cloud deployments
• Creating a new repo(s) under the Bokeh GH to support complete end-to-end examples
• Provisioning permanent resources to host live examples (e.g. I can interface with NF who may have cloud credits we can utilize)

The absolute key to this is an appropriate division of labor. Our best role here would be to empower and support folks who already have cloud experience and thus can speak from that experience to the intended audience in the most efficient, authoritative, and authentic way. (Much more so than I have the ability to do, for instance.)

Hi Bryan, thank you for such detailed explanation and your keen interest. I just hate when potential of such great library goes to waste. Unfortunately, bokeh server apps require an actual bokeh server to be running. This erases any standard use of any of those three platforms which increases complexity exponentially, since it becomes a guessing game for each PaaS provider. But using the entire VM simply costs too much.

I stayed up late until 4 am and succeeded to deploy my app to Google Cloud App Engine with custom environment, and it works great. Although my bokeh app is proprietary and I should not share it (and it is too complex for a tutorial), I would be more than happy to contribute with a detailed tutorial on a simple bokeh server application (bokeh solo), say on Medium and official GitHub repo (please tell me if I need to do something in particular), also, a piece of the chapter in the documentation. If you could somehow arrange getting free resources on Google Cloud, it would be amazing.

I have read a lot of material regarding this and I saw that you have your demos deployed on aws. If you have some time, perhaps, you could share some configuration insights in a tutorial.

As for Azure, I have found a number of people having deployed their apps. However, there are only crumbs of information. I have spent more than enough time trying, but I was too tired crying over the debugging window.

Side note… Where should I report bokeh bugs and ask for new features?

Hi @bergenescher I’m very glad to hear you found a solution, and would love to work to extract the knowledge gained from that effort into a helpful resource for all users.

For bug reports and feature requests and dev-related questions, the best place is a GitHub Issue.

We also have a Slack instance for dev chat that you can request to join here:

https://slack-invite.bokeh.org/

That’s probably a really good place for the two of us to have higher-bandwidth async conversations about this. We can certainly set up a call to e.g. go over the existing deploy of the demo.bokeh.org site too if that is useful.

I can start asking NumFocus about GCP or Azure credits. That’s a bureaucratic question, so it will definitely take the most time. Fortunately, I think permanently hosted demos can easily happen last. I would prioritize a blog post and/or docs to be the most immediately valuable.

cc @Timo who may also be interested in this discussion.

Great, let’s do this!

Thank you @bergenescher, that sounds great! I’m a technical writer for Bokeh and I’d be happy to help putting your knowledge into the Bokeh docs. Depending on the complexity, we could either extend the existing chapter on Bokeh server or start an additional chapter dedicated to deploying in the cloud. As most things with Bokeh, this can be a work in progess - we could start by adding whatever is easiest first and then expand from there. You’ll also be able to find me on the Slack!

As an aside: the current one-page chapter is already enormous. I think there should be one top-level chapter, but I think it is passed time to split things into sub-chapters (and this work seems like a prime opportunity to do so).