If you need it at container runtime, you can create an.env file viainitializeCommand. Then you can have docker compose set that env file for the service.
Consider something like this:

devcontainer.json

{"initializeCommand":"echo\"USERNAME=$USER\nUSER_UID=$(id -u $USER)\nGROUPNAME=$(id -gn $USER)\nGROUP_GID=$(id -g $USER)\nIS_AMD=$(test $(uname -m) = amd64 && echo true || echo false)\" > .devcontainer/.env","dockerComposeFile":"../docker-compose.yml","service":"main"}

docker-compose:

services:main:image:my_image:latestenv_file:      -.devcontainer/.env

This would probably fail on the first run since the .env will be created in the same context as the docker-compose command, but after that it should work, I use a variation of this as well.

Note that this will work ONLY for container environment variable and not environment variables you need to have present at build time.

You can use thecontainerEnv|remoteEnv andlocalEnv with templating to set environment variables in the container.

{"containerEnv": {"INTERNAL_VAR":"${localEnv:YOUR_EXTERNAL_VAR}","INTERNAL_VAR_DEFAULT":"${localEnv:YOUR_UNSET_VAR:default value}"}

The difference betweencontainerEnv andremoteEnv is the former bakes the variable into the container but the later sets the variable when the container starts so it's better for things that may change regularly