Acontece que nem todo servidor terá um arquivo de .env, isso quebraria a inicialização do projeto.
Devemos pegar pelo pacote do dotenv mesmo, inclusive eu utilizo o servidor railway, aceita, porém, eu não subo o arquivo .env
O legal séria colocar o arquivo .env, em um .gitignore, para ele não subir para o github/etc... e não ter falhas de segurança caso alguém consegui acesso ao código.
Resumindo: utilize o dotenv...
No servidor as variáveis de ambiente devem estar no ambiente do servidor. Como a %PATH% do windows.
A aplicação não necessáriamente depende de um .env
há formas simples de carregar esse arquivo para o ambiente do servidor
Não é recomendado subir esse arquivo nunca para o servidor, se trata de uma prática inviável, o conceito de variáveis de ambiente é justamente elas virem direto do OS, seja pelo PATH do windows, ou o .bashrc do linux.
Se for para subir o .env seja github ou servidor, não há sentido utilizar este conceito tão importante, nesse caso, podemos apenas colocar direto no código.
Lembrando que na área de segurança da informação a primeira coisa que um profissional (Hacker), aprende é um jogo chamado CTF - Capture The Flag, que consiste em invadir servidores e pegar algum arquivo lá que foi deixado para esse fim, a prática de invadir e pegar .envs do sistema é super comum, comprometendo o acesso direto ao banco de dados.
Quando colocamos então apenas as variaveis de ambiente vindo do OS, impede que ao ser chamado a API ela revele arquivos dentro do código como o .env, impede a interceptação do mesmo, lembrando que se enviar direto ao github, pode ser interceptado, direto ao servidor pode ser pego usando ferramenta chamada Nikto, usada para mapear arquivos, rotas, etc... dentro de sites.
Resumindo: não tenham o retrabalho de enviar para o servidor o .env, sigam o conceito e deixem apenas no OS