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:
#!/usr/bin/env python # -*- coding: utf-8 -*- 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 [UNKNOWN NODE title_reference] 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, reloader_interval=1, reloader_type='auto', threaded=False, processes=1, request_handler=None, static_files=None, passthrough_errors=False, ssl_context=None)
Start a WSGI application. Optional features include a reloader, multithreading and fork support.
This function has a command-line interface too:
python -m werkzeug.serving --help
New in version 0.5: [UNKNOWN NODE title_reference] was added to simplify serving of static files as well as [UNKNOWN NODE title_reference].
New in version 0.6: support for SSL was added.
New in version 0.8: Added support for automatically loading a SSL context from certificate file and private key.
New in version 0.9: Added command-line interface.
New in version 0.10: Improved the reloader and added support for changing the backend through the [UNKNOWN NODE title_reference] parameter. See Reloader for more information.
- hostname – The host for the application. eg:
- port – The port for the server. eg:
- application – the WSGI application to execute
- use_reloader – should the server automatically restart the python process if modules were changed?
- use_debugger – should the werkzeug debugging system be used?
- use_evalex – should the exception evaluation feature be enabled?
- extra_files – a list of files the reloader should watch additionally to the modules. For example configuration files.
- reloader_interval – the interval for the reloader in seconds.
- reloader_type – the type of reloader to use. The default is
auto detection. Valid values are
'watchdog'. See Reloader for more information.
- threaded – should the process handle each request in a separate thread?
- processes – if greater than 1 then handle each request in a new process up to this maximum number of concurrent processes.
- request_handler – optional parameter that can be used to replace
the default one. You can use this to replace it
with a different
- static_files – a list or dict of paths for static files. This works
SharedDataMiddleware, it’s actually just wrapping the application in that middleware before serving.
- passthrough_errors – set this to [UNKNOWN NODE title_reference] to disable the error catching. This means that the server will die on errors but it can be useful to hook debuggers in (pdb etc.)
- ssl_context – an SSL context for the connection. Either an
ssl.SSLContext, a tuple in the form
(cert_file, pkey_file), the string
'adhoc'if the server should automatically create one, or
Noneto disable SSL (which is the default).
Checks if the application is running from within the Werkzeug reloader subprocess.
New in version 0.10.
werkzeug.serving.make_ssl_devcert(base_path, host=None, cn=None)
Creates an SSL key for development. This should be used instead of
'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
For more information see
New in version 0.9.
- base_path – the path to the certificate and key. The extension
.crtis added for the certificate,
.keyis added for the key.
- host – the name of the host. This can be used as an alternative for the [UNKNOWN NODE title_reference].
- cn – the [UNKNOWN NODE title_reference] to use.
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 Application Deployment pages.
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:
- The default
statbackend simply checks the
mtimeof all files in a regular interval. This is sufficient for most cases, however, it is known to drain a laptop’s battery.
watchdogbackend 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.
watchdog is installed and available it will automatically be used
instead of the builtin
To switch between the backends you can use the [UNKNOWN NODE title_reference] parameter of the
'stat' sets it to the default stat based
'watchdog' forces it to the watchdog backend.
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.
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 [UNKNOWN NODE title_reference] and [UNKNOWN NODE title_reference] (or anything else) in addition to [UNKNOWN NODE title_reference].
You can find the hosts file on the following location:
Linux / OS X
You can open the file with your favorite text editor and add a new name after [UNKNOWN NODE title_reference]:
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
Shutting Down The Server
New in version 0.7.
Starting with Werkzeug 0.7 the development server provides a way to shut
down the server after a request. This currently only works with Python
2.6 and later and will only work with the development server. To initiate
the shutdown you have to call a function named
'werkzeug.server.shutdown' in the WSGI environment:
def shutdown_server(environ): if not 'werkzeug.server.shutdown' in environ: raise RuntimeError('Not running the development server') environ['werkzeug.server.shutdown']()
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:
Alternatively you can also disable ipv6 support in your browser. For example
if Firefox shows this behavior you can disable it by going to
and disabling the [UNKNOWN NODE title_reference] 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
explicitly bind the hostname to an ipv4 address ([UNKNOWN NODE title_reference])
New 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.
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 [UNKNOWN NODE title_reference].
Generate an SSL key and store it somewhere:[UNKNOWN NODE doctest_block]
Now this tuple can be passed as
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
In Python 2.7.9 and 3+ you also have the option to use a
object instead of a simple tuple. This way you have better control over the SSL
behavior of Werkzeug’s builtin server:
import ssl ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23) ctx.load_cert_chain('ssl.cert', 'ssl.key') run_simple('localhost', 4000, application, ssl_context=ctx)
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 [UNKNOWN NODE title_reference] command installed on your system:
$ openssl genrsa 1024 > ssl.key $ openssl req -new -x509 -nodes -sha1 -days 365 -key ssl.key > ssl.cert
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 pyOpenSSL library to be installed.