drawDB

Last reviewed Aug 26, 2026 · 862 words

drawDB is a React bundle behind nginx. There is no database, no login, no API server, and nothing on the box does any work after the page loads; the entire ER-diagram editor, the SQL generator, and your diagrams run inside the browser tab. That makes it the lightest thing in the office category by a wide margin and the easiest self-host I have done this year. It also means the honest question is not "how do I run it" but "why run it at all, when drawdb.app is the same client-side code for free". The answers are offline use, a version you control, and never pasting a production schema into someone else's domain.

The whole install is a build and a port

The project ships a Dockerfile rather than a published image, so you build once:

git clone https://github.com/drawdb-io/drawdb
cd drawdb
docker build -t drawdb .
docker run -d --name drawdb --restart unless-stopped -p 3000:80 drawdb

The container is nginx serving compiled static files on port 80; the catalogue's 128 MB floor is generous, and on my box the container idles at under 10 MB. Put it behind Caddy with a hostname and you are finished. There is nothing to back up on the server because the server holds nothing. Updating means git pull, rebuild, restart, and because the app is self-contained, an old build keeps working forever if you never want to update at all.

Your diagrams live in the browser, not on the server

This is the property that bites. Diagrams autosave to the browser's IndexedDB, keyed to the origin you loaded the page from. Open your self-hosted drawDB from a different machine, a different browser profile, or a private window, and the list is empty. Clear site data and the diagrams are gone. The tool is explicit about this and gives you the way out: export the diagram as a .ddb JSON file, commit it next to your migrations, and re-import when needed. I treat the browser copy as a working buffer and the JSON in git as the record, the same way you would treat an unsaved editor tab. The share feature on the public site relies on a small companion server and a GitHub token; on a private self-host, sharing is "send the JSON file", which is fine.

SQL export is the feature, and it is broad

Draw tables, set types and constraints, drag relationships between keys, and export DDL for MySQL, PostgreSQL, SQLite, MariaDB, SQL Server, and Oracle from the same diagram. The generated scripts are plain and readable, with foreign keys, indexes, and comments where you added them, so they are safe to paste into a migration file and edit. Import works in the other direction, from SQL scripts and from DBML, which is how you get an existing schema onto the canvas in a minute. Review imported diagrams for anything dialect-specific; the parser is good on standard DDL and less certain on vendor extensions. There is also a relational-to-diagram view that lays tables out automatically, which saves 20 minutes on a 40-table schema.

No live sync makes it a design tool, not documentation

drawDB never connects to a database. It cannot introspect your running Postgres, will not notice a column you added in a hotfix, and has no notion of a diagram drifting from reality. For designing a schema before it exists, or sketching a change before you write the migration, that is exactly right and it keeps the tool tiny. For "the current ER diagram of production", you want something that reads the catalog, and the Postgres for everything approach of one database with pg_dump --schema-only in git gets you closer than any drawing tool. Use drawDB to think, not to record.

The AGPL clause only matters if you fork it

The catalogue lists AGPL-3.0 as a con, and for a self-hoster it is not one. AGPL's network clause obliges you to offer source to users of a modified version you run as a service. Running unmodified drawDB for your own team triggers nothing; even running it modified for a private team is, in practice, a matter of pointing colleagues at your fork. The licence bites only when a company embeds a changed drawDB in a product it sells and does not want to publish the changes. If that is your situation, see the broader discussion in open source licences for self-hosters; if it is not, stop worrying.

What I'd do

Build the image, run it on 3000 behind Caddy at db.internal.example.com, and add one habit: export the .ddb file into the repository beside the migrations every time a schema changes, with the same commit. Use it for every new table before writing DDL, and never pretend it reflects what is running. For general whiteboarding rather than schemas, Excalidraw is the neighbour to install alongside it; the two together cover most of what a paid diagramming subscription did.