Installation Guide
July 16, 2026 · View on GitHub
WhoDB can run as a container, a standalone binary, a desktop app, or a local source checkout.
Installation Methods
Docker (Recommended)
Docker Compose
services:
whodb:
image: clidey/whodb:latest
ports:
- "8080:8080"
environment:
- PORT=8080
- WHODB_LOG_LEVEL=info
# Keeps encrypted login sessions valid across container recreation.
# Generate once with: openssl rand -hex 32
- WHODB_ENCRYPTION_KEY=replace_with_openssl_rand_hex_32
restart: unless-stopped
volumes:
- whodb-data:/data
volumes:
whodb-data:
Session Storage
WhoDB keeps login sessions server-side. When you log in from a browser, WhoDB stores your database credentials encrypted (AES-256-GCM) in a local SQLite file under its data directory, and the browser only holds an opaque, HttpOnly session cookie — never the credentials themselves.
Without any configuration, this works out of the box: a plain docker run generates an encryption key on first start and keeps you logged in until the container is recreated (at which point you simply log in again). To keep sessions valid across upgrades and restarts:
- Mount
/dataas a volume so the encrypted session database and generated key persist. - Set
WHODB_ENCRYPTION_KEYto a stable 64-character hex string (openssl rand -hex 32) so the key does not depend on the container's filesystem.
If WhoDB sits behind an HTTPS-terminating reverse proxy (nginx, Traefik, Caddy, a cloud load balancer), also set WHODB_SECURE=true so the session cookie is marked Secure. Leave it unset for plain HTTP, including local development — WhoDB does not infer HTTPS from proxy headers, and setting it on an HTTP deployment causes the browser to drop the cookie.
Binary Installation
Download the appropriate release artifact from GitHub Releases, make it executable if needed, and run it:
chmod +x whodb
./whodb
Build From Source
Prerequisites
- Go
1.26.1or newer - Node.js and
pnpm
Build Steps
Development Mode
Use two terminals:
cd core
go run ./cmd/whodb
cd frontend
pnpm start
The frontend dev server runs on http://localhost:3000 and proxies its backend requests to the WhoDB server.
Desktop App
The desktop app lives in desktop-ce/ and uses the same frontend and backend codepaths. See Desktop App for the current behavior.
Common Environment Variables
Server
| Variable | Description | Default |
|---|---|---|
PORT | HTTP port WhoDB listens on | 8080 |
WHODB_LOG_LEVEL | Logging level: debug, info, warn, error, none | info |
WHODB_LOG_FORMAT | Set to json for JSON logs; unset for the default text format | text |
WHODB_LOG_FILE | Redirect non-HTTP logs to a file. default means /var/log/whodb/whodb.log | unset |
WHODB_ACCESS_LOG_FILE | Redirect HTTP access logs to a file. default means /var/log/whodb/whodb.access.log | unset |
WHODB_ALLOWED_ORIGINS | Comma-separated CORS allowlist | unset |
WHODB_BASE_PATH | URL path prefix for bundled web deployments, such as /whodb | unset |
WHODB_DISABLE_CREDENTIAL_FORM | Hide the manual credential form and require managed profiles/providers | false |
WHODB_MAX_PAGE_SIZE | Maximum rows allowed per page request | 10000 |
WHODB_DISABLE_MOCK_DATA_GENERATION | Disable mock data globally or for named tables | unset |
WHODB_DISABLE_UPDATE_CHECK | Disable release availability checks | false |
WHODB_ENCRYPTION_KEY | 64-char hex key used to encrypt stored login sessions. Auto-generated and persisted to WHODB_DATA_DIR if unset | unset |
WHODB_DATA_DIR | Directory for the encrypted session database and generated key | platform default data directory |
WHODB_SESSION_TTL | Sliding idle timeout for login sessions, as a Go duration (for example 168h) | 168h (7 days) |
WHODB_SECURE | Mark the session cookie Secure. Set to true only when served over HTTPS (including behind a TLS-terminating proxy) | false |
AI Providers
| Variable | Description | Default |
|---|---|---|
WHODB_OLLAMA_HOST | Ollama host | localhost (resolved for Docker/WSL when needed) |
WHODB_OLLAMA_PORT | Ollama port | 11434 |
WHODB_OLLAMA_NAME | Display name for Ollama | unset |
WHODB_OPENAI_API_KEY | OpenAI API key | unset |
WHODB_OPENAI_ENDPOINT | OpenAI API base URL | https://api.openai.com/v1 |
WHODB_OPENAI_NAME | Display name for OpenAI | unset |
WHODB_ANTHROPIC_API_KEY | Anthropic API key | unset |
WHODB_ANTHROPIC_ENDPOINT | Anthropic API base URL | https://api.anthropic.com/v1 |
WHODB_ANTHROPIC_NAME | Display name for Anthropic | unset |
WHODB_LMSTUDIO_BASE_URL | LM Studio base URL | http://localhost:1234/v1 |
WHODB_LMSTUDIO_API_KEY | LM Studio API key | unset |
WHODB_LMSTUDIO_NAME | Display name for LM Studio | unset |
Generic OpenAI-compatible providers can be added with the WHODB_AI_GENERIC_<ID>_* pattern. See Setting Up AI Providers.
Cloud Providers
| Variable | Description | Default |
|---|---|---|
WHODB_ENABLE_AWS_PROVIDER | Enable AWS provider support | false |
WHODB_AWS_PROVIDER | JSON array of AWS provider definitions | unset |
WHODB_ENABLE_AZURE_PROVIDER | Enable Azure provider support | false |
WHODB_AZURE_PROVIDER | JSON array of Azure provider definitions | unset |
WHODB_ENABLE_GCP_PROVIDER | Enable GCP provider support | false |
WHODB_GCP_PROVIDER | JSON array of GCP provider definitions | unset |
See Cloud Providers for examples and discovery details.
Database Connection Profiles
WhoDB can preload connection profiles from environment variables so they appear on the login page.
Profiles work for every database type in the catalog: the prefix is WHODB_ followed by the uppercased type name. Examples for the core types include:
WHODB_POSTGRESWHODB_COCKROACHDBWHODB_MYSQLWHODB_MARIADBWHODB_TIDBWHODB_SQLITE3WHODB_MONGODBWHODB_REDISWHODB_ELASTICSEARCHWHODB_CLICKHOUSEWHODB_DUCKDBWHODB_MEMCACHED
The same pattern applies to the rest of the catalog, such as WHODB_VALKEY, WHODB_DRAGONFLY, WHODB_OPENSEARCH, WHODB_YUGABYTEDB, WHODB_QUESTDB, and WHODB_FERRETDB.
Two formats are supported:
export WHODB_POSTGRES_1='{"alias":"prod","host":"db.example.com","user":"postgres","password":"secret","database":"app","port":"5432"}'
export WHODB_POSTGRES_2='{"alias":"staging","host":"staging.example.com","user":"postgres","password":"secret","database":"app","port":"5432"}'
Each profile object supports these common fields:
| Field | Description |
|---|---|
alias | Label shown on the login page |
host | Database hostname or IP |
user | Username |
password | Password |
database | Database name or file path |
port | Port number as a string |
advanced | Key/value map of advanced options |
SSL Example
For profile-based connections, the backend accepts both certificate content keys and server-side file-path keys:
export WHODB_POSTGRES_1='{
"alias": "prod",
"host": "db.example.com",
"user": "postgres",
"password": "secret",
"database": "app",
"port": "5432",
"advanced": {
"SSL Mode": "verify-ca",
"SSL CA Path": "/etc/certs/ca.pem",
"SSL Client Cert Path": "/etc/certs/client.pem",
"SSL Client Key Path": "/etc/certs/client-key.pem"
}
}'
Custom Port Example
PORT=3000 ./whodb
To publish the default container listener on host port 3000:
docker run -d \
-p 3000:8080 \
clidey/whodb:latest
If you intentionally change the internal listener with PORT, map the same internal port:
docker run -d \
-e PORT=3000 \
-p 3000:3000 \
clidey/whodb:latest
Verify The Install
Troubleshooting
- the database is reachable from the WhoDB process
- firewall rules allow the connection
- credentials are correct
- Docker deployments use the correct host naming (
host.docker.internalfor host services when appropriate)