Settings - Gunicorn

Generated file — update gunicorn/config.py instead.
This reference is built directly from gunicorn.config.KNOWN_SETTINGS and is regenerated during every documentation build.
Settings can be provided through the GUNICORN_CMD_ARGS environment variable. For example:
Command line: -c CONFIG, --config CONFIG
Default: './gunicorn.conf.py'
The Gunicorn config file.
A string of the form PATH, file:PATH, or python:MODULE_NAME.
Only has an effect when specified on the command line or as part of an application specific configuration.
By default, a file named gunicorn.conf.py will be read from the same directory where gunicorn is being run.
Loading the config from a Python module requires the python: prefix.
A WSGI application path in pattern $(MODULE_NAME):$(VARIABLE_NAME).
Command line: --control-socket PATH
$XDG_RUNTIME_DIR/gunicorn.ctl or $HOME/.gunicorn/gunicorn.ctl
Unix socket path for control interface.
The control socket allows runtime management of Gunicorn via the gunicornc command-line tool. Commands include viewing worker status, adjusting worker count, and graceful reload/shutdown.
Default: $XDG_RUNTIME_DIR/gunicorn.ctl if XDG_RUNTIME_DIR is set, otherwise $HOME/.gunicorn/gunicorn.ctl. The parent directory is created automatically if needed.
Use --no-control-socket to disable.
Command line: --control-socket-mode INT
Permission mode for control socket.
Restricts who can connect to the control socket. Default 0600 allows only the socket owner. Set to 0660 to allow group access.
Command line: --no-control-socket
Disable control socket.
When set, no control socket is created and gunicornc cannot connect to this Gunicorn instance.
Command line: --reload
Restart workers when code changes.
This setting is intended for development. It will cause workers to be restarted whenever application code changes.
The reloader is incompatible with application preloading. When using a paste configuration be sure that the server block does not import any application code or the reload will not work as designed.
The default behavior is to attempt inotify with a fallback to file system polling. Generally, inotify should be preferred if available because it consumes less system resources.
In order to use the inotify reloader, you must have the inotify package installed.
Enabling this will change what happens on failure to load the the application: While the reloader is active, any and all clients that can make requests can see the full exception and traceback!
Command line: --reload-engine STRING
The implementation that should be used to power reload.
Command line: --reload-extra-file FILES
Extends reload option to also watch and reload on additional files (e.g., templates, configurations, specifications, etc.).
Entries containing *, ? or [ are treated as glob patterns and are re-expanded on every reload check, so a file created after startup starts being watched without restarting gunicorn. Note that it is the first edit to that file which triggers a reload, not its creation. Use ** to recurse, and keep patterns narrow: a recursive pattern over a large tree is walked once per check.
Two things behave the way glob does, not the way a path does. * does not match dotfiles, so list .env literally rather than expecting * to find it. And a literal path that happens to contain *, ? or [ is read as a pattern, so it warns and matches nothing instead of failing outright the way a missing plain path does.
Patterns are relative to the directory gunicorn is started from, not to chdir, which is applied later.
Glob patterns are supported.
Command line: --spew
Install a trace function that spews every line executed by the server.