Why shouldn’t Flask be deployed with the built in server?

Werkzeug’s WSGI server is not meant for use in production. It is provided as a convenience during development. It was not developed with security or performance in mind (by default it only handles one request at a time). Use a real WSGI application server such as uWSGI or Gunicorn for performance, and proxy it through a real web server such as Nginx for performance and security. Web servers are good at queueing requests/responses, can serve static and other content at the same time, and are designed to handle SSL. WSGI servers are good at coordinating multiple requests across an app efficiently. Werkzeug was designed as a WSGI library, not as a web server or WSGI server.

The docs tell you directly not to use the development server in production.

You can use the builtin server during development, but you should use a full deployment option for production applications. (Do not use the builtin development server in production.)

Additionally, web servers run as root (then drop privileges), so they can listen on the standard ports 80 and 443. You should never run an application as root, and so you would only be able to bind to ports above 1024, so users would have to know the port rather than just the domain.

Leave a Comment