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 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.
Start an application using wsgiref and with an optional reloader. This wraps wsgiref to fix the wrong default reporting of the multithreaded WSGI variable and adds optional multithreading and fork support.
Changed in version 0.5: Older versions of this function supported replacing the default request handler with a custom wsgiref request handler. As we are no longer using wsgiref internally that parameter went away.
New in version 0.5: static_files was added to simplify serving of static files.
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.
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.