Serving WSGI Applications

There are many ways to serve a WSGI application. While you’re developing it, you usually don’t want to have a full-blown webserver like Apache up and running, but instead a simple standalone one. Because of that Werkzeug comes with a builtin development server.

The easiest way is creating a small start-myproject.py file that runs the application using the builtin server:

from werkzeug.serving import run_simple
from myproject import make_app

app = make_app(...)
run_simple('localhost', 8080, app, use_reloader=True)

You can also pass it the extra_files keyword argument with a list of additional files (like configuration files) you want to observe.

werkzeug.serving.run_simple(hostname, port, application, use_reloader=False, use_debugger=False, use_evalex=True, extra_files=None, exclude_patterns=None, reloader_interval=1, reloader_type='auto', threaded=False, processes=1, request_handler=None, static_files=None, passthrough_errors=False, ssl_context=None)

Start a development server for a WSGI application. Various optional features can be enabled.

Warning

Do not use the development server when deploying to production. It is intended for use only during local development. It is not designed to be particularly efficient, stable, or secure.

Parameters:

  • hostname (str) – The host to bind to, for example 'localhost'. Can be a domain, IPv4 or IPv6 address, or file path starting with unix:// for a Unix socket.

  • port (int) – The port to bind to, for example 8080. Using 0 tells the OS to pick a random free port.

  • application (WSGIApplication) – The WSGI application to run.

  • use_reloader (bool) – Use a reloader process to restart the server process when files are changed.

  • use_debugger (bool) – Use Werkzeug’s debugger, which will show formatted tracebacks on unhandled exceptions.

  • use_evalex (bool) – Make the debugger interactive. A Python terminal can be opened for any frame in the traceback. Some protection is provided by requiring a PIN, but this should never be enabled on a publicly visible server.

  • extra_files (t.Iterable[str] | None) – The reloader will watch these files for changes in addition to Python modules. For example, watch a configuration file.

  • exclude_patterns (t.Iterable[str] | None) – The reloader will ignore changes to any files matching these fnmatch patterns. For example, ignore cache files.

  • reloader_interval (int) – How often the reloader tries to check for changes.

  • reloader_type (str) – The reloader to use. The 'stat' reloader is built in, but may require significant CPU to watch files. The 'watchdog' reloader is much more efficient but requires installing the watchdog package first.

  • threaded (bool) – Handle concurrent requests using threads. Cannot be used with processes.

  • processes (int) – Handle concurrent requests using up to this number of processes. Cannot be used with threaded.

  • request_handler (type[WSGIRequestHandler] | None) – Use a different BaseHTTPRequestHandler subclass to handle requests.

  • static_files (dict[str, str | tuple[str, str]] | None) – A dict mapping URL prefixes to directories to serve static files from using SharedDataMiddleware.

  • passthrough_errors (bool) – Don’t catch unhandled exceptions at the server level, let the server crash instead. If use_debugger is enabled, the debugger will still catch such errors.

  • ssl_context (_TSSLContextArg | None) – Configure TLS to serve over HTTPS. Can be an ssl.SSLContext object, a (cert_file, key_file) tuple to create a typical context, or the string 'adhoc' to generate a temporary self-signed certificate.

Return type:

None

Changelog

Changed in version 2.1: Instructions are shown for dealing with an “address already in use” error.

Changed in version 2.1: Running on 0.0.0.0 or :: shows the loopback IP in addition to a real IP.

Changed in version 2.1: The command-line interface was removed.

Changed in version 2.0: Running on 0.0.0.0 or :: shows a real IP address that was bound as well as a warning not to run the development server in production.

Changed in version 2.0: The exclude_patterns parameter was added.

Changed in version 0.15: Bind to a Unix socket by passing a hostname that starts with unix://.

Changed in version 0.10: Improved the reloader and added support for changing the backend through the reloader_type parameter.

Changed in version 0.9: A command-line interface was added.

Changed in version 0.8: ssl_context can be a tuple of paths to the certificate and private key files.

Changed in version 0.6: The ssl_context parameter was added.

Changed in version 0.5: The static_files and passthrough_errors parameters were added.

werkzeug.serving.is_running_from_reloader()

Check if the server is running as a subprocess within the Werkzeug reloader.

Changelog

Added in version 0.10.

Return type:

bool

werkzeug.serving.make_ssl_devcert(base_path, host=None, cn=None)

Creates an SSL key for development. This should be used instead of the 'adhoc' key which generates a new cert on each server start. It accepts a path for where it should store the key and cert and either a host or CN. If a host is given it will use the CN *.host/CN=host.

For more information see run_simple().

Changelog

Added in version 0.9.

Parameters:

  • base_path (str) – the path to the certificate and key. The extension .crt is added for the certificate, .key is added for the key.

  • host (str | None) – the name of the host. This can be used as an alternative for the cn.

  • cn (str | None) – the CN to use.

Return type:

tuple[str, str]

Information

The development server is not intended to be used on production systems. It was designed especially for development purposes and performs poorly under high load. For deployment setups have a look at the Deploying to Production pages.

Reloader

Changelog

Changed in version 0.10.

The Werkzeug reloader constantly monitors modules and paths of your web application, and restarts the server if any of the observed files change.

Since version 0.10, there are two backends the reloader supports: stat and watchdog.

  • The default stat backend simply checks the mtime of all files in a regular interval. This is sufficient for most cases, however, it is known to drain a laptop’s battery.

  • The watchdog backend uses filesystem events, and is much faster than stat. It requires the watchdog module to be installed. The recommended way to achieve this is to add Werkzeug[watchdog] to your requirements file.

If watchdog is installed and available it will automatically be used instead of the builtin stat reloader.

To switch between the backends you can use the reloader_type parameter of the run_simple() function. 'stat' sets it to the default stat based polling and 'watchdog' forces it to the watchdog backend.

Note

Some edge cases, like modules that failed to import correctly, are not handled by the stat reloader for performance reasons. The watchdog reloader monitors such files too.

Colored Logging

The development server highlights the request logs in different colors based on the status code. On Windows, Colorama must be installed as well to enable this.

Virtual Hosts

Many web applications utilize multiple subdomains. This can be a bit tricky to simulate locally. Fortunately there is the hosts file that can be used to assign the local computer multiple names.

This allows you to call your local computer yourapplication.local and api.yourapplication.local (or anything else) in addition to localhost.

You can find the hosts file on the following location:

Windows

%SystemRoot%\system32\drivers\etc\hosts

Linux / OS X

/etc/hosts

You can open the file with your favorite text editor and add a new name after localhost:

127.0.0.1       localhost yourapplication.local api.yourapplication.local

Save the changes and after a while you should be able to access the development server on these host names as well. You can use the URL Routing system to dispatch between different hosts or parse request.host yourself.

Shutting Down The Server

In some cases it can be useful to shut down a server after handling a request. For example, a local command line tool that needs OAuth authentication could temporarily start a server to listen for a response, record the user’s token, then stop the server.

One method to do this could be to start a server in a multiprocessing process, then terminate the process after a value is passed back to the parent.

import multiprocessing
from werkzeug import Request, Response, run_simple

def get_token(q: multiprocessing.Queue) -> None:
    @Request.application
    def app(request: Request) -> Response:
        q.put(request.args["token"])
        return Response("", 204)

    run_simple("localhost", 5000, app)

if __name__ == "__main__":
    q = multiprocessing.Queue()
    p = multiprocessing.Process(target=get_token, args=(q,))
    p.start()
    print("waiting")
    token = q.get(block=True)
    p.terminate()
    print(token)

That example uses Werkzeug’s development server, but any production server that can be started as a Python process could use the same technique and should be preferred for security. Another method could be to start a subprocess process and send the value back over stdout.

Troubleshooting

On operating systems that support ipv6 and have it configured such as modern Linux systems, OS X 10.4 or higher as well as Windows Vista some browsers can be painfully slow if accessing your local server. The reason for this is that sometimes “localhost” is configured to be available on both ipv4 and ipv6 sockets and some browsers will try to access ipv6 first and then ipv4.

At the current time the integrated webserver does not support ipv6 and ipv4 at the same time and for better portability ipv4 is the default.

If you notice that the web browser takes ages to load the page there are two ways around this issue. If you don’t need ipv6 support you can disable the ipv6 entry in the hosts file by removing this line:

::1             localhost

Alternatively you can also disable ipv6 support in your browser. For example if Firefox shows this behavior you can disable it by going to about:config and disabling the network.dns.disableIPv6 key. This however is not recommended as of Werkzeug 0.6.1!

Starting with Werkzeug 0.6.1, the server will now switch between ipv4 and ipv6 based on your operating system’s configuration. This means if that you disabled ipv6 support in your browser but your operating system is preferring ipv6, you will be unable to connect to your server. In that situation, you can either remove the localhost entry for ::1 or explicitly bind the hostname to an ipv4 address (127.0.0.1)

SSL

Changelog

Added in version 0.6.

The builtin server supports SSL for testing purposes. If an SSL context is provided it will be used. That means a server can either run in HTTP or HTTPS mode, but not both.

Quickstart

The easiest way to do SSL based development with Werkzeug is by using it to generate an SSL certificate and private key and storing that somewhere and to then put it there. For the certificate you need to provide the name of your server on generation or a CN.

  1. Generate an SSL key and store it somewhere:

    >>> from werkzeug.serving import make_ssl_devcert
>>> make_ssl_devcert('/path/to/the/key', host='localhost')
('/path/to/the/key.crt', '/path/to/the/key.key')

  2. Now this tuple can be passed as ssl_context to the run_simple() method:

    run_simple('localhost', 4000, application,
           ssl_context=('/path/to/the/key.crt',
                        '/path/to/the/key.key'))

You will have to acknowledge the certificate in your browser once then.

Loading Contexts by Hand

You can use a ssl.SSLContext object instead of a tuple for full control over the TLS configuration.

import ssl
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain('ssl.cert', 'ssl.key')
run_simple('localhost', 4000, application, ssl_context=ctx)

Generating Certificates

A key and certificate can be created in advance using the openssl tool instead of the make_ssl_devcert(). This requires that you have the openssl command installed on your system:

$ openssl genrsa 1024 > ssl.key
$ openssl req -new -x509 -nodes -sha1 -days 365 -key ssl.key > ssl.cert

Adhoc Certificates

The easiest way to enable SSL is to start the server in adhoc-mode. In that case Werkzeug will generate an SSL certificate for you:

run_simple('localhost', 4000, application,
           ssl_context='adhoc')

The downside of this of course is that you will have to acknowledge the certificate each time the server is reloaded. Adhoc certificates are discouraged because modern browsers do a bad job at supporting them for security reasons.

This feature requires the cryptography library to be installed.

Unix Sockets

The dev server can bind to a Unix socket instead of a TCP socket. run_simple() will bind to a Unix socket if the hostname parameter starts with 'unix://'.

from werkzeug.serving import run_simple
run_simple('unix://example.sock', 0, app)