Running prorm under Deno in Docker

Running prorm under Deno in Docker Deno runs prorm through its npm compatibility layer. Unlike Bun there is no built-in SQLite that prorm targets, so SQLite goes through better-sqlite3 — a native addon, which needs Deno's Node compatibility and FFI permissions. Networked engines (PostgreSQL, MySQL, MongoDB, Redis) are the smoother path. A container to work in As a Dockerfile: Importing prorm Permissions Deno denies everything by default, and the failure modes look like unrelated bugs, so grant explicitly: Flag | Needed for | --- | --- | --allow-net | every networked engine | --allow-env | reading connection settings from the environment | --allow-read / --allow-write | SQLite file storage | --allow-ffi | better-sqlite3's native addon | --node-modules-dir | npm packages with native or CommonJS internals | Talking to a database container The host is the container name (pg), not 127.0.0.1 — loopback inside a container refers to that container. SQLite under Deno Workable, but the least comfortable combination: better-sqlite3 must compile and load through Deno's Node compatibility layer, which needs node-modules-dir, --allow-ffi, and a toolchain in the image. If you want SQLite specifically, Bun is the better runtime — prorm uses its built-in bun:sqlite and skips the native build entirely. Troubleshooting Symptom | Cause | --- | --- | PermissionDenied: Requires net access | Add --allow-net. | Module not found "npm:ts-prorm-orm" | Add --node-modules-dir, or deno cache first. | better-sqlite3 fails to load | Needs --allow-ffi and a build toolchain — prefer Bun for SQLite. | ECONNREFUSED 127.0.0.1 | Use the container name on a shared network. | Related reading Bun runner PostgreSQL in Docker