-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Description
When setting up Forus locally using Docker Desktop, dependency installation for both backend (Composer) and frontend (npm) can cause containers to stall and Docker Desktop to become unresponsive.
In some cases, containers cannot be restarted and Docker Desktop must be restarted entirely to recover. This makes local setup unreliable, especially for new developers or clean environments.
Environment
- Docker Desktop: on Ubuntu 25.10 (likely affects Windows and macOS as well)
- Main repository:
teamforus/Forus- release v163 (commit3f61218, 4 days ago) - Backend:
teamforus/forus-backend- release v163 (commitd2dae97, 4 days ago) - Frontend:
teamforus/forus-frontend-react- release v163 (commit7fad5d6, 4 days ago) - Setup: Following
readme-docker.mdin each repository
Steps to reproduce
Backend
- Clone
teamforus/forus-backend - Follow
readme-docker.md - Use Docker Compose with the project directory bind-mounted (current default)
- Run
composer installinside the container
Frontend
- Clone
teamforus/forus-frontend-react - Follow
readme-docker.md - Remove
node_modules - Run
npm installinside the container
Observed behavior
- Dependency installation stalls while creating thousands of files
- Docker Containers become unresponsive and can be reset or removed by using commands.
docker compose down/docker compose updoes not recover the environment
- Docker Desktop restart is required
Expected behavior
- Dependency installation completes reliably
- Containers remain responsive
- Local setup completes without requiring Docker Desktop restart
Analysis
Composer and npm create large dependency trees with thousands of small files. On Docker Desktop, writing these files through bind mounts can overwhelm the filesystem sync and event pipeline, leading to stalls or deadlocks. This appears to be a Docker Desktop limitation when using bind-mounted dependency directories.
Proposed direction (requesting feedback)
Docker recommends using named volumes for data generated and managed by containers,
rather than bind mounts, especially for performance and reliability reasons.
See: https://docs.docker.com/engine/storage/volumes/
It seems a possible mitigation is to store dependency directories in Docker named volumes instead of bind mounts:
- Backend: mount
vendor/as a named volume - Frontend: mount
node_modules/as a named volume
This keeps source code bind-mounted while avoiding filesystem sync issues for dependencies.
Before making changes to both repositories, feedback is requested on:
- Is this a suitable solution?
- Whether this approach should be adopted as the default Docker Desktop setup
- Whether alternative approaches are preferred