Files
foodster/.env.example
T
Esa Kataja c6f44bb427 Keep the database in ./data and bind-mount it
SQLite writes three files — the database plus its -wal and -shm companions.
Putting them in one directory means a deployment mounts a single path and a
backup copies a single directory.

- FOODSTER_DB defaults to ./data/foodster.db, and openDB creates the parent
  directory on startup rather than failing on a fresh checkout
- compose bind-mounts ./data instead of using a named volume, so the file can
  be listed, copied and opened with any sqlite client without going through
  the container engine
- the image runs as UID 65534, which cannot write to a host directory owned
  by someone else, so compose now sets user: from FOODSTER_UID/FOODSTER_GID
- `make up` creates ./data first: left to the engine it appears root-owned
  and the app silently cannot write to it
2026-09-05 18:17:14 +03:00

24 lines
794 B
Bash

# Copy to .env and fill in. .env is gitignored — the real registry hostname
# must not end up in the repository.
# Image coordinates. FOODSTER_REPO carries no tag.
FOODSTER_REPO=registry.example.com/you/foodster
FOODSTER_TAG=latest
# Shared household password. The app will not start without it.
FOODSTER_PASSWORD=changeme
# Host port to publish on.
FOODSTER_PORT=8080
# The database lives in ./data, bind-mounted into the container. These must
# match whoever owns that directory on the host, or the container cannot
# write to it. `id -u` and `id -g` will tell you.
FOODSTER_UID=1000
FOODSTER_GID=1000
# Used for every calendar-day calculation. Set it in development too: under
# UTC the date rolls over three hours late, which is exactly when dinner
# gets logged.
TZ=Europe/Helsinki