Bokeh Server: Specifying bind address and port number separately from hostname

Hi All,

I am (still) trying to develop a workflow to make it easier for me to post interactive visualizations on my site hosted at I am using django, and the interactive bokeh app requiring running bokeh server is working in my local development environment. In my production environment have been stuck trying to get bokeh server going, and I received the following message from NFS support:

You need to specify the bind address and port number separately from the hostname used to generate URLs for the client. There is literally no single value that serves both purposes. Our system sets X-Forwarded-Host & X-Forwarded-Proto. It also handles SSL termination, including for websockets.

NFS has a simple UI form where you can set up a websocket proxy, requiring a base URI, a document root, and a port. I am honestly just guessing at this.

I have gotten bokeh serve to launch by specifying bokeh serve test_app/ --address --port 5006, however as the support person stated, “as with all other valid bind address options, it’s entirely unusable as a hostname.”

Any guidance would be greatly appreciated!


I am afraid I can’t really give any specific guidance, because I don’t really know anything at all about this hosting platform. But if they are setting X-Forwarded-Host and X-Forwarded-Proto then you would probably want to configure the Bokeh server to use these with --use-xheaders similar to what’s described in Reverse Proxying with Nginx and SSL. That said, Bokeh will look at X-Forwarded-For not X-Forwarded-Host so you may need to check with NFS support.

Additionally, you will want to set --allow-websocket-origin to tell the Bokeh server what origins it is allowed to accept connections from. By default the settings are conservative and only connections from localhost (i.e. for local development or experimentation) are allowed.

Thanks Bryan,

I’ve dug around a little more, and have found the following (all tests below use some combination/variation of the flags --allow-websocket-origin --port 8000 --use-xheaders):

No matter what I set allow-websocket-origin to, If I don’t set --address in a bokeh serve command , I get the following error:

Cannot start Bokeh server, address 'None' not available

If I set --address, I get:

Cannot start Bokeh server, address ‘’ not available

If I set a proxy using ws protocol on port 5000 with a base uri of /dataviz/, pointing at the document root where the application is located, and I try --address, I get:

Cannot start Bokeh server [ENOEXEC]: gaierror(8, ‘hostname nor servname provided, or not known’)

I get the above error regardless of what I set the address (,, etc.) or port (5000, 5006, 8000, 8080) which shows how badly I’m lobbing guesses into the abyss.

The whole shell command is:

bokeh serve bk_test/ --address --allow-websocket-origin --port 5000 --use-xheaders

NFS does not use nginx, I think it uses Apache. Maybe I need to configure with .htaccess? I understand these files should be located in the folder structure itself, if the case is I need to configure something with .htaccess, would it be located in the root folder or in the app folder (bk_test/)?

Any ideas?

Not alot, unfortunately. I don’t really have any experience with Apache. I can offer a few comments:

  • --address refers to what local network interface address the HTTP server should bind to. By default Bokeh binds to all available network addresses. I doubt you would need to set this. (And if you did, it would be an octet, not a hostname)

  • The value for --allow-websocket-origin should be a hostname and just the hostname, e.g. As a temporary measure, you could set allow-websocket-origin='*' which tells bokeh to accept all websocket connections, regardless of origin

  • The proxy will have to forward websockets! The Bokeh docs describe how to configure Nginx to do this. I don’t know what it looks like for Apache. If this is not feasible (e.g. NFS does not want to allow it) then this endeavor is DOA. All Bokeh server comms occur over websockets, there’s no getting around this.

  • More information to collect:

    • JS console logs from the browser
    • Bokeh sever console logs
    • logs from the proxy (Apache in this case)

    The questions to try to answer are: How far do things get? Did it make it through the proxy, does the bokeh server show a connection attempt? Does the browser try to make the WS upgrade at all, and if so does it fail? With what error?

Also I am going to venture that you are trying to avoid larger cloud vendors, but just in case it’s useful, the Elastic Beanstalk deployment is here

It’s basically just upload that Dockerfile to get things running.