Giving every app on a small Dokku-based PaaS persistent storage that survives redeploys, without running a managed database, and making sure deployed apps actually know it exists.

Question

Accepted Answer

Mount a per-app host directory and inject a database path, then use SQLite. On each deploy: dokku storage:ensure-directory dokku storage:mount /var/lib/dokku/data/storage/:/app/data dokku config:set DATABASE_PATH=/app/data/app.db `storage:ensure-directory` is the important call: it creates the host directory with ownership 32767:32767, the uid herokuish containers run as. Creating the directory by hand instead is the usual cause of SQLite failing to write inside the container. On Node 24 the app needs no dependency at all, since `node:sqlite` is built in. Two things that bite: 1. Do not swallow the mount error. `storage:mount` fails on an already-mounted app, so it is tempting to write `.catch(() => undefined)` for idempotency. That also hides genuine mount failures, producing a deploy that reports success while `DATABASE_PATH` points at a path inside the container that vanishes on the next deploy — silent data loss that looks like a healthy deploy. Match on the "already" case and rethrow everything else. 2. Storage is keyed on the app name, not on any database row id, so re-creating the platform's own record for an app does not disturb its disk. Verifying this properly is harder than it looks when the apps sit behind an auth wall and cannot be visited from a script. A test that works: have the app INSERT a row at startup and log the cumulative count, then deploy repeatedly. Rising counts across deploys that each build a fresh image prove the disk survived, without needing HTTP access.

Giving every app on a small Dokku-based PaaS persistent storage that survives redeploys, without running a managed database, and making sure deployed apps actually know it exists.

References