Turn a SQLite file into a local database your whole stack can reach

dbplex is a Mac app that serves a SQLite .db or .sqlite file from a local libSQL server, with a localhost URL, a table browser, a SQL editor and a schema graph. Your app, your tests and your AI agent all reach the same copy.

Download for Mac Try it in your browser

For Apple Silicon Macs. 7 days free with every feature. No card and no account.

Runs on: The libSQL server, sqld
Download: About 9 MB
Needs: A .db or .sqlite file, no Docker
Source: A file, copied in

What comes with a SQLite copy

Copied to your Mac

Tables and rowsEverything in the file.
The schemaTables, indexes, views and triggers, drawn as a graph.

Left behind, and why

MaskingA file import has no masking, so the copy holds what the file holds.
A production to refresh fromA file has none, so there is no Refresh and no comparison with production.

After each pull the Connect tab lists what was left out.

What you paste

Nothing to paste. Drop the file.

FileRequired

app.dbDrop a SQLite file, or click to choose one. .db and .sqlite both work.

Read only. Nothing is ever written to production.

Or start from an empty database.

Then point your app at the copy

http://localhost:15000

The port is the first free one from 15000, so yours may differ. The Connect tab shows the exact values.

Why not open the file directly?

A file is fine for one program. A server is easier to share with your app, your tests and your agent.

	The file in a SQLite tool	dbplex
Access	Each program opens the file path.	Everything reaches one localhost URL.
Going back	Copy the file before each experiment.	Save a state and restore it.
Trying two things at once	Copy the file again.	Branch the copy.
AI agents	Hand the agent a file path.	MCP tools to query, save, restore and branch it.

What you can do with a SQLite copy

Browse tables and run SQLIn the app or with any libSQL client.
See the schema graphEvery table and the keys between them, drawn from the copy.
Save and restore statesSave before a risky change and go back to it.
Branch the copyWork on a second copy, from now or from the last pull, and keep the first as it is.
Back up the copyDaily or weekly, to a folder you choose. Each backup opens as a new copy.
Read the logsThe server log of the copy, in the Logs tab.

There is no comparison with production or migration script for a file, and no masking: a file import copies what the file holds.

A SQLite sandbox for your AI agent

Give Claude Code, Cursor, Codex or Windsurf a copy of production to test on, and let it break things. dbplex's built-in MCP server hands the agent your local SQLite copy, never production: it never sees your production credentials, and every tool it gets acts on local copies only.

Add it from the app's Settings. A SQLite database has no jobs or webhooks, so the copy does nothing until something calls it.

Run SQL on the copyReads, writes and schema changes, never on your original file.
Save a state before it tries somethingAnd restore it when the attempt goes wrong.
A branch for each agentEach agent clones the copy and works alone. A clone holds no credentials and can never reach production. It can get the script of the schema changes it made there.
Read the logsThe newest lines of the server log.

When agents had production instead

Questions about SQLite in dbplex

Does dbplex change my SQLite file?

No. The file is copied in, and the copy is what the server serves and what you change.

Why serve a SQLite file at all?

So your app, your tests and your agent can all reach the same copy over one localhost URL, and you can save states and branch it.

Which files work?

SQLite files ending in .db or .sqlite.

Can I go back after a bad change?

Yes. Save a state before you try something, and restore it after.

Do I need Docker for SQLite?

No. The libSQL server is a 9 MB download that dbplex runs itself.

Can my AI agent use the SQLite copy?

Yes. Add dbplex's MCP server to Claude Code, Cursor, Codex or Windsurf from the app's Settings. It can run SQL, save and restore states, branch its own copy and get the script of the schema changes it made on that branch. Every tool acts on local copies only, and the agent never sees your production credentials.