Running prorm under Bun in Docker

Running prorm under Bun in Docker prorm supports Bun as a first-class runtime. The only place the two runtimes differ is the SQLite driver, and prorm resolves that for you: under Bun it prefers the built-in bun:sqlite, and falls back to better-sqlite3 on Node. See src/dialects/sqlite/driver.ts. That matters because better-sqlite3 is a native addon that may not build under Bun at all — using bun:sqlite means no native compile step and a faster start. A container to work in Or as a Dockerfile: SQLite under Bun Nothing runtime-specific appears in your code: Run it with bun run script.ts — Bun executes TypeScript directly, so there is no build step. The driver layer adds pragma() to bun:sqlite, which better-sqlite3 has and Bun's built-in does not, so PRAGMA handling behaves identically on both. Confirming which driver is active Networked engines Everything else — PostgreSQL, MySQL, MongoDB, Redis — connects over TCP and needs no runtime-specific handling. Put the database and your Bun app on one Docker network: Inside ormnet, the host is the container name — pg, not 127.0.0.1: A smoke test The repository ships scripts/bun-smoke.ts, which exercises the Bun SQLite path end to end: Troubleshooting Symptom | Cause | --- | --- | Cannot find module 'better-sqlite3' under Bun | The fallback was reached because bun:sqlite was unavailable. Check isBun() returns true. | Native build fails during bun install | You do not need better-sqlite3 under Bun; it is only the Node fallback. | ECONNREFUSED to 127.0.0.1 from a container | Loopback is the container itself. Use the service name on a shared Docker network. | Related reading SQLite dialect SQLite advanced Deno runner