Is the Server Bundled with Flask Safe to Use in Production

python flask to production server

By default, app.run() hosts server on localhost(127.0.0.1). To make it accessible,

app.run('0.0.0.0', port=5000)

Although, the server bundled with Flask is not for production, it is recommended to use WSGI server(mod_wsgi, nginx, gunicorn, etc.)

https://flask.palletsprojects.com/en/1.0.x/deploying/wsgi-standalone/

Is running flask in the default server safe (security-wise)?

Short of someone from the Pallets Project speaking up, the official word on the recommendation is

https://flask.palletsprojects.com/en/1.1.x/tutorial/deploy/#run-with-a-production-server

If you have enough access to a server to permit running something that'll listen to a socket, the step of adding a WSGI server isn't a big one. The link above recommends waitress (and provides instructions), but gunicorn and uwsgi will work, too.

Adding my opinion:

Parsing HTTP and dealing with edge-cases is hard, so why should Flask/Werkzeug spend effort dealing with edge cases when there are WSGI front-ends that already take on the responsibility? In their position (which I'm not), I'd punt scaling and security to WSGI servers, and focus on making an excellent framework.

Flask at first run: Do not use the development server in a production environment

As of Flask 2.2, the development server always shows this warning, it is not possible to disable it. The development server is not intended for use in production. It is not designed to be particularly efficient, stable, or secure. Use a production WSGI server instead. See the deployment docs from Flask for more information.

That warning is just a warning though, it's not an error preventing your app from running. If your app isn't working, there's something else wrong with your code.

That warning applies to the development server, not Flask itself. The Flask framework is appropriate for any type of application and deployment.

What are the limitations of the flask built-in web server

There isn't one right answer to this question, but here are some things to keep in mind:

With the right amount of horizontal scaling, it is quite possible you could keep scaling out use of the debug server forever. When exactly you would need to start scaling (or switch to using a "real" web server) would also depend on the environment you are hosting in, the expectations of the users, etc.

The main issue you would probably run into is that the server is single-threaded. This means that it will handle each request one at a time, serially. This means that if you are trying to serve more than one request (including favicons, static items like images, CSS and Javascript files, etc.) the requests will take longer. If any given requests happens to take a long time (say, 20 seconds) then your entire application is unresponsive for that time (20 seconds). This is only the default, of course: you could bump the thread counts (or have requests be handled in other processes), which might alleviate some issues. But once again, it can still be slow under a "high" load. What is considered a "high" load will be dependent on your application and the expectations of a maximum acceptable response time.

Another issue is security: if you are concerned at ALL about security (and not just the security of the data in the application itself, but the security of the box that will be running it as well) then you should not use the development server. It is not ready to withstand any sort of attack.

Finally, the development server could just fail outright. It is not designed to be used as a long-running process (days, weeks, months), and so it has not been well tested to work in this capacity.

So, yes, it has limitations. Yes, you could still conceivably use it in production. And yes, I would still recommend using a "real" web server. If you don't like the idea of needing to install something like Apache or Nginx, you can still go with a solution that is still as easy as "run a python script" by using some of the WSGI Standalone servers, which can run a server that is designed to be in production with something just as simple as running python run_app.py in the command line. You typically just need to create a 4-5 line python script to import and create the server object, point it to your Flask app, and run it.

gunicorn could be run with only the following on the command line, no extra script needed:

gunicorn myproject:app

...where "myproject" is the Python package that contains the app Flask object. Keep in mind that one of developers of gunicorn would probably recommend against this approach. See https://serverfault.com/questions/331256/why-do-i-need-nginx-and-something-like-gunicorn.

---

Related Topics