🔥Windows users and Jam.py with gunicorn

[Dean D. Babic]

Hi all,

looks like gunicorn does NOT run on Windows!

Which means Windows users can't run production ready wsgi server.

However, I just found that UVICORN runs nicely in Windows:
https://uvicorn.dev/

Install with:
pip install asgiref uvicorn

What is needed is a slight modification of wsgi.py file in project folder,

call it asgi.py:

from jam.wsgi import create_application
from asgiref.wsgi import WsgiToAsgi
application = WsgiToAsgi(create_application(__file__))

That is it.

run in your project folder with:
uvicorn.exe asgi:application

Enjoy

[Fabio Lenzarini]

Thanks Dean,
what are the advantages of using Unicorn instead of the built-in server?

ciao

Fabio

--
You received this message because you are subscribed to the Google Groups "Jam.py Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jam-py+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jam-py/bdf9b0f5-856a-46ce-8576-4463fd908015n%40googlegroups.com.

[Dean D. Babic]

:)

I mean, that easy, right? 

Below is all from Chatgpt, no need to depend on me :)

D.

For many people, the single biggest and most dangerous disadvantage of using the default Python web server (especially Flask/Jam.py dev server built on Werkzeug) is:

⚠️ The Werkzeug Interactive Debugger Exposure

When debug mode is ON, Werkzeug exposes:

• A full interactive Python console in the browser

• With read/write access to your server

• Allowing full remote code execution (RCE)

If exposed to the internet, anyone can take over your machine instantly.

This is not a “small risk” — it is a catastrophic security hole.

---

The main disadvantages of using Python’s default web server (e.g., python -m http.server, Flask’s built-in server, Django’s runserver, Jam.py’s development server, etc.) are the following:

Why the default / built-in server is NOT recommended for production 1. Not designed for concurrency

The built-in server is typically single-threaded or uses very limited threading.
This means:

• Poor performance under multiple simultaneous requests

• Slow responses when one request blocks others

• No efficient use of modern multi-core CPUs

Production servers like Gunicorn, uWSGI, or Waitress can spawn many workers and scale properly.

---

2. No robustness / no automatic restarts

If the built-in server crashes:

❌ It does NOT restart
❌ It does NOT isolate worker failures
❌ It offers no graceful reloads

A production server supervises workers and keeps the service alive.

---

3. No protection or hardening

Default servers lack:

• Request timeouts

• Rate limits

• Connection limits

• Slowloris mitigation

• Security headers

• Proper TLS/HTTPS support

They are insecure for public exposure.

---

4. No process management

You cannot run the built-in server under:

• systemd units

• service supervision

• log rotation

• error reporting

Production stacks integrate cleanly with system services.

---

5. Cannot handle high load

Default servers cannot:

• Serve many requests per second

• Keep persistent connections

• Handle WebSockets reliably

• Serve large files efficiently

Production servers use event loops, pre-forking, threadpools, and optimised I/O.

---

6. No support for load balancers or reverse proxies

They can’t:

• Pass X-Forwarded-For headers correctly

• Handle Nginx/Apache proxying

• Use UNIX sockets

• Use keep-alive tuning

This becomes critical as soon as you put traffic behind Nginx/F5/A10 etc.

---

7. Hot reloading is slower

Development servers often force:

• Full reload on file change

• Long recompile times

• No control over live workers

Production servers support zero-downtime reloads (USR2 signals in Gunicorn, etc.).