Getting Started

First Login

The login page is the entry point for the web app and desktop app. It adapts to the selected database type, can show saved profiles, and can also surface cloud-discovered connections when provider support is enabled.

WhoDB Login Page

Info

In the web app, a successful login is kept server-side: WhoDB stores your database credentials encrypted in a local session database and gives your browser only an opaque, HttpOnly session cookie — the credentials themselves never reach browser storage. Non-secret display details (connection name, host, database) are kept in the browser so the profile switcher and login state survive a page reload.

The desktop app, which cannot rely on cookies, stores saved credentials in the OS keyring instead (for example, macOS Keychain); if no keyring is available, it warns and continues without persisting credentials. For shared or sensitive machines, prefer managed database accounts and environment-defined profiles either way.

Ways To Start A Connection

Manual Credentials

Pick a database type and fill in the fields shown for that type.

Saved Profiles

Choose from previously saved local profiles or profiles injected through environment variables.

Cloud Pickers

When enabled, AWS, Azure, and GCP pickers can prefill the login form from discovered resources.

Sample Database

First-time users can be offered a built-in sample database flow and guided tour.

Step-By-Step

Choose A Database Type

Open the database type dropdown and select the system you want to connect to.

Database Type Dropdown

The available catalog in the current CE codebase includes PostgreSQL, MySQL, MariaDB, CockroachDB, SQLite3, MongoDB, Redis, ElasticSearch, ClickHouse, DuckDB, Memcached, TiDB, Valkey, Dragonfly, OpenSearch, YugabyteDB, QuestDB, and FerretDB.

Fill The Main Fields

The main form changes by database type:

Most network databases use host, username, password, and database
PostgreSQL-family databases can also expose search path / schema behavior
SQLite and DuckDB use a database file path instead of host and port
Some document and cache systems only require a host and optional credentials

Open Advanced Options If Needed

The web app advanced panel is for SSL/TLS and backend-defined database-specific fields.

Advanced Options

Shared SSL fields include:

SSL Mode
SSL CA Content
SSL Client Cert Content
SSL Client Key Content
SSL Server Name

Note

If you need SSH tunneling, set up an external tunnel first or use the CLI & MCP tooling. SSH tunneling is not a web login form control in this codebase.

Connect Or Use A Profile

Click the main connect button for manual credentials, or choose a saved profile and log in through that profile flow.

Saved Profiles

Profiles can appear from two places:

Local profiles saved by the app
Environment-defined profiles such as WHODB_POSTGRES_1, WHODB_MYSQL_1, or WHODB_REDIS_1

When the manual credential form is disabled with WHODB_DISABLE_CREDENTIAL_FORM=true, the login page can still work through managed profiles and cloud pickers.

Cloud-Discovered Connections

When any of these flags are enabled:

WHODB_ENABLE_AWS_PROVIDER=true
WHODB_ENABLE_AZURE_PROVIDER=true
WHODB_ENABLE_GCP_PROVIDER=true

the login page can show provider-specific pickers below the standard form. Picking a discovered resource does not skip the normal connection flow; it prefills the same login form with the discovered endpoint and connection metadata.

File-Based Databases

SQLite3 and DuckDB behave differently from host-based systems:

The required field is the database file path
The desktop app can open a native file picker for these databases
DuckDB is only available on supported builds

Next Steps

Database Connectivity

See the current CE connection model and advanced option reference.

Supported Databases

Review the current database catalog grouped by compatibility family.

Cloud Providers

Enable and manage AWS, Azure, and GCP discovery.

Quick Start

Move from login to exploring data and writing queries.

Installation

Quick Start Guide