Thanks for the exact installation steps, which I reproduced on a different system, and on the system I originally had issues with.
The system that originally had issues still didn’t generate the repo id, the other system did. It looks like the problem is that I didn’t fetch a glass of water, as you recommend 
: The failing system uses much slower storage, and I probably ran the initialization seatable.sh commands too quickly after docker-compose up -d. When I tried again and waited some time, the initialization of the variable worked. 
Reading the seatable.sh source I figured out that deleting the problematic line PLUGINS_REPO_ID='' in dtable_web_settings.py, and the running the seatable.sh, will generate the desired repo id and insert it into the settings file. (seatable.sh only checks if the string “PLUGINS_REPO_ID” is present in the settings file, but not if it is set to a meaningful value, that’s why it has to be deleted.)
AFAIK the depends_on declarations in docker compose ensures that containers are started in a certain order, but there is no guarantee that the service inside a previously started container is ready and accepting connections when the next container is started. This can lead to cases where errors are hard to reproduce across systems with varying performance. Some docker projects use the wait-for-it.sh workaround to make sure that for instance database and redis are actually done initializing before running the main application. Maybe that’s an approach seatable could use too.
I’m sorry for causing this confusion with my slow RAID 
