Ask a Question
Report a Bug
This page in other versions:
This document in other formats:
pgAdmin may be deployed as a web application by configuring the app to run in
server mode and then deploying it either behind a webserver running as a reverse
proxy, or using the WSGI interface.
The following instructions demonstrate how pgAdmin may be run as a WSGI
application under Apache HTTP, using mod_wsgi.
Important: Some components of pgAdmin require the ability to maintain affinity
between client sessions and a specific database connection (for example, the
Query Tool in which the user might run a BEGIN command followed by a number of
DML SQL statements, and then a COMMIT). pgAdmin has been designed with built-in
connection management to handle this, however it requires that only a single
Python process is used because it is not easily possible to maintain affinity
between a client session and one of multiple WSGI worker processes.
On Windows systems, the Apache HTTP server uses a single process, multi-threaded
architecture. WSGI applications run in embedded mode, which means that only
a single process will be present on this platform in all cases.
On Unix systems, the Apache HTTP server typically uses a multi-process, single
threaded architecture (this is dependent on the MPM that is chosen at
compile time). If embedded mode is chosen for the WSGI application, then
there will be one Python environment for each Apache process, each with it’s own
connection manager which will lead to loss of connection affinity. Therefore
one should use mod_wsgi‘s daemon mode, configured to use a single
process. This will launch a single instance of the WSGI application which is
utilised by all the Apache worker processes.
Whilst it is true that this is a potential performance bottleneck, in reality
pgAdmin is not a web application that’s ever likely to see heavy traffic
unlike a busy website, so in practice should not be an issue.
Future versions of pgAdmin may introduce a shared connection manager process to
overcome this limitation, however that is a significant amount of work for
little practical gain.
In order to configure pgAdmin to run in server mode, it is first necessary to
configure the Python code to run in multi-user mode, and then to configure the
web server to find and execute the code.
Note that there are multiple configuration files that are read at startup by
pgAdmin. These are as follows:
In order to configure the Python code, follow these steps:
Create a config_local.py file alongside the existing config.py file.
Edit config_local.py and add the following setting:
SERVER_MODE = True
In most cases, the default file locations are setup for running in desktop mode.
Add settings similar to the following to config_local.py to use paths suitable
for server mode.
NOTE: You must ensure the directories specified are writeable by
the user that the web server processes will be running as, e.g. apache or www-data.
LOG_FILE = '/var/log/pgadmin4/pgadmin4.log'
SQLITE_PATH = '/var/lib/pgadmin4/pgadmin4.db'
SESSION_DB_PATH = '/var/lib/pgadmin4/sessions'
STORAGE_DIR = '/var/lib/pgadmin4/storage'
Run the following command to create the configuration database:
# python setup.py
Change the ownership of the configuration database to the user that the web server
processes will run as, for example, assuming that the web server runs as user
www-data in group www-data, and that the SQLite path is /var/lib/pgadmin4/pgadmin4.db:
# chown www-data:www-data /var/lib/pgadmin4/pgadmin4.db
Once Apache HTTP has been configured to support mod_wsgi, the pgAdmin
application may be configured similarly to the example below:
WSGIScriptAlias / "C:\Program Files\pgAdmin4\web\pgAdmin4.wsgi"
<Directory "C:\Program Files\pgAdmin4\web">
Allow from all
WSGIDaemonProcess pgadmin processes=1 threads=25
WSGIScriptAlias / /opt/pgAdmin4/web/pgAdmin4.wsgi
Allow from all
Note: If you’re using Apache HTTPD 2.4 or later, replace the lines:
Allow from all
Require all granted
Adjust as needed to suit your access control requirements.