What problem does this solve?
The current Docker configuration runs the app using CMD ["python", "app.py"]. This starts Flask’s built-in Werkzeug development server, which isn't safe or efficient for production. As the Flask docs warn, the dev server lacks the concurrency, stability, and scaling capabilities needed to handle real-world traffic. Leaving it active limits performance and creates unnecessary security risks.
Proposed solution
I propose switching the container to use Gunicorn as our WSGI server. This involves two steps:Add Gunicorn: Add gunicorn==23.0.0 to requirements.txt.Update the Dockerfile: Change the CMD instruction to use Gunicorn with multiple workers and threads to handle traffic efficiently:
CMD ["gunicorn", "--workers", "4", "--threads", "2", "--bind", "0.0.0.0:5000", "app:app"]
Alternatives considered
-Leaving the server as it is: keeps the development server active, which violates deployment best practices and triggers a "Do not use in production" log warning.
-Using uWSGI: a good alternative, but requires C-compiler dependencies that slow down the Docker build process. Gunicorn is a cleaner choice because it installs instantly via pip and works perfectly with our python:3.9 - slim base image.
Which part of the app does this affect?
Other
Estimated complexity
Medium (one function and one template change)
Before submitting
What problem does this solve?
The current Docker configuration runs the app using CMD ["python", "app.py"]. This starts Flask’s built-in Werkzeug development server, which isn't safe or efficient for production. As the Flask docs warn, the dev server lacks the concurrency, stability, and scaling capabilities needed to handle real-world traffic. Leaving it active limits performance and creates unnecessary security risks.
Proposed solution
I propose switching the container to use Gunicorn as our WSGI server. This involves two steps:Add Gunicorn: Add gunicorn==23.0.0 to requirements.txt.Update the Dockerfile: Change the CMD instruction to use Gunicorn with multiple workers and threads to handle traffic efficiently:
Alternatives considered
-Leaving the server as it is: keeps the development server active, which violates deployment best practices and triggers a "Do not use in production" log warning.
-Using uWSGI: a good alternative, but requires C-compiler dependencies that slow down the Docker build process. Gunicorn is a cleaner choice because it installs instantly via pip and works perfectly with our python:3.9 - slim base image.
Which part of the app does this affect?
Other
Estimated complexity
Medium (one function and one template change)
Before submitting