Is the server bundled with Flask safe to use in production?

Question

Is the server bundled with Flask safe for deployment in a production environment? If not, what should I use to deploy Flask in production?

Solution 1

No. The bundled server is a development server. It's not designed with production environments in mind.

• It will not handle more than one request at a time by default.
• If you leave debug mode on and an error pops up, it opens up a shell that allows for arbitrary code to be executed on your server (think os.system('rm -rf /')).
• The development server doesn't scale well.

Flask uses Werkzeug's development server, and the documentation says the same thing:

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.

The recommended approach is to use a production WSGI server to run your Flask application. There's a whole section dedicated to deployment in the docs: Deployment Options.

Deploying your application is as simple as installing a WSGI server like uWSGI or gunicorn and running that instead of Flask's development server:

gunicorn -w 4 -b 127.0.0.1:4000 myproject:app

---

If you are serving any static assets like images or videos, need low-level caching, or have higher concurrency demands, it's recommended to use a webserver like nginx and have it handle all of your requests.

In crappy ASCII form:

                +----------+
                | Client 2 |
                +----------+
                      |
                      V 
+----------+      +-------+      +----------+
| Client 1 |----->| nginx |<-----| Client 3 |
+----------+      +-------+      +----------+
                      ^
                      |
                      V
           /--------------------\
           | useful nginx stuff |
           | like asset serving |
           | and rate limiting  |
           \--------------------/
                      |
                      V
               +-------------+
               | WSGI server |
               +-------------+

To actually run the WSGI server process, you can use Supervisor. It automatically restarts the server if it fails for some reason, keeps logs, and runs as a daemon so your service starts when the server boots.

Solution 2

Basically, no. The built-in development server is not safe for deployment in a production environment.

The built in development server is for just that. For use in production you should follow one of the steps detailed here.

These include different servers that implement the WSGI specification, such as Apache/mod_wsgi or one of these stand-alone wsgi server http://flask.pocoo.org/docs/deploying/wsgi-standalone/

There are also uWSGI and FastCGI options available

Solution 3

While lightweight and easy to use, Flask’s built-in server is not suitable for production as it doesn’t scale well and by default serves only one request at a time. http://flask.pocoo.org/docs/0.12/deploying/

Comments

[Basj]

This answer gives a wider context to this problem, and explains why using the server bundled with Flask should not be used.

[Anton Egorov]

I use supervisor + gunicorn + nginx. It is really easy to setup and maintain.

[HaveAGuess]

"It will not handle more than one request at a time" - not true, see threaded and processes arguments : werkzeug.pocoo.org/docs/0.11/serving

[HaveAGuess]

"if an error pops up, it opens up a shell that allows for arbitrary code to be executed on your server" - isn't that debug=True mode ?

[Blender]

@HaveAGuess: Amended. By default, though, the server will not be multithreaded. Those arguments aren't mentioned anywhere in the Flask docs, so you have to look at Werkzeug's documentation, which I think is more work than most people will do.

[mvarge]

@HaveAGuess: From the flask deployment doc: "Flask’s built-in server is not suitable for production as it doesn’t scale well and by default serves only one request at a time."

[HaveAGuess]

@mvarge agreed but we had it scaled up to multiprocesses with no problems to handle multiple requests for an internal production app. We are now running on Apache for external exposure

[Grey Li]

@Blender Sorry to disturb you. I'm writing a post about Werkzeug, and I have some silly questions. Is the server provided by Werkzeug similar to Gunicorn in functionality? Can I call it "WSGI server"?

[Blender]

@GreyLi: Yeah, both are WSGI servers. That's why you can swap out the dev server for a production server without any code modifications.

[Basj]

1) "It will not handle more than one request at a time by default" => can be changed with threaded option. 2) "If you leave debug mode on and an error pops up, it opens up a shell that allows for arbitrary code to be executed" => this could be easily turned off with a few lines of code. 3) "The development server doesn't scale well." => a benchmark (if someone has one) would be interesting to add concrete facts to help people understand why the bundled server is really so bad. I trust you, but everyone seems to repeat this without source.

[Blender]

@Basj: I would consider the people who wrote the development server to be a canonical source. General-purpose deployment guidelines try to address the common use case, which is deploying a public webservice. Can you get away with using the development server for a low-traffic webservice? Sure, but why waste the effort trying to make the development server into an almost-production server when pip install uwsgi && uwsgi --http :8000 -w yourapp:app works just as well and is actually tailored for that use case?

[SeanQuinn781]

@Haveaguess link is down for me but for the WSGi serving options see here: werkzeug.palletsprojects.com/en/1.0.x/serving. Another alternative to using the development server is to run the Flask app as a service with systemd, nginx proxy and gunicorn: edmondchuc.com/…