RexSystem1 voteoriginally by @mgabor3141 on GitHub OP
9: S3 data_dir resolves relative to fluxer_server/, not the project root — uploads silently written to ephemeral container layer
Symptom: All avatars, banners, and attachments return 404 after a container rebuild. The S3 bucket directories exist on the persistent volume but are empty.
Root cause: The S3 service's data_dir defaults to ./data/s3 (a relative path). Since the entrypoint is pnpm --filter fluxer_server start, pnpm sets the cwd to /usr/src/app/fluxer_server/. This means ./data/s3 resolves to /usr/src/app/fluxer_server/data/s3/ — inside the container's writable layer — instead of /usr/src/app/data/s3/ on the bind mount.
Uploads succeed and the app works fine, but the files are silently written to the ephemeral container filesystem. They survive restarts but are permanently lost on container rebuild (docker compose up --build, image update, etc.).
This is the same class of bug as the sqlite_path issue — the Dockerfile's ENTRYPOINT uses pnpm --filter, which changes the working directory, breaking all relative path defaults.
Fix: Set an absolute path for services.s3.data_dir in config.json:
Note: The only other relative-path default in the schema is services.queue.data_dir (./data/queue), but it appears unused in the self-hosted setup since the queue is backed by NATS JetStream.
Thread
Comment by @mgabor3141
9: S3
Symptom: All avatars, banners, and attachments return 404 after a container rebuild. The S3 bucket directories exist on the persistent volume but are empty. Root cause: The S3 service'sdata_dirresolves relative tofluxer_server/, not the project root — uploads silently written to ephemeral container layerdata_dirdefaults to./data/s3(a relative path). Since the entrypoint ispnpm --filter fluxer_server start, pnpm sets the cwd to/usr/src/app/fluxer_server/. This means./data/s3resolves to/usr/src/app/fluxer_server/data/s3/— inside the container's writable layer — instead of/usr/src/app/data/s3/on the bind mount. Uploads succeed and the app works fine, but the files are silently written to the ephemeral container filesystem. They survive restarts but are permanently lost on container rebuild (docker compose up --build, image update, etc.). This is the same class of bug as thesqlite_pathissue — the Dockerfile's ENTRYPOINT usespnpm --filter, which changes the working directory, breaking all relative path defaults. Fix: Set an absolute path forservices.s3.data_dirinconfig.json:services.queue.data_dir(./data/queue), but it appears unused in the self-hosted setup since the queue is backed by NATS JetStream.