Main Page: https://libredb.org
Git: https://github.com/libredb/libredb-studio
Licence: MIT
Dockerfile: Yes, published multi-arch image (amd64 and arm64): ghcr.io/libredb/libredb-studio:0.14.1
Demo: https://trial.libredb.org (admin@libredb.org / Admin!2026)
Summary
LibreDB Studio is a database client you run on your own server and use from a browser tab, so nobody has to install a desktop client and no third party sees your credentials. It ships 16 drivers of its own: PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL, DuckDB, MongoDB, Redis, Couchbase, ClickHouse, Druid, Elasticsearch, OpenSearch, Trino and Cassandra. Another 26 engines speak the same wire protocols and connect through those same drivers, MariaDB through the MySQL one and Valkey through the Redis one, which is where the figure of 42 reachable engines comes from. You point it at a database you already run, browse the schema, write and run queries and edit rows. It keeps its own state in a local SQLite file, so there is no separate admin database to provision alongside it.
Notes
The parts that matter for packaging on Cloudron:
Authentication is on by default. A plain docker run with no variables does not leave an open dashboard; without a session cookie every path redirects to /login, and the API routes that touch a database re-check the session. If ADMIN_PASSWORD and JWT_SECRET are not supplied they are generated on first start, written 0600, and the admin password is printed once in the container log. There is no default password anywhere. AUTH_BOOTSTRAP=off turns that generation off and makes ADMIN_PASSWORD genuinely required, which is probably what a package would want.
Connection secrets are encrypted at rest with AES-256-GCM, key derived by HKDF-SHA256 from STORAGE_ENCRYPTION_KEY, or from JWT_SECRET when that is not set. Passwords, connection strings, SSL client keys and the three SSH tunnel fields are encrypted; host, port, user and database name stay readable so the connection list can be sorted without decrypting anything.
Two things I would rather say up front than have you find later. First, STORAGE_PROVIDER must be set to sqlite, because with it unset the app falls back to browser storage and connections never reach the server at all. That is a bad default and it is ours. Second, in sqlite mode without STORAGE_ENCRYPTION_KEY the key derives from JWT_SECRET, which lives in auth-bootstrap.json in the same directory as the database file, so a volume snapshot carries both. Passing STORAGE_ENCRYPTION_KEY from the environment fixes that, and a Cloudron package is exactly the right place to do it.
There is no TLS in the app itself, it listens on plain HTTP behind a reverse proxy, which is how Cloudron works anyway. The container starts as root and the entrypoint drops to UID 1001 via gosu after fixing ownership of /app/data. There is no HEALTHCHECK in the image, but GET /api/db/health exists and is wired into the compose example and the Helm probes. The image is about 312 MB compressed and an idle container sits at roughly 57 MiB of RAM.
An AI assistant is included, off by default, and it does nothing without your own key (Gemini, OpenAI, or a local Ollama).
I help maintain it, so treat this as an interested party asking rather than a neutral recommendation.
Alternative to: CloudBeaver, Adminer, phpMyAdmin, pgAdmin, DBeaver
The nearest comparison is CloudBeaver, and the difference is licensing rather than features: their fine grained permissions, SSO and part of the administration live in the enterprise edition, while SSO, diagrams, the AI assistant and the NoSQL engines are all in the same MIT build here, with no paid tier and no licence key. LibreDB Studio is younger and CloudBeaver is more mature; that is the honest trade.
