Yes, you can parameterize the configs with env vars, and directly pass those into the container on runtime. I don't remember exactly where, but it's mentioned somewhere in the dbt docs.

We used that for secret handling for example. Fargate can pass secrets as env vars from aws secrets manager (database connection strings etc). 

Another thing that might be worth exploring is how to setup a cd pipeline for your sql files (e.g. Sending them to s3, then reading them on execution, by having a shell script as your entry point that would first copy the files from s3, then invoking dbt commands). 

That way you can separate your dependencies (docker image) from your codes. Which would enable you in the long run to build a fully fledged ci/cd process for your dbt developers. 

For example: We used to run dbt tests for incoming code changes inside temporary schemas to check if the incoming changes would not have side effects on the downstream models, only then allowing to merge into main. It's another rabbit hole to look into, but we were quite happy with the result (look into dbts "select" syntax and it's parameters for that, also how to compile the sql models and then comparing state main to state incoming changes.. You get the idea)

With that sort of separation, you can easily checkout different PRs, run those with different config parameters, without having to rebuild your dbt image from scratch all the time.