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

Run the published image and expose the web UI on port 8080. Download a release binary and run it directly. Build the frontend and backend from this repository. Use the Wails desktop shell around the same core app. ```bash docker pull clidey/whodb:latest ``` ```bash docker run -d \ --name whodb \ -p 8080:8080 \ clidey/whodb:latest ``` Visit `http://localhost:8080`.

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 /data as a volume so the encrypted session database and generated key persist.
  • Set WHODB_ENCRYPTION_KEY to a stable 64-character hex string (openssl rand -hex 32) so the key does not depend on the container's filesystem.
Keep `WHODB_ENCRYPTION_KEY` safe and stable. Changing or losing it invalidates every existing session — sessions encrypted with the old key can no longer be decrypted, so users are simply logged out and need to sign in again.

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
The default port is `8080`. Override it with `PORT=3000 ./whodb` if you want a different listener port.

Build From Source

Prerequisites

  • Go 1.26.1 or newer
  • Node.js and pnpm

Build Steps

```bash git clone https://github.com/clidey/whodb.git cd whodb ``` ```bash cd frontend pnpm install pnpm run build:ce cd .. ``` ```bash cd core go build ./cmd/whodb ``` ```bash ./whodb ```

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

VariableDescriptionDefault
PORTHTTP port WhoDB listens on8080
WHODB_LOG_LEVELLogging level: debug, info, warn, error, noneinfo
WHODB_LOG_FORMATSet to json for JSON logs; unset for the default text formattext
WHODB_LOG_FILERedirect non-HTTP logs to a file. default means /var/log/whodb/whodb.logunset
WHODB_ACCESS_LOG_FILERedirect HTTP access logs to a file. default means /var/log/whodb/whodb.access.logunset
WHODB_ALLOWED_ORIGINSComma-separated CORS allowlistunset
WHODB_BASE_PATHURL path prefix for bundled web deployments, such as /whodbunset
WHODB_DISABLE_CREDENTIAL_FORMHide the manual credential form and require managed profiles/providersfalse
WHODB_MAX_PAGE_SIZEMaximum rows allowed per page request10000
WHODB_DISABLE_MOCK_DATA_GENERATIONDisable mock data globally or for named tablesunset
WHODB_DISABLE_UPDATE_CHECKDisable release availability checksfalse
WHODB_ENCRYPTION_KEY64-char hex key used to encrypt stored login sessions. Auto-generated and persisted to WHODB_DATA_DIR if unsetunset
WHODB_DATA_DIRDirectory for the encrypted session database and generated keyplatform default data directory
WHODB_SESSION_TTLSliding idle timeout for login sessions, as a Go duration (for example 168h)168h (7 days)
WHODB_SECUREMark the session cookie Secure. Set to true only when served over HTTPS (including behind a TLS-terminating proxy)false
The `default` log paths write to `/var/log/whodb/`. That works naturally in Docker but usually requires a custom path for local development. `WHODB_BASE_PATH` only applies to production versions, such as the Docker image or a production binary build. It is intended for reverse-proxy subpath hosting like `/whodb/`, not split frontend/backend dev mode.

AI Providers

VariableDescriptionDefault
WHODB_OLLAMA_HOSTOllama hostlocalhost (resolved for Docker/WSL when needed)
WHODB_OLLAMA_PORTOllama port11434
WHODB_OLLAMA_NAMEDisplay name for Ollamaunset
WHODB_OPENAI_API_KEYOpenAI API keyunset
WHODB_OPENAI_ENDPOINTOpenAI API base URLhttps://api.openai.com/v1
WHODB_OPENAI_NAMEDisplay name for OpenAIunset
WHODB_ANTHROPIC_API_KEYAnthropic API keyunset
WHODB_ANTHROPIC_ENDPOINTAnthropic API base URLhttps://api.anthropic.com/v1
WHODB_ANTHROPIC_NAMEDisplay name for Anthropicunset
WHODB_LMSTUDIO_BASE_URLLM Studio base URLhttp://localhost:1234/v1
WHODB_LMSTUDIO_API_KEYLM Studio API keyunset
WHODB_LMSTUDIO_NAMEDisplay name for LM Studiounset

Generic OpenAI-compatible providers can be added with the WHODB_AI_GENERIC_<ID>_* pattern. See Setting Up AI Providers.

Cloud Providers

VariableDescriptionDefault
WHODB_ENABLE_AWS_PROVIDEREnable AWS provider supportfalse
WHODB_AWS_PROVIDERJSON array of AWS provider definitionsunset
WHODB_ENABLE_AZURE_PROVIDEREnable Azure provider supportfalse
WHODB_AZURE_PROVIDERJSON array of Azure provider definitionsunset
WHODB_ENABLE_GCP_PROVIDEREnable GCP provider supportfalse
WHODB_GCP_PROVIDERJSON array of GCP provider definitionsunset

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_POSTGRES
  • WHODB_COCKROACHDB
  • WHODB_MYSQL
  • WHODB_MARIADB
  • WHODB_TIDB
  • WHODB_SQLITE3
  • WHODB_MONGODB
  • WHODB_REDIS
  • WHODB_ELASTICSEARCH
  • WHODB_CLICKHOUSE
  • WHODB_DUCKDB
  • WHODB_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:

```bash Array Format export WHODB_POSTGRES='[ {"alias":"prod","host":"db.example.com","user":"postgres","password":"secret","database":"app","port":"5432"}, {"alias":"staging","host":"staging.example.com","user":"postgres","password":"secret","database":"app","port":"5432"} ]' ```
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:

FieldDescription
aliasLabel shown on the login page
hostDatabase hostname or IP
userUsername
passwordPassword
databaseDatabase name or file path
portPort number as a string
advancedKey/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"
  }
}'
Cloud-managed variants such as `DocumentDB` and `ElastiCache` accept `WHODB_` profile prefixes like any other catalog type (`WHODB_DOCUMENTDB`, `WHODB_ELASTICACHE`), though provider discovery is the more common way to introduce them. Those provider-discovery paths are still not production-ready in the current CE build, which is why the provider integrations stay disabled unless you explicitly turn them on.

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

Visit `http://localhost:8080` or your configured port. You should see the login page with the current database catalog. Connect to a known local or development database to confirm network reachability and credentials.

Troubleshooting

Use a different external port mapping in Docker or run the binary with `PORT=3000`. ```bash chmod +x whodb ``` Verify:
  • 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.internal for host services when appropriate)
Walk through the connection flow after WhoDB is running. Enable managed discovery for AWS, Azure, and GCP.