LibreDB Studio

The database editor that deploys next to your data, not onto your laptop.

English · 简体中文 · 日本語 · Español · اردو · हिन्दी

Listed by the PostgreSQL project: News · PostgreSQL Clients · Software Catalogue · Community Guide to GUI Tools

Also listed in official Redis, ClickHouse, MariaDB, Trino, Apache Cloudberry, YugabyteDB, DragonflyDB and OpenSearch docs

Quick Start • Live Demo • Install Options • Deploy Your Own

Quick Start

# Docker (recommended)
docker run -p 3000:3000 ghcr.io/libredb/libredb-studio:latest

# or with Node.js 24+ (no Docker)
npx @libredb/studio

If the browser reaches Studio at anything other than localhost or HTTPS (http://192.168.x.x:3000 on a LAN, for example), also set AUTH_COOKIE_SECURE=false. Without it the health check passes while login fails silently and sends you back to the login page.

Need Helm, Homebrew, Snap, winget, or deb/rpm? See all install options.

Live Test

Try LibreDB Studio instantly without installation!

Overview

Why LibreDB Studio?

• Deploys next to the data: container, Helm chart, Rancher, OpenShift operator, one-click PaaS template, or embedded via npm.
• Sixteen engines, one interface: PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL, DuckDB, MongoDB, Redis, Couchbase, ClickHouse, Druid, Elasticsearch, OpenSearch, Trino, Cassandra.
• Runs where you are: browser, phone, Windows, MacOS, Linux desktop.
• A read-only agent, with your own model: state a question, and the run drafts SQL, reads the results, and writes a report whose claims cite them. Gemini, OpenAI, or a local Ollama with open-source models.
• Nothing behind a wall: RBAC, OIDC single sign-on, query audit trail, and ER diagrams all ship under MIT.

Connect to PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, Couchbase, ClickHouse, Druid, Elasticsearch, OpenSearch, Trino, Cassandra, Redis, SQLite, DuckDB, or libSQL with SSL/TLS and SSH Tunnel support.

Key Features

Professional SQL IDE

• Monaco Engine: Powered by the same core as VS Code.
• Smart Autocomplete: Schema-aware suggestions for tables, columns, and SQL keywords.
• Command Palette: Quick access to tables, connections, saved queries, and actions with Cmd/Ctrl+K.
• Multi-Tab Workspace: Handle parallel tasks with independent execution states.
• Saved Query Backups: Export the complete saved-query library as JSON. Import validates the file, preserves query metadata and merges new entries, reporting duplicate IDs while keeping existing queries intact.
• Duplicate Connections: Open an independent (copy) of an editable saved connection in the connection editor, adjust its settings and save. Cancelling leaves the saved connections unchanged; administrator-managed connections cannot be duplicated.
• Visual EXPLAIN: Graphical execution plans to identify performance bottlenecks.
• Interactive ER Diagrams: Visual schema graph with real foreign key edges, cardinality labels, MiniMap navigation, table search/filter, compact mode, and PNG/SVG export. Automatic hierarchical layout powered by ELK.js.
• Schema Diff & Migration: Compare schema snapshots or cross-connection schemas side-by-side. Color-coded diff view (added/removed/modified) with automatic migration SQL generation for PostgreSQL, MySQL, SQLite, Oracle, and SQL Server, plus ClickHouse column modifications.
• Snapshot Timeline: Visual horizontal timeline of schema snapshots. Click any two points to instantly compare and track schema evolution over time.

Visual schema explorer with interactive ER diagrams powered by ReactFlow.

The Database Agent

• Read-only, enforced by the database rather than by a parser. Every statement the agent runs

• Agent mode reads PostgreSQL, SQLite, DuckDB and SQL Server only. The read-only profile is

• Three workflows: Investigate (answer a question), Optimize (compare estimated plans,

• Nothing runs itself. The agent never starts a run for you, never writes to the editor, and

• Evidence or nothing. A claim with no citation cannot be composed, and the run states its own

• Bounded, and the meter is on screen: 18 to 45 statements and a 360 s to 900 s run deadline

• Your own model. Gemini (the default), OpenAI, Ollama, or any OpenAI-compatible endpoint.

• No model configured, no AI. With no LLM_* settings at all, the rail does not render, and

Model-backed helpers

• Universal LLM Support: Defaults to Gemini and serves OpenAI, Ollama, and any OpenAI-compatible endpoint (LM Studio, LiteLLM, vLLM).
• Query Safety Analysis: AI-powered pre-execution risk assessment for destructive queries (DELETE, DROP, TRUNCATE). With no provider configured, the confirmation remains available with a plain query warning. Setting LLM_PROVIDER without its credentials is an unfinished setup, so that error stays visible, as do other configuration and service errors.
• AI Query Explainer: EXPLAIN plans translated into plain language with optimization suggestions.
• Schema Awareness: the connected database's schema is sent as context, so an explanation names your own tables and columns.
• Data Profiler summary: the profiler's per-column statistics written up in prose. That context carries each column's min and max, which are real values from your data; see Agent Data Flow.

Pro Data Management

• Universal Data Grid: Virtualized rendering (TanStack) for millions of rows.
• Inline Editing: Double-click to update values directly in the grid, on engines whose SQL has a single-table row update (the control is hidden elsewhere).
• Column Filtering: Per-column text filters on query results for instant data exploration.
• Interactive Pivot Table: Client-side pivoting with 5 aggregation functions (COUNT, SUM, AVG, MIN, MAX) and SQL generation.
• Expert Exporter: Instant CSV and JSON exports for reporting. CSV import and result export offer comma (default), semicolon and tab separators. Every format the Export menu writes to a file it also copies straight to the clipboard.

Advanced Data Visualization

• 8 Chart Types: Bar, Line, Pie, Area, Scatter, Histogram, Stacked Bar, and Stacked Area charts powered by Recharts.
• Data Aggregation: Group-by with SUM, AVG, COUNT, MIN, MAX aggregation functions. Date grouping by hour, day, week, month, or year.
• Chart Persistence: Save chart configurations and reload them instantly. Manage a library of saved charts.
• Chart Dashboard: Grid view of all saved charts for at-a-glance data overview directly in the bottom panel.

Display Masking (Preview)

• Client-Side Display Layer: Masks sensitive values in the browser UI — useful for screen sharing, demos, and reducing accidental on-screen exposure. Not server-enforced; query API responses still contain full values for authenticated users.
• Column-Name Pattern Matching: 10 built-in patterns (email, phone, credit card, SSN, password, IP, date, financial, and more) match result column headers by regex. Works when the output name matches (e.g., SELECT salary). Aliases (salary AS x) and aggregates (SUM(salary)) are not masked today.
• Configurable Rules: Admin panel to add, edit, enable/disable masking patterns. Email, phone, credit card and SSN presets prefill the Add Pattern form so column patterns can be adapted before saving. Custom patterns support regex. Settings stored per-browser in localStorage.
• RBAC UI Controls: User role cannot toggle or reveal masked cells in the UI. Admin role can toggle masking and temporarily reveal individual cells (10s auto-hide).
• Export & Clipboard: CSV, JSON, and SQL INSERT exports, whether saved as a file or copied to the clipboard, use masked display values when masking is active in the UI. This does not prevent access to raw data via the API, browser DevTools, or admin reveal.
• UI Coverage: Grid, mobile card/table views, row detail sheet, and clipboard copy respect the active display mask.

Analyst & Developer Tools

• AI Data Profiler: One-click table profiling with column statistics (null %, cardinality, min/max, sample values) and AI-powered narrative summaries.
• ORM Code Generator: Generate TypeScript interfaces, Zod schemas, Prisma models, Go structs, Python dataclasses, and Java POJOs from live table schemas.
• Test Data Generator: Schema-aware fake data generation with 30+ semantic column inferences (email, phone, name, address, etc.). Produces INSERT statements or MongoDB insertMany JSON.
• Database Documentation: Auto-generated searchable data dictionary from live schema with AI-powered documentation and Markdown export.

One-click column profiling: null %, cardinality, min/max, and sample values for 300K+ rows.

Generate TypeScript interfaces, Prisma models, Go structs, and more from live schemas.

Authentication & SSO

• Dual Auth Modes: Local email/password login or OpenID Connect (OIDC) Single Sign-On; switchable via environment variable.
• Vendor-Agnostic OIDC: Works with any OIDC-compliant provider — Auth0, Keycloak, Okta, Azure AD, Zitadel, Google, and more.
• One-Command SSO Demo: docker compose -f docker-compose.oidc-demo.yml up starts Studio with a preconfigured Keycloak so you can try SSO and role mapping locally (walkthrough).
• PKCE Security: Authorization Code Flow with Proof Key for Code Exchange (S256) for secure authentication.
• Auto Role Mapping: Configurable claim-based role mapping with dot-notation for nested claims (e.g., realm_access.roles).
• Provider Logout: Logout clears both the local JWT session and identity provider session.

DBA Maintenance Toolkit (Admin Only)

• Live Monitoring Dashboard: 7-tab monitoring with Overview, Performance, Queries, Sessions, Tables, Storage, and Connection Pool views.
• Time-Series Trend Charts: Real-time metric trends (connections, cache hit ratio, buffer pool, deadlocks) with auto-refreshing ring buffer history.
• Configurable Auto-Refresh: Polling intervals from 5s to 60s with play/pause control.
• Threshold Alerting: Color-coded health indicators (healthy/warning/critical) for cache hit ratio, connection usage, deadlocks, and buffer pool utilization.
• Connection Pool Stats: Live total/active/idle/waiting pool metrics with utilization progress bars.
• One-Click Maintenance: Trigger VACUUM, ANALYZE, REINDEX, UPDATE STATISTICS, DBCC CHECKDB, and ALTER INDEX REBUILD per database engine.
• Audit Trail: Full history of every query executed across the organization. The admin Audit tab exports loaded operations and query history as CSV or JSON, respecting the current filters.

Supported Databases

Twenty-six more engines have no driver of their own. The sixteen above are the drivers this build ships. Twenty-six further engines speak one of those wire protocols and connect through an existing driver unchanged, so sixteen drivers reach forty-two named engines in all. They are MariaDB, Percona Server for MySQL, TiDB, Vitess, StarRocks, Apache Doris, OceanBase, SingleStore, Databend, Citus, Percona Distribution for PostgreSQL, ParadeDB, OrioleDB, TimescaleDB, YugabyteDB, AlloyDB Omni, Apache Cloudberry (incubating), CockroachDB, Materialize and RisingWave (as PostgreSQL or MySQL), Valkey, DragonflyDB, KeyDB and Garnet (as Redis), FerretDB (as MongoDB), and ScyllaDB (as Cassandra). Each was measured against a live instance, and how much of the product works differs per engine. MariaDB, both Percona distributions, TiDB, Vitess, AlloyDB Omni, Citus, TimescaleDB, YugabyteDB, ParadeDB, OrioleDB, Valkey, DragonflyDB, KeyDB and FerretDB behave as their driver's own engine, though three of them report statistics you should not trust: a Citus distributed table and a TimescaleDB hypertable report row counts and sizes that are wrong rather than missing, and YugabyteDB reports 0 until you run ANALYZE. Vitess is not one of those three, its row counts and sizes being exact to the byte, but a running query cannot be cancelled there: vtgate refuses KILL QUERY and the statement runs to completion. AlloyDB Omni is not one of them either, reporting 2000 rows for 2000 and 270336 bytes for 270336, but two things there surprise: version() names AlloyDB nowhere, so the version panel cannot be told apart from a stock PostgreSQL 17, and eight of AlloyDB's own google_ml tables list in the object browser, which any role that can connect at all may also read. StarRocks reports itself as MySQL 5.1 and loses its overview, health and session panels, its monitoring dashboard rendering six panels with the session one carrying the engine's own refusal; Apache Doris - the engine StarRocks is a fork of - loses only the overview and health panels, to one statement form its grammar rejects, and is the more trustworthy of the two where it counts: it reports 2000 rows and 10187 bytes for a table holding exactly that, where StarRocks reads zero at first too - its own background statistics collector is slower, measured 4.5 minutes against 3.3.22 where Doris's is about a minute - and, until a 2026-09-16 fix, read zero forever afterward for sizes specifically, because StarRocks' INDEX_LENGTH is NULL rather than Doris's real 0 and poisoned the sum the provider computed in SQL; no index is ever reported, and a foreign key is accepted, listed by SHOW CONSTRAINTS, invisible to the ER diagram and unenforced; Cloudberry loses the monitoring dashboard and its table and index statistics, all three to one MPP planner restriction, and reads a foreign key back as though it were enforced when it is not, though its row counts are correct; CockroachDB loses the object browser and the size panels; OceanBase answers fourteen of the fifteen surfaces but only twelve of them usefully, health failing outright because its tenant has no performance_schema database at all and every size reading 0 B, though its row counts are correct once ANALYZE TABLE has run; SingleStore lost five surfaces to a cause that was ours rather than its own - the provider sent every statement through the prepared-statement protocol, which SingleStore refuses for the SHOW and EXPLAIN statements four panels need - and four of those five are now recovered, its Explain panel being the one that is not, because there the grammar wants EXPLAIN JSON and the statement fails on either protocol; its numbers are still missing rather than wrong, a 2000-row table reading 0 rows and 0 B with no ANALYZE able to change it; ScyllaDB loses five surfaces and Test Connection with them, all six to one absent keyspace - the overview, health, performance-metrics, active-session and monitoring panels read Cassandra's system_views virtual tables and ScyllaDB has no system_views keyspace at all - those five now degrade to empty rather than throwing, so Test Connection passes and the dialog saves the connection, which it could not do at all until that change - while the editor and the object browser work in full, every one of 18 CQL types reading back byte-identically to the Cassandra 5.0.9 probed in the same pass; ParadeDB and OrioleDB are both full and their costs are opposites: ParadeDB's nine extensions put 41 objects in the object browser for 2 user tables and break agent plan mode on a stock install, while OrioleDB's browser is clean and its own storage is invisible to PostgreSQL's size functions, so every index reads 0 bytes and the cache hit ratio reads N/A. Materialize, RisingWave and Databend are query-editor-only, and Databend is the one of those three whose catalogs answer perfectly well when asked directly - the object browser is empty because our parameterised reads use a prepared protocol it does not implement. Garnet behaves as Redis and is one of three relatives here (with Valkey and DragonflyDB) whose own version INFO carries beside the Redis compat level and the overview now labels ahead of it - Garnet 2.1.5 (Redis 7.4.3) - and two of its readings are absences wearing a value, every size showing 0 B because it publishes no used_memory and the cache hit ratio showing 100% because it publishes no keyspace counters. The per-engine detail, with the exact version probed, is in docs/providers/README.md — we publish a name only after connecting to it, so a name absent there is untested rather than unsupported.

Transport security is cross-cutting, not per engine. The SSH tunnel is opened before the provider connects and the connection is rewritten to the local endpoint, so it is provider-independent: it applies to any connection configured with a host and a port. A connection entered as a connection string instead (an option for MongoDB, Couchbase, ClickHouse and libSQL) carries neither, so it is not tunnelled; SQLite and DuckDB have neither either. The SSL/TLS panel is honoured by every engine that shows it — which is every engine except the three file-based ones, SQLite, DuckDB and the embedded LibreDB, where no transport exists to secure and no panel is offered. On Trino it is load-bearing rather than optional, because the coordinator refuses a password over plain HTTP. Oracle is the one engine whose mapping carries a caveat worth stating up front: its Thin driver always verifies the certificate chain, so require needs the server's CA supplied when that certificate is self-signed, and a connect string pasted whole keeps whatever protocol it names.

All SQL databases share: schema explorer, ER diagrams, schema diff & migration, display masking (preview), monitoring dashboard, and connection string import. Druid, Elasticsearch, OpenSearch and Trino are each the exception twice over: their HTTP SQL APIs have no URI convention this build can parse, so they are configured by host and port only, and a generated migration names the limitation instead of emitting column-modification DDL against an engine whose SQL contains none — as it also does for Couchbase's schemaless collections. An ER diagram over a search cluster draws boxes and no edges: an index declares no foreign keys and the engine's model has none to declare, which the provider states as declaresForeignKeys: false rather than leaving to be guessed from an empty list.

Provider reference docs: each database has an in-depth reference (design, connection, query format, monitoring, limitations) under docs/providers/. For the provider architecture see docs/DATABASE_PROVIDERS.md, and to add a new database see docs/ADDING_A_PROVIDER.md.

Tech Stack

Getting Started

docker run \
  --name libredb-studio \
  -p 3000:3000 \
  -e [email protected] \
  ghcr.io/libredb/libredb-studio:latest

# Debian / Ubuntu
sudo dpkg -i libredb-studio_<version>_amd64.deb

# RHEL / Fedora / Rocky
sudo rpm -i libredb-studio-<version>.x86_64.rpm

# Start the service (first run prints the generated admin password to the journal)
sudo systemctl enable --now libredb-studio
journalctl -u libredb-studio

```bash
git clone https://github.com/libredb/libredb-studio.git
cd libredb-studio
bun install
```

    2. **Configure Environment**
  Create a `.env.local` file:
  ```env
  # Authentication (email/password)
  [email protected]
  [email protected]
  JWT_SECRET=your_32_character_random_string

  # Optional: OIDC Single Sign-On (Auth0, Keycloak, Okta, Azure AD, etc.)
  # NEXT_PUBLIC_AUTH_PROVIDER=oidc
  # OIDC_ISSUER=https://your-provider.com
  # OIDC_CLIENT_ID=your_client_id
  # OIDC_CLIENT_SECRET=your_client_secret

  # LLM Configuration
  LLM_PROVIDER=gemini # options: gemini, openai, ollama, custom
  LLM_API_KEY=your_api_key
  LLM_MODEL=gemini-2.5-flash
  LLM_API_URL=http://localhost:11434/v1 # optional for local LLMs (Ollama)
  ```

1. Launch

```bash
bun dev
```
Open [http://localhost:3000](http://localhost:3000)

async headers() {
  return [
    {
      source: "/:path*",
      headers: Object.entries(securityHeaders()).map(([key, value]) => ({ key, value })),
    },
  ];
},

Development Databases

# Start every default-profile database (PostgreSQL, MySQL, MongoDB, SQL Server, Oracle, ...)
docker compose -f database-compose.yml up -d

# Or start a specific database
docker compose -f database-compose.yml up -d postgres
docker compose -f database-compose.yml up -d mssql
docker compose -f database-compose.yml up -d oracle

# Apache Druid: profile-gated, so a bare `up -d` does NOT start it. Druid is a distributed
# system with no single-container mode - five Druid processes plus ZooKeeper plus its own
# metadata database is the minimum that can answer a SQL query, so all seven services carry
# `profiles: [druid]` rather than doubling the default stack. Connect to the Router on 8888
# (or the Broker on 8082 - the same endpoint, no different configuration).
docker compose -f database-compose.yml --profile druid up -d

# Start PostgreSQL with sample e-commerce data
docker compose -f docker/postgres.yml up -d

# Stop (keeps data)
docker compose -f database-compose.yml down

# Stop and remove all data
docker compose -f database-compose.yml down -v

# The Druid containers need the profile flag here too - without it `down` leaves them running
docker compose -f database-compose.yml --profile druid down -v

Connection Details

PostgreSQL Sample Data

This setup is ideal for testing the Monitoring Dashboard features with real pg_stat_statements data.

Testing

Quick Commands

# Every test file, each in its own bun process
bun run test

# Run by layer
bun run test:unit          # Pure function tests (328 files)
bun run test:api           # API route handler tests (35 files)
bun run test:integration   # Database provider tests (24 files)
bun run test:hooks         # React hook tests (21 files)
bun run test:security      # Security posture tests (21 files)
bun run test:evals         # LLM prompt evaluation tests (13 files)
bun run test:components    # Component tests (107 files: tests/components and tests/isolated)

# Any subset, and what the runner would run
bun tests/run-tests.ts tests/integration/db/duckdb-provider.test.ts
bun tests/run-tests.ts --list
bun tests/run-tests.ts --jobs=4          # bound the concurrency

# E2E tests (requires build)
bun run test:e2e           # Playwright browser tests (79 cases across chromium and webkit)

# Coverage report (lcov)
bun run test:coverage

Test Architecture

Key Details

• Test runner: tests/run-tests.ts over bun:test. It discovers every *.test.ts and *.test.tsx file under tests/ except tests/live/, so a new test file runs the moment it is added, and it runs each file in its own bun process, several at a time (one per CPU by default, --jobs=N to change it).
• Why a process per file: bun's mock.module() is process-wide with no undo, and whole-module mocks are the standard pattern in tests/api/, so files that share a process contaminate each other. On Linux with 20 cores and bun 1.4.2, the suite took 211 seconds one file at a time, 61 seconds 4 at a time and 36 seconds 20 at a time, measured on 2026-09-15 over the 538 files the tree held then; docs/BACKLOG.md D86 carries the same three timings and the same basis.
• One command everywhere: the runner is TypeScript rather than shell so that the command a contributor is told to run works on Linux, macOS and Windows from the platform's own shell. The bash scripts it replaced did not: one used mapfile, a bash 4 builtin that macOS's bash 3.2 does not have.
• E2E: Playwright runs the full suite on Chromium and the security-headers spec on WebKit (webkit-security), against a production build (bun run build && bun start)
• CI: GitHub Actions runs lint + typecheck + build, the required Unit & Integration Tests job (bun run test:coverage then bun run coverage:check) on ubuntu, a non-required Cross-platform Tests job running bun run test on windows-latest and macos-latest, E2E tests, and SonarCloud analysis
• Coverage: bun run test:coverage is the same runner with --coverage, which writes one lcov per test file; scripts/merge-lcov.mjs merges them into coverage/lcov.info for the gate and for SonarCloud

Important: Always use bun run test, never bare bun test over a directory. bun test tests/api puts every file in one process, where one file's module mock becomes every file's. To run a single file, name it to the runner: bun tests/run-tests.ts tests/api/proxy.test.ts.

One-Click Deploy

DigitalOcean: the Marketplace listing creates a preconfigured Droplet. Unique admin credentials are generated on first boot; the welcome message (MOTD) tells you where to find them.
CapRover: open your CapRover dashboard → Apps → One-Click Apps/Databases, search for LibreDB Studio, and deploy.
Koyeb: set a strong JWT_SECRET (at least 32 characters — openssl rand -base64 32) and credentials before deploying (Koyeb cannot auto-generate secrets). The prefilled values are deliberately unusable: the secret is shorter than the 32-character minimum, so the app stops at boot and says so rather than running on a secret printed in this file. The button uses STORAGE_PROVIDER=local — connection metadata lives in the browser, which suits Koyeb's ephemeral filesystem. For persistence across redeploys, switch to STORAGE_PROVIDER=postgres and point STORAGE_POSTGRES_URL at a Koyeb managed Postgres or Neon database. The button also fills in LLM_PROVIDER/LLM_MODEL/LLM_API_KEY, but Agent mode needs a server-held connection, so its Start button stays disabled until STORAGE_PROVIDER is sqlite or postgres (see docs/AGENT.md). See deploy/koyeb/.
Fly.io: the repo ships a ready fly.toml — full steps (app name, volume, secrets) in docs/FLY.md.
Cosmos: install in one click from the Cosmos Marketplace — search for LibreDB Studio. Cosmos auto-generates secrets, provisions a persistent SQLite volume, and serves the app behind its SmartShield reverse proxy. See deploy/cosmos/.
Dokploy: install in one click from the Dokploy template catalog — in your Dokploy dashboard, Create Service → Template, search for LibreDB Studio, and deploy. Dokploy auto-generates ADMIN_PASSWORD, USER_PASSWORD, and JWT_SECRET, and persists connections on a SQLite volume behind Traefik. See deploy/dokploy/.

Environment Variables

Tip: Copy .env.example to .env.local for local development.

Deployment (DevOps)

Maintainers: every distribution channel is inventoried in distribution/channels.yaml; bun run distribution:check reports version drift across all of them (see docs/DISTRIBUTION.md).

Koyeb

1. Use the Deploy to Koyeb button under One-Click Deploy to run the prebuilt ghcr.io/libredb/libredb-studio:latest image.
2. Set a strong JWT_SECRET (32+ characters) in the deploy form before launching. Koyeb cannot auto-generate secrets, and the prefilled one is shorter than the 32-character minimum on purpose, so a deployment left as it stands stops at boot and says why. No password is prefilled: leave ADMIN_PASSWORD unset and the app generates one on first run and prints it to the Koyeb runtime log, or set your own. USER_PASSWORD is not generated — without it the lower-privilege account does not exist at all, which is the safer default for a public URL.
3. For connections to survive redeploys, set STORAGE_PROVIDER=postgres and STORAGE_POSTGRES_URL to a Koyeb managed Postgres or Neon connection string. The button defaults to STORAGE_PROVIDER=local, which keeps connection metadata in the browser.

Railway

CapRover

1. Open your CapRover dashboard → Apps → One-Click Apps/Databases
2. Search for LibreDB Studio
3. Fill in the variables (admin/user credentials, JWT_SECRET, optional AI/storage settings)
4. Deploy!

Kubero

Cosmos

Render (Recommended for cloud deployment)

1. Fork this repository
2. Connect to Render: dashboard.render.com → New → Blueprint
3. Select your forked repo and Render will auto-detect render.yaml
4. Set Environment Variables in Render Dashboard:
5. Deploy!

Docker Compose (Self-Hosted)

# 1. Copy the ready-to-use compose file
cp docker-compose.example.yml docker-compose.yml

# 2. Create your .env (set at least JWT_SECRET / ADMIN_PASSWORD / USER_PASSWORD)
cp .env.example .env

# 3. Start
docker compose up -d   # → http://localhost:3000

The repository's default docker-compose.yml builds the image from source (build: .) and is intended for local development.

Kubernetes (Helm Chart)

helm repo add libredb https://libredb.org/libredb-studio/
helm install libredb libredb/libredb-studio

# Retrieve the generated admin credentials from the pod log
kubectl logs deployment/libredb-libredb-studio | grep -A 4 "generated admin credentials"

helm install libredb oci://ghcr.io/libredb/charts/libredb-studio

helm install libredb libredb/libredb-studio \
  --set secrets.jwtSecret=$(openssl rand -base64 32) \
  --set secrets.adminPassword=MyAdmin123

Seed Connections (Pre-Configured Databases)

• Role-based access control (admin, user, * wildcard)
• Hybrid model: managed: true (read-only, admin-controlled) or managed: false (editable copy for user)
• Credentials injected via ${ENV_VAR} syntax — never stored in config file
• Hot-reload: config changes apply within 60s without restart
• Works with Docker, docker-compose, and Kubernetes (Helm)

version: "1"

defaults:
  managed: true
  environment: production

connections:
  - id: "prod-analytics"
    name: "Production Analytics"
    type: postgres
    host: analytics-db.internal
    port: 5432
    database: analytics
    user: "readonly_user"
    password: "${ANALYTICS_DB_PASSWORD}"
    roles: ["admin"]
    color: "#10B981"

  - id: "dev-sandbox"
    name: "Dev Sandbox"
    type: mysql
    host: dev-mysql.internal
    port: 3306
    database: sandbox
    user: "dev_user"
    password: "${DEV_DB_PASSWORD}"
    roles: ["*"]
    managed: false

docker run -v ./seed-connections.yaml:/app/config/seed-connections.yaml:ro \
  -e SEED_CONFIG_PATH=/app/config/seed-connections.yaml \
  -e ANALYTICS_DB_PASSWORD=secret \
  -e DEV_DB_PASSWORD=devsecret \
  ghcr.io/libredb/libredb-studio:latest

services:
  app:
    image: ghcr.io/libredb/libredb-studio:latest
    volumes:
      - ./seed-connections.yaml:/app/config/seed-connections.yaml:ro
    environment:
      SEED_CONFIG_PATH: /app/config/seed-connections.yaml
      ANALYTICS_DB_PASSWORD: ${ANALYTICS_DB_PASSWORD}
      DEV_DB_PASSWORD: ${DEV_DB_PASSWORD}

# values.yaml
seedConnections:
  enabled: true
  config:
    version: "1"
    connections:
      - id: "prod-analytics"
        name: "Production Analytics"
        type: postgres
        host: analytics-db.internal
        password: "${ANALYTICS_DB_PASSWORD}"
        roles: ["admin"]

# Credentials via K8s Secret:
extraEnvFrom:
  - secretRef:
      name: seed-db-credentials

One-Command Vault Demo

docker compose -f docker-compose.vault-demo.yml up

The Vault in that file is dev mode — in-memory, root token, no TLS, no policies — so it's for demonstration only. The reference scheme, the VAULT_* variables, the rotation window and both rotation commands are in docs/SEED_CONNECTIONS.md; a real deployment starts from HashiCorp's production hardening guide.

Roadmap

• x Phase 1: Monaco SQL IDE & Multi-Tab Support.
• x Phase 2: Multi-Model AI (Gemini, OpenAI, Ollama, Custom) Integration.
• x Phase 3: Pro Data Grid & Virtualization.
• x Phase 4: Multi-Database Support (PostgreSQL, MySQL, SQLite, MongoDB, Redis).
• x Phase 5: Interactive ER Diagrams (Visual Schema Graph).
• x Phase 6: Enterprise Foundation (Connection Testing, SSL/TLS, SSH Tunnel, Transaction Control, Query Cancellation).
• x Phase 7: AI Intelligence (Query Safety Analysis, AI Query Explainer, AI-generated schema descriptions).
• x Phase 8: Analyst & Developer Tools (Data Profiler, Code Generator, Test Data Generator, Pivot Table, Column Filtering, Database Docs).
• x Phase 9: Display Masking — Preview (column-name pattern matching, configurable rules, RBAC UI controls, client-side export/clipboard masking).
• x Phase 10: Advanced ERD (Real FK Edges, ELK.js Auto-Layout, MiniMap, PNG/SVG Export, Compact Mode, Table Search).
• x Phase 11: Schema Diff & Migration (Snapshot Timeline, Cross-Connection Diff, Migration SQL Generation for PostgreSQL, MySQL, SQLite, Oracle, and SQL Server, plus ClickHouse column modifications).
• x Phase 12: Advanced Charting (Scatter, Histogram, Stacked Charts, Aggregation, Date Grouping, Chart Save/Load, Chart Dashboard).
• x Phase 13: Monitoring Enhancement (Time-Series Trends, Threshold Alerting, Connection Pool Stats, Configurable Polling).
• x Phase 14: Enterprise Database Support (Oracle Database via oracledb Thin mode, Microsoft SQL Server via mssql/tedious).
• x Phase 15: SSO Integration — Vendor-agnostic OIDC authentication (Auth0, Keycloak, Okta, Azure AD, Zitadel) with PKCE, role mapping, and provider logout.
• Phase 16: DBA & Monitoring (Lock Dependency Graph, Vacuum Scheduler, Prometheus Export).
• Phase 17: Enterprise Collaboration (User Identity, Shared Workspaces, SAML 2.0).
• Phase 18: Server-Enforced Data Masking (SQL output-lineage, deployment-global policy, fail-closed API masking, alias/aggregate coverage).
• x Phase 19: Driver-Free Providers — Couchbase (SQL++ over the Query REST API), the first provider that adds no runtime dependency. Pattern documented in Adding a Provider.
• x Phase 20: Analytics Databases — ClickHouse (#264) and Apache Druid (#265), both driver-free over HTTP. Druid is read-only by nature — no UPDATE, no DELETE, no CREATE TABLE — so it also demonstrates a provider that reports absent capabilities honestly instead of offering controls that can only fail.
• x Phase 21: Federated Query — Apache Trino (#424, Phase 2), driver-free over Trino's own client protocol. The product question that held it up is answered: a connection pins one catalog, exactly as a PostgreSQL connection pins one database, and the tree stays two levels — fanning information_schema across every catalog is unbounded, since jmx.current alone publishes one table per MBean. Cross-catalog queries still work in the editor by qualifying names in full. PrestoDB is a separate future type-id; the transport already builds its headers from a dialect prefix so that is a descriptor, not a rewrite.

Community & Quality

Cross-browser testing

Support

Sponsors

Supporters

• Docker — the

• BrowserStack — the BrowserStack

• Tailscale — the Community on GitHub

Contributing

1. Fork the Project.
2. Create your Feature Branch (git checkout -b feature/AmazingFeature).
3. Commit your Changes (git commit -m 'Add some AmazingFeature').
4. Push to the Branch (git push origin feature/AmazingFeature).
5. Open a Pull Request.

License

Built for DBAs and Developers.