Getting Started

Installation

Installation Guide

WhoDB can run as a container, a standalone binary, a desktop app, or a local source checkout.

Installation Methods

Docker

Run the published image and expose the web UI on port 8080.

Binary

Download a release binary and run it directly.

Build From Source

Build the frontend and backend from this repository.

Desktop App

Use the Wails desktop shell around the same core app.

Docker Compose

YAML

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.

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:

Bash

chmod +x whodb
./whodb

Build From Source

Prerequisites

  • Go 1.26.1 or newer
  • Node.js and pnpm

Build Steps

Development Mode

Use two terminals:

Bash

cd core
go run ./cmd/whodb

Bash

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_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:

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"}
]'

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:

Bash

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

Bash

PORT=3000 ./whodb

To publish the default container listener on host port 3000:

Bash

docker run -d \
  -p 3000:8080 \
  clidey/whodb:latest

If you intentionally change the internal listener with PORT, map the same internal port:

Bash

docker run -d \
  -e PORT=3000 \
  -p 3000:3000 \
  clidey/whodb:latest

Verify The Install

Troubleshooting

First Login

Walk through the connection flow after WhoDB is running.

Cloud Providers

Enable managed discovery for AWS, Azure, and GCP.