Summary

start.sh appends a hardcoded IS_CONFIG_VARIABLES_IN_DB_ENABLED=false after copying /app/data/env, so any value a user sets for that variable in /app/data/env is silently overridden on every start.

Details

In /app/pkg/start.sh:

cat /app/data/env > /run/twenty-server/.env
cat >> /run/twenty-server/.env <<EOT
IS_CONFIG_VARIABLES_IN_DB_ENABLED=false
...
EOT

Since the generated .env is read top to bottom, the appended line wins. I had IS_CONFIG_VARIABLES_IN_DB_ENABLED=true in /app/data/env; the resulting /run/twenty-server/.env contains false.

Impact

With database configuration disabled, Twenty's Admin Panel still renders the Configuration Variables and AI model settings, but no write succeeds. From the UI this looks like a broken feature rather than a deliberate deployment mode — in my case a generic "failed to update model recommendations" toast with no indication that the panel is read-only by design.

It also means the only way to configure the instance is to edit /app/data/env and restart, which is not discoverable from the app itself.

Suggested fix

Only append the default when the user has not set it:

grep -q '^IS_CONFIG_VARIABLES_IN_DB_ENABLED=' /app/data/env \
  || echo 'IS_CONFIG_VARIABLES_IN_DB_ENABLED=false' >> /run/twenty-server/.env

Same pattern would apply to any other variable in that heredoc that isn't strictly infrastructure-bound (the Postgres/Redis/APP_SECRET lines obviously need to stay authoritative).

Happy to test a build if that helps.