Which to use: containerEnv or remoteEnv?

[jcbhmr]

👋 hello! this is more a question than an "issue" per-se

if i want to, say, set a laravel env var DB_CONNECTION=sqlite, which should i use?

https://containers.dev/implementors/json_reference/

specifically, what's the difference between "supporting service / tool (or sub-processes like terminals) but not the container as a whole" and "overrides environment variables for the container" ??

[jkeech]

containerEnv will set the variable on the docker container itself, so all processes spawned in the container will have access to it. But the env var also will be static for the life of the container -- you'd have to rebuild the container to update the value. remoteEnv is applied only to the VS Code server process that is running in the container (or the equivalent for other clients that connect to the container). If you have a background daemon that starts up in the container, it wouldn't see the env var. One benefit of remoteEnv is that you can update the values without having to rebuild the full container though since it would only require the VS Code server process to be relaunched with the updated environment variable value.

In short, I would recommend using containerEnv as much as possible since it allows all processes to see the env var and isn't client-specific. This is true particularly if the value is static. But if the value is not static, putting it in remoteEnv might be better.

[jcbhmr]

Thanks for your overview of the differences! ❤️ You perfectly answered my question. I'll use containerEnv for my DB_CONNECTION=sqlite variable.

🤔 Would it be possible to put something like this into the https://containers.dev/ website docs? Does an explanation already exist that I just missed/misunderstood?

[jkeech]

🤔 Would it be possible to put something like this into the https://containers.dev/ website docs? Does an explanation already exist that I just missed/misunderstood?

Good idea! @bamurtaugh can we expand the docs to describe the differences a bit better and encourage containerEnv over remoteEnv in many cases (including by moving containerEnv higher in the list above remoteEnv).

[bamurtaugh]

Thanks for opening @jcbhmr, and thanks for tagging me @jkeech! This sounds like a great idea to me too.

I opened an issue and can add this to my backlog: devcontainers/devcontainers.github.io#203. @jcbhmr if you'd like to open a PR, that'd be fantastic too as we welcome any and all contributions, and I'd be happy to review too!