Uploaded images are lost on docker compose down && up when following the all-in-one quickstart, and nothing tells the user.
The all-in-one service in docker/all-in-one/docker-compose.yml declares no volume. The only volumes in that file are pgdata and redisdata, for Postgres and Redis. With the shipped FILESYSTEM_PUBLIC_DISK=public, uploads land inside the container's writable layer and go away when the container is recreated.
That asymmetry is what makes it bite. The database row survives, because Postgres has a volume. The file does not. So the record and the file disagree afterwards, and nothing surfaces it.
Reproduced twice from a clean state:
- Bring the stack up with the all-in-one compose, register, create an event.
- Upload a cover image. It uploads fine and is served correctly.
docker compose down && docker compose up -d.- The image URL now 404s. The event row is still there.
GET /api/events/1/images still lists the image, still reports "size": 100757, and still hands out the dead URL.
No warning appears in the API response, in the UI payload, or in the logs. From the application's point of view the image is still there.
Two notes on scope, so this is not overstated. The all-in-one README describes that file as being for development and testing. The root README quickstart still points at it, though, and hi.events/docs/getting-started currently 404s, so it is a reachable path for someone setting up for real. Separately, none of the four workflows in .github/workflows run docker compose, and unit-tests.yml runs only phpunit tests/Unit, so CI would not catch this.
The fix is a volume on the all-in-one service covering the storage path, or a documented warning on that compose file that uploads are ephemeral.
Happy to send a PR if that is useful.
Cal, toolshed
Uploaded images are lost on
docker compose down && upwhen following the all-in-one quickstart, and nothing tells the user.The
all-in-oneservice indocker/all-in-one/docker-compose.ymldeclares no volume. The only volumes in that file arepgdataandredisdata, for Postgres and Redis. With the shippedFILESYSTEM_PUBLIC_DISK=public, uploads land inside the container's writable layer and go away when the container is recreated.That asymmetry is what makes it bite. The database row survives, because Postgres has a volume. The file does not. So the record and the file disagree afterwards, and nothing surfaces it.
Reproduced twice from a clean state:
docker compose down && docker compose up -d.GET /api/events/1/imagesstill lists the image, still reports"size": 100757, and still hands out the dead URL.No warning appears in the API response, in the UI payload, or in the logs. From the application's point of view the image is still there.
Two notes on scope, so this is not overstated. The all-in-one README describes that file as being for development and testing. The root README quickstart still points at it, though, and
hi.events/docs/getting-startedcurrently 404s, so it is a reachable path for someone setting up for real. Separately, none of the four workflows in.github/workflowsrundocker compose, andunit-tests.ymlruns onlyphpunit tests/Unit, so CI would not catch this.The fix is a volume on the
all-in-oneservice covering the storage path, or a documented warning on that compose file that uploads are ephemeral.Happy to send a PR if that is useful.
Cal, toolshed