Run the container as the host uid that owns the ./data bind mount

The image's own petal user (uid 10001) has no claim on a bind-mounted
host directory, so SQLite came up with "unable to open database file
(14)" and the container restart-looped. Run as the stack directory's
owner instead of chowning ./data to 10001 -- the backup script gzips
snapshots in place from the host, so that account needs write access to
the same directory. Still non-root.

deploy/petal.env.example

@@ -14,6 +14,12 @@ BASE_URL=https://petal.parodia.dev
 # The companion's bedtime nag and the night theme read the container clock.
 TZ=Europe/Lisbon
 
+# The container runs as this uid/gid so it can write the ./data bind mount.
+# Set both to the output of `id -u` / `id -g` for the account owning the stack
+# directory. Wrong values show up as "unable to open database file (14)".
+PETAL_UID=1001
+PETAL_GID=1001
+
 # --- LLM (millenia, over headscale) ------------------------------------------
 # The only cross-VPN dependency. Petal degrades warmly when it's unreachable:
 # spell check, gloss, garden, search, export and read-aloud all keep working and

docker-compose.yml

@@ -24,6 +24,13 @@ services:
     image: petal:local
     container_name: petal
     restart: unless-stopped
+    # ./data is a bind mount, so the image's own `petal` user (uid 10001) has no
+    # claim on it — the host's ownership wins and the container can't open
+    # petal.db. Run as whoever owns the stack directory instead. Keeping it the
+    # host user (rather than chowning ./data to 10001) is deliberate: the backup
+    # script gzips snapshots in place from the host, so the host account needs
+    # write access to the same directory. Still never root.
+    user: "${PETAL_UID:-1001}:${PETAL_GID:-1001}"
     env_file: .env
     environment:
       # Fixed by the image layout; kept here so they're visible at a glance.