LibreDB Studio is an open source database manager that runs in your browser and deploys on your own server with a single Docker command. Your entire team works from a single shared instance, rather than installing a desktop client on each machine. Version 0.16.0 was released on September 17, 2026 under the MIT license and connects with 16 native engines, from PostgreSQL, MySQL and Oracle to MongoDB, Redis and ClickHouse.
Before installing: use version 0.16.2 or later. Two of the fixes in the 0.16 series close cross-account bugs in shared instances. Details are in the security section, below.
What is LibreDB Studio?
LibreDB Studio is a web SQL IDE (a web SQL IDE, or self-hosted SQL client) built on Next.js, with the Monaco editor, the same engine as VS Code. The project positions itself between heavy desktop clients, like DataGrip or DBeaver, and command-line tools.
It covers what you expect from a desktop client:
- autocomplete that knows your schema
- visual EXPLAIN plans
- interactive entity-relationship diagrams, exportable to PNG or SVG
- schema comparison with migration SQL generation
- a virtualized data grid with inline editing
- export to CSV and JSON
And it adds features that only make sense on a shared server: single sign-on with OIDC, an audit log of queries and connections provisioned by the administrator.
It also has an AI panel. It generates SQL from natural language, warns before executing destructive queries and explains execution plans. It works with Gemini, OpenAI or a local model via Ollama. The AI is a panel within a conventional SQL IDE, not the purpose of the product, and no AI feature activates until you configure an API key.
What changed in 0.16.0 is the schema tree. Each engine now declares its own object types, so views, materialized views, ClickHouse dictionaries, Oracle packages and Redis function libraries appear with the name each engine uses. Before, the tree was a flat list of tables. You can open an object’s definition in a read-only tab and, in PostgreSQL functions and procedures, you can also edit and apply it.
Is LibreDB Studio free?
Yes. The code is licensed under MIT and the repository states that nothing is locked behind an enterprise paywall. SSO, RBAC, the audit log and the monitoring panel are all in the open source version. The project is funded through GitHub Sponsors.
What databases does it support?
Version 0.16 has native providers for these engines:
- SQL: PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL/Turso, DuckDB, ClickHouse
- Analytics and search: Apache Druid, Elasticsearch, OpenSearch, Trino
- Document and columnar: MongoDB, Couchbase, Cassandra
- Key-value: Redis
More than twenty additional engines connect through one of those drivers because they speak the same protocol, like MariaDB, TiDB, Valkey, CockroachDB, TimescaleDB or YugabyteDB.
Here the project does something unusual: it tests each compatible engine against a real instance and publishes a support level (Full, Partial or Query editor only). It also documents known inaccuracies. For example, in Citus the row count describes the coordinator’s empty table, not the shards. Review that table before trusting a number on a compatible engine. The list grows with nearly every release, so take these figures as current as of the date this note was published.
How do I install LibreDB Studio with Docker or Helm?
The fastest path is Docker:
docker run -d -p 3000:3000 ghcr.io/libredb/libredb-studio:0.16.2
Open http://localhost:3000. On first startup, the server generates the admin password and JWT secret, and prints the password once in the container log (docker logs <container>).
The project documentation uses the :latest tag. We pin 0.16.2 because patch versions were released on September 19 and 21, just days after 0.16.0, and one of them is a security fix. Since 0.16.1, each tag is also published in -alpine and -alpine-slim variants. The -alpine-slim is the smallest image, but doesn’t include the DuckDB driver.
Without Docker, you can run it with Node.js 20.9 or later:
npx @libredb/studio
On Kubernetes, pin the chart version:
helm repo add libredb https://libredb.org/libredb-studio/
helm repo update
helm install libredb libredb/libredb-studio --version 0.1.68
Chart 0.1.68 deploys version 0.16.2 of the application by default. The README also documents Homebrew, deb/rpm packages with systemd service, Snap and winget.
How do I set up a shared database manager for your team?
Startup without configuration is fine for a local test, not for a team. Four adjustments make a difference.
1. Disable autogenerated secrets
Set AUTH_BOOTSTRAP=off, which is what the project recommends in production. Then configure JWT_SECRET yourself (minimum 32 characters; the README suggests openssl rand -base64 32) and ADMIN_PASSWORD.
2. Use SSO, not local accounts
The local provider has exactly two accounts: an administrator and an optional user. Everyone who knows the user password shares that same identity. Per-person identity comes from OIDC:
NEXT_PUBLIC_AUTH_PROVIDER=oidc
OIDC_ISSUER=https://your-provider.com
OIDC_CLIENT_ID=your_client_id
OIDC_CLIENT_SECRET=your_client_secret
OIDC_ROLE_CLAIM=realm_access.roles # optional: assign admin role from a claim
Works with any OIDC provider, such as Keycloak, Okta, Azure AD, Auth0, Zitadel, or Google.
If you stick with local accounts, 0.16.0 added an optional second factor: a 6-digit TOTP code, activated per account with ADMIN_TOTP_SECRET and USER_TOTP_SECRET, or with secrets.adminTotpSecret and secrets.userTotpSecret in the chart. The secret must be valid base32 and decode to at least 128 bits. An invalid value blocks login with an error naming the variable, instead of silently disabling the factor.
3. Provision connections so nobody has credentials
A YAML file of seed connections defines connections centrally. Each connection is restricted by role, and passwords are injected from environment variables with the syntax ${ENV_VAR}, never written in the file. Mount it and point SEED_CONFIG_PATH to it. Connections marked with managed: true are read-only for users.
4. Choose persistent storage
The default, STORAGE_PROVIDER=local, saves connection metadata in each person’s browser. Use sqlite or postgres (with STORAGE_POSTGRES_URL) to save them on the server, per user.
With that, the admin audit tab logs queries executed from the application. Since 0.16.0 you can export it filtered.
What to check before opening it to your team?
In the 0.16 series the project found and fixed two flaws that only appear in shared instances:
- 0.16.0: on a shared connection, one account could roll back another account’s unconfirmed transaction. Now each transaction belongs to the account that opened it, with a five-minute grace period of inactivity.
- 0.16.2: the maintainers scored 8.8 the advisory GHSA-3wh2-8x78-jfw4. A request could name the connection identifier from another session and receive that live, already authenticated connection. A
useraccount could reach a connection restricted to administrators. The release notes recommend updating if more than one account accesses your instance.
Both were published with full detail, and reproductions became tests. It’s a good sign about the project, but it also tells you where the risk is: don’t run anything before 0.16.2 on a multi-user instance.
Three limits worth knowing before it goes through a security review:
- Data masking is client-side only. The README states it explicitly: API responses still include full values. It works for screen sharing, not for protecting data.
- TOTP code reuse across replicas. The registry of used codes lives in the process memory, so with multiple replicas a captured code can be reused once per additional replica. The project documents this in
docs/SECURITY.md. - Serving it from a subroute requires building your own image. Behind a proxy (for example, at
/tools/libredb),BASE_PATHis set at compile time, so the published image can’t be relocated. You have to build yours with the Docker build argument.
DBeaver or LibreDB Studio?
The difference is architectural more than functional.
- A desktop client lives on each developer’s machine, and each person stores their own connection credentials.
- LibreDB Studio is a single deployment alongside your databases. People log in with your identity provider, credentials stay on the server, and each query lands in one audit log.
That trade-off fits teams that today share database passwords so people can query. If you’re looking for a DBeaver alternative for a team, this is the pitch.
If you work alone, a desktop client needs no server or SSO. LibreDB now also publishes a desktop version for Linux (AppImage, .deb, and Flatpak) that runs the server as a local process, without a login screen. Its public roadmap still lists, as of this note’s publication date, shared workspaces, SAML 2.0, and server-side data masking as pending.