Chat2DB's encryption key is the whole install contract

One key file gates both saved passwords and your AI model keys

Stored datasource passwords and AI model API keys are encrypted with AES-256-GCM under a single per-installation key. Both purposes use that one key, separated by authenticated AAD values, so a ciphertext captured from the password store cannot be decrypted as an API key or the reverse. The key must be valid Base64 that decodes to exactly 32 bytes, and the bundled initializer emits the standard padded form: 44 Base64 characters ending in `=`. It is cryptographic key material, not a password you can retype from memory.

The design choice that follows from this is worth naming. A local-first client with no accounts still holds every production credential you point it at. Encrypting them with a key that lives beside them buys very little against an attacker who already has filesystem access to your user account, and it costs you a hard failure mode: replace or lose the key and every previously stored datasource password and AI API key becomes unreadable.

Web and headless startup fails without the key, Desktop quietly creates one

This is the sharpest edge in the project. Web/headless startup fails when no valid key is provided. Only Desktop mode creates a missing key automatically.

So the same install can behave two different ways depending on which surface you launch. Start the desktop app first on a machine, let it generate a key, and the failure never appears. Deploy the Docker container on a fresh host with no key mounted, and the service does not come up in a degraded, keyless mode. It stops. For a Docker deployment the ordering is forced on you, and the README puts it in that order: create the key before you start the container.

The key path is resolved in a fixed priority order: the positional argument passed to the script, then `CHAT2DB_COMMUNITY_ENCRYPTION_KEY_FILE`, then the default location. If you pass a custom path to the initializer you must configure the identical path on the Chat2DB side or the two halves disagree about where the key lives, and the web process will refuse to start rather than silently generate a second key.

The Docker run example and the Compose file write to two different volumes

The two documented ways to run the container are not interchangeable, and the README says so in one line that is easy to miss. The `docker run` example stores application data in `$HOME/.chat2db-community-docker`. The Compose definition uses the `chat2db-community-data` named volume. These locations do not share data.

Someone who starts with the `docker run` block, gets comfortable, then switches to the Compose path expecting the same instance finds an empty workspace. Their saved datasources are in the bind mount, not the named volume.

The Compose variant is the shorter of the two, once the key already exists:

./script/security/init-community-encryption-key.sh
docker compose --file docker/docker-compose.yml up --detach

There is a second trap layered on top. Chat2DB Community 5.3.0 uses the independent `/root/.chat2db-community` directory and does not automatically migrate data from earlier images that used `/root/.chat2db`. If you came from an image older than 5.3.0, your datasources are still sitting in the old directory with nothing moving them. Upgrading the container image alone does not bring them forward.

Updating means destroying and recreating the container

The documented update path is not a pull and restart. To update, pull the new image, remove the old container, and run the start command again. Keep `~/.config/chat2db-community/encryption.key` across rebuilds.

Read that as an operational instruction rather than a convenience note. There is no container in place while the update runs, and the encryption key lives outside the container on purpose, mounted read-only at `/run/secrets/chat2db-community-encryption.key`. If your update procedure follows the usual instinct of clearing stray files under `$HOME`, the key goes with it, and the next start fails. Whatever script automates your updates has to treat that one file as protected data.

The Compose variant needs the same care with the named volume, which is why the README keeps pointing at the key file rather than at the data directory. The data volume survives; the key is the thing that does not come back on its own.

No user accounts, so the HTTP port is the entire access control

Chat2DB Community is a single-user, local-first application. It has no user accounts or authorization boundaries between users. Keep the HTTP service bound to `127.0.0.1` or `::1` and do not expose it to other users or untrusted networks.

The Docker example obeys this by publishing `127.0.0.1:10825:10825`, which binds the loopback interface on the host rather than all interfaces. Any host firewall rule you relaxed, any reverse proxy you put in front of it, any tunnel that forwards a port, converts a single-user local tool into an unauthenticated SQL execution surface with every datasource credential loaded. There is no login screen to get past and nothing to configure. The binding is the control.

This rules out the deployment shape most teams actually want. A shared browser-accessible database console for a data team is not a configuration problem here, because there is no authentication layer to configure. If you need one, you are looking at a different tool.

Custom JDBC drivers are executable Java code, and everything imported stays untrusted

Adding a database without writing code is the advertised extension path: new JDBC databases can be added through configuration only, without code changes. That flexibility arrives with a specific risk the project states plainly. Custom JDBC drivers are executable Java code, install them only from sources you trust.

A JDBC driver is a jar that runs inside the Chat2DB process with the same privileges as the application itself, and it executes when a connection is opened. A driver pulled from an unverified download page is arbitrary code execution on your workstation, arriving through the same workflow that a legitimate database uses. Verify the artifact before it enters the driver path.

The same framing applies to everything else the application ingests. Imported configuration files, archives, SQL files, database contents, and AI responses remain untrusted data. Database contents in particular means a value sitting in a `users.email` column on a shared database is data your client will parse and your AI assistant may send to whichever model endpoint you configured.

Your AI model runs on your own endpoint, which decides what leaves the machine

The AI assistant is bring-your-own-model. You supply the model, and it is used to generate, explain, and optimize SQL in natural language. Nothing about a hosted model is assumed, and that is the point of the design: the local-first claim extends to the inference call.

The consequence for you is that choosing the endpoint is a data-protection decision, not a convenience setting. Context taken from a production schema, values read out of a table, and the AI responses that come back are all named as untrusted data by the project. A production database plus a third-party model endpoint means schema details and query fragments leave your machine by design. A local model endpoint keeps that traffic on the host.

The newest line extends this surface rather than shrinking it. The 5.4.0-beta.1 early preview adds an optional local agent runtime with skills, external MCP servers, and file and terminal tools, enabled by choosing Pi Agent in the AI input's runtime selector. The first selection asks for confirmation and downloads the runtime. File and terminal tools in a tool that already holds your database credentials is a materially larger blast radius than query generation, which is why it sits behind a confirmation rather than a flag.

The preview channel and the stable channel are deliberately out of step

Release naming here carries meaning, and the README is careful about it. `Latest` stays on the stable build. The regular Beta line continues with `5.3.8-beta.x`. Enable Receive Beta versions in Settings → About Us to receive beta builds in the app. The early preview is neither the stable nor the regular Beta release.

So at the time of writing there are three moving parts: v5.3.8 published on 2026-10-09, a regular Beta line now at v5.3.9-beta.2 (2026-10-29), and v5.4.0-beta.1 published on 2026-09-23 as an early preview carrying the agent runtime. Reading a version number off a release tag does not tell you which of those you would actually get from the download button.

The repository's last push landed on 2026-11-02 and the project is not archived, so it is moving fast enough that release-channel discipline is worth checking before you pin anything into a script.

Editorial conclusion

Adopt Chat2DB Community if you want one desktop client that opens MySQL, Postgres, ClickHouse, MongoDB and Snowflake side by side and you are willing to own a key file as carefully as you own a password manager vault. Do not adopt it for a team server: it has no user accounts and no authorization boundaries between users, so anything beyond 127.0.0.1 is out of bounds. Before the first connection, copy ~/.config/chat2db-community/encryption.key somewhere outside the container volume, and confirm which of your production credentials you are actually willing to store in a desktop app rather than in a vault you control.

Frequently asked questions

Official sources

1. Issues
2. OtterMind/Chat2DB on GitHub
3. Project website
4. README
5. Releases