serve#
To run a Bokeh application on a Bokeh server from a single Python script,
pass the script name to bokeh serve on the command line:
bokeh serve app_script.py
By default, the Bokeh application will be served by the Bokeh server on a
default port (5006) at localhost, under the path /app_script,
i.e.,
http://localhost:5006/app_script
It is also possible to run the same command with jupyter notebooks:
bokeh serve app_notebook.ipynb
This will generate the same results as described with a python script
and the application will be served on a default port (5006)
at localhost, under the path /app_notebook
Applications can also be created from directories. The directory should
contain a main.py (and any other helper modules that are required) as
well as any additional assets (e.g., theme files). Pass the directory name
to bokeh serve to run the application:
bokeh serve app_dir
It is possible to run multiple applications at once:
bokeh serve app_script.py app_dir
If you would like to automatically open a browser to display the HTML
page(s), you can pass the --show option on the command line:
bokeh serve app_script.py app_dir --show
This will open two pages, for /app_script and /app_dir,
respectively.
If you would like to pass command line arguments to Bokeh applications,
you can pass the --args option as the LAST option on the command
line:
bokeh serve app_script.py myapp.py --args foo bar --baz
Everything that follows --args will be included in sys.argv when
the application runs. In this case, when myapp.py executes, the
contents of sys.argv will be ['myapp.py', 'foo', 'bar', '--baz'],
consistent with standard Python expectations for sys.argv.
Note that if multiple scripts or directories are provided, they
all receive the same set of command line arguments (if any) given by
--args.
If you have only one application, the server root will redirect to it. Otherwise, You can see an index of all running applications at the server root:
http://localhost:5006/
This index can be disabled with the --disable-index option, and the redirect
behavior can be disabled with the --disable-index-redirect option.
Another way to run multiple applications is using glob notation to indicate that all the files matching a particular pattern should be served.
bokeh serve *.py
Command line shells will normally expand the *.py automatically. However,
if you are starting a Bokeh server programmatically, then filename arguments
with globs may not be expanded by the shell. In situations like this, the
--glob flag may be used to make the Bokeh server explicitly perform globbing:
subprocess.call(["bokeh", "serve", "--glob", "*.py"])
A .ico file may be configured with the --ico-path option, and the Bokeh
server will return the contents of this file for /favicon.ico:
bokeh serve app.py --ico-path=/assets/app.ico
Since browsers only look at the top-level root, only one .ico file may be supplied, even if multiple apps are running. By default, a Bokeh project logo is returned as the favicon.ico file.
Application Configuration#
Bokeh server can fork the underlying tornado server into multiprocess. This is useful when trying to handle multiple connections especially in the context of apps which require high computational loads. Default behavior is one process. using 0 will auto-detect the number of cores and spin up corresponding number of processes
bokeh serve app_script.py --num-procs 2
Note that due to limitations inherent in Tornado, Windows does not support
--num-procs values greater than one! In this case consider running multiple
Bokeh server instances behind a load balancer.
The Bokeh server can also add an optional prefix to all URL paths. This can often be useful in conjunction with “reverse proxy” setups.
bokeh serve app_script.py --prefix foobar
Then the application will be served under the following URL:
http://localhost:5006/foobar/app_script
If needed, Bokeh server can send keep-alive pings at a fixed interval.
To configure this feature, set the --keep-alive option:
bokeh serve app_script.py --keep-alive 10000
The value is specified in milliseconds. The default keep-alive interval is 37 seconds. Give a value of 0 to disable keep-alive pings.
Network Configuration#
To control the port that the Bokeh server listens on, use the --port
argument:
bokeh serve app_script.py --port 8080
To listen on an arbitrary port, pass 0 as the port number. The actual
port number will be logged at startup.
Similarly, a specific network address can be specified with the
--address argument. For example:
bokeh serve app_script.py --address 0.0.0.0
will have the Bokeh server listen all available network addresses.
By default, cross site connections to the Bokeh server websocket are not
allowed. You can enable websocket connections originating from additional
hosts by specifying them with the BOKEH_ALLOW_WS_ORIGIN environment variable
or the --allow-websocket-origin option:
bokeh serve app_script.py --allow-websocket-origin foo.com:8081
It is possible to specify multiple allowed websocket origins by adding
the --allow-websocket-origin option multiple times and to provide a
comma separated list of hosts to BOKEH_ALLOW_WS_ORIGIN
To have the Bokeh server override the remote IP and URI scheme/protocol for
all requests with X-Real-Ip, X-Forwarded-For, X-Scheme,
X-Forwarded-Proto headers (if they are provided), set the
--use-xheaders option:
bokeh serve app_script.py --use-xheaders
This is typically needed when running a Bokeh server behind a reverse proxy that is SSL-terminated.
Warning
It is not advised to set this option on a Bokeh server directly facing the Internet.
A Bokeh server can also terminate SSL connections directly by specifying the path to a single file in PEM format containing the certificate as well as any number of CA certificates needed to establish the certificate’s authenticity:
bokeh serve --ssl-certfile /path/to/cert.pem
Alternatively, the path may also be supplied by setting the environment
variable BOKEH_SSL_CERTFILE.
If the private key is stored separately, its location may be supplied by
setting the --ssl-keyfile command line argument, or by setting the
BOKEH_SSL_KEYFILE environment variable. If a password is required for the
private key, it should be supplied by setting the BOKEH_SSL_PASSWORD
environment variable.
Session ID Options#
Typically, each browser tab connected to a Bokeh server will have its own session ID. When the server generates an ID, it will make it cryptographically unguessable. This keeps users from accessing one another’s sessions.
To control who can use a Bokeh application, the server can sign session IDs
with a secret key and reject “made up” session names. There are three modes,
controlled by the --session-ids argument:
bokeh serve app_script.py --session-ids signed
The available modes are: unsigned, signed or external-signed
In unsigned mode, the server will accept any session ID provided to it in
the URL. For example, http://localhost/app_script?bokeh-session-id=foo will
create a session foo. In unsigned mode, if the session ID isn’t
provided with ?bokeh-session-id= in the URL, the server will still generate
a cryptographically-unguessable ID. However, the server allows clients to
create guessable or deliberately-shared sessions if they want to.
unsigned mode is most useful when the server is running locally for
development, for example you can have multiple processes access a fixed session
name such as default. unsigned mode is also convenient because there’s
no need to generate or configure a secret key.
In signed mode, the session ID must be in a special format and signed with
a secret key. Attempts to use the application with an invalid session ID will
fail, but if no ?bokeh-session-id= parameter is provided, the server will
generate a fresh, signed session ID. The result of signed mode is that only
secure session IDs are allowed but anyone can connect to the server.
In external-signed mode, the session ID must be signed but the server
itself won’t generate a session ID; the ?bokeh-session-id= parameter will
be required. To use this mode, an external process (such as another web app)
would use the function bokeh.util.token.generate_session_id() to
create valid session IDs. The external process and the Bokeh server must share
the same BOKEH_SECRET_KEY environment variable.
external-signed mode is useful if you want another process to authenticate
access to the Bokeh server. If someone is permitted to use a Bokeh application,
you would generate a session ID for them, then redirect them to the Bokeh
server with that valid session ID. If you don’t generate a session ID for
someone, then they can’t load the app from the Bokeh server.
In both signed and external-signed mode, the secret key must be kept
secret; anyone with the key can generate a valid session ID.
The secret key should be set in a BOKEH_SECRET_KEY environment variable and
should be a cryptographically random string with at least 256 bits (32 bytes)
of entropy. The bokeh secret command can generate new secret keys.
Authentication Options#
The Bokeh server can be configured to only allow connections in case there is a properly authenticated user. This is accomplished by providing the path to a module that implements the necessary functions on the command line:
bokeh serve --auth-module=/path/to/auth.py
or by setting the BOKEH_AUTH_MODULE environment variable.
The module must contain one of the following two functions that will return the current user (or None):
def get_user(request_handler):
pass
async def get_user_async(request_handler):
pass
The function is passed the Tornado RequestHandler and can inspect cookies
or request headers to determine the authenticated user. If there is no valid
authenticated user, these functions should return None.
Additionally, the module must specify where to redirect unauthenticated users. It must contain either:
a module attribute
login_urland (optionally) aLoginHandlerclassa function definition for
get_login_url
login_url = "..."
class LoginHandler(RequestHandler):
pass
def get_login_url(request_handler):
pass
When a relative login_url is given, an optional LoginHandler class may
also be provided, and it will be installed as a route on the Bokeh server
automatically.
The get_login_url function is useful in cases where the login URL must
vary based on the request, or cookies, etc. It is not possible to specify a
LoginHandler when get_url_function is defined.
Analogous to the login options, optional logout_url and LogoutHandler
values may be define an endpoint for logging users out.
If no auth module is provided, then a default user will be assumed, and no authentication will be required to access Bokeh server endpoints.
Warning
The contents of the auth module will be executed!
Bokeh can also enable the use of Tornado’s XFRF cookie protection. To turn this
feature on, use the --enable-xsrf-cookies option, or set the environment
variable BOKEH_XSRF_COOKIES=yes. If this setting is enabled, any PUT, POST,
or DELETE operations on custom or login handlers must be instrumented properly
in order to function. Typically, this means adding the xsrf_form_html()
module to HTML form submissions templates. For full details, see:
Session Expiration Options#
To configure how often to check for unused sessions. set the
--check-unused-sessions option:
bokeh serve app_script.py --check-unused-sessions 10000
The value is specified in milliseconds. The default interval for checking for unused sessions is 17 seconds. Only positive integer values are accepted.
To configure how often unused sessions last. set the
--unused-session-lifetime option:
bokeh serve app_script.py --unused-session-lifetime 60000
The value is specified in milliseconds. The default lifetime interval for unused sessions is 15 seconds. Only positive integer values are accepted.
Diagnostic Options#
The logging level can be controlled by the --log-level argument:
bokeh serve app_script.py --log-level debug
The available log levels are: trace, debug, info, warning, error or critical
The log format can be controlled by the --log-format argument:
bokeh serve app_script.py --log-format "%(levelname)s: %(message)s"
The default log format is "%(asctime)s %(message)s"
To control how often statistic logs are written, set the
--stats-log-frequency option:
bokeh serve app_script.py --stats-log-frequency 30000
The value is specified in milliseconds. The default interval for logging stats is 15 seconds. Only positive integer values are accepted.
Bokeh can also optionally log process memory usage. This feature requires
the optional psutil package to be installed. To enable memory logging
set the --mem-log-frequency option:
bokeh serve app_script.py --mem-log-frequency 30000
The value is specified in milliseconds. The default interval for logging stats is 0 (disabled). Only positive integer values are accepted.
- class Serve(parser: ArgumentParser)[source]#
Subcommand to launch the Bokeh server.
- customize_applications(args: Namespace, applications: dict[str, Any]) dict[str, Any][source]#
Allows subclasses to customize
applications.Should modify and return a copy of the
applicationsdictionary.
- customize_kwargs(args: Namespace, server_kwargs: dict[str, Any]) dict[str, Any][source]#
Allows subclasses to customize
server_kwargs.Should modify and return a copy of the
server_kwargsdictionary.