In production an application is installed by a normal pip install <app>
With 0.5 the preferred way to served the application was:
* in development
- 'paste' HTTP server -- (WSGI protocol) -> application
- 'memory' sessions manager
* in production
- 'nginx' (or 'apache') reverse proxy -- (FastCGI protocol) --> 'flup' FastCGI adapter -- (WSGI protocol) --> application
- 'memcache' sessions manager
With 0.6:
* in development
- 'gunicorn' HTTP server --- (WSGI protocol) --> application
- 'memory' sessions manager
* in production
- 'nginx' (or 'apache') reverse proxy -- (proxy pass HTTP) --> 'gunicorn' -- (WSGI protocol) --> application
- 'memcache' or 'redis' sessions manager
So, with 0.6, the application is always served by 'gunicorn'. In production, 'nginx' is added in front of it to serve the statics assets (CSS, JS, images ...), handle HTTPS protocol, rewrite some URL if needed ... Also in production, 'gunicorn' is better configurated with multiple worker processus to utilize all the CPU cores of the server and bypass the Python GIL limitation with threads. That's why, in this case, the sessions must by store in an external 'memcache' or 'redis' server because processes can't share sessions in RAM.
Hint: the `nagare-commands-proxy` package adds the `nagare-admin proxy` command to help generate the 'nginx' or 'apache' proxy pass configuration fragment.
-Henrik