Na verdade... o seu .env tem que funcionar com os valores pertinentes para cada ambiente.

Deveria ter um .env.prod, .env.local, .env.dev... e assim por diante. Em teoria, as variáveis do .env real que rodam em produção deveriam ser conhecidas apenas por quem faz o deploy em produção, por quem gerencia as pipelines, etc.

Localmente, você deveria ter um .env que não tivesse nem um resquício das variáveis que são usadas de verdade e que todos os membros do projeto deveriam ter acesso e que poderiam inclusive ir para o repositório.

Vamos supor que você tem:

.env.example -> tem que estar no repositório

HOST_SERVICE_A=
AUTH_KEY_SERVICE_A=

.env.local -> pode ir pro repositório

HOST_SERVICE_A=localhost:8002
AUTH_KEY_SERVICE_A=uma_key_local_sem_importancia

.env.prod -> nunca jamais deve estar no repositório

HOST_SERVICE_A=host_servico_a_prod.com.br
AUTH_KEY_SERVICE_A=uma_key_secreta_que_ninguem_saberia_e_estaria_na_pipeline

.env.dev -> talvez possa estar no repositório

HOST_SERVICE_A=host_servico_a_homolog.com.br ou host_servico_a_mockado.com.br
AUTH_KEY_SERVICE_A=uma_key_de_homologação_ou_do_mock_que_é_menos_sensivel

Perceba que em todos esses casos, a variável do prod (sejam elas quais forem, aqui eu dei só o exemplo da url de um serviço) NUNCA foi exposta para os outros contextos. Se você for subir o serviço A localmente, você passaria o endereço localhost. Mas se isso fosse impossível, você usaria um ambiente de homologação ou um Mock, mas não o ambiente que se usa em produção.

Se seu projeto não possui essa organização então obrigatóriamente você precisa caçar esses valores pra conseguir trabalhar, mas é uma má prática de segurança que seja necessário saber os valores reais para conseguir desenvolver alguma coisa.