/claim #7655

Problem

Coolify auto-injects env_file: ['.env'] into every service in a Docker Compose project. This means all environment variables defined via the Coolify UI end up as runtime env vars in every container, regardless of which service they were intended for.

This is a security issue (container A can read secrets meant for container B) and it breaks Docker Compose semantics — the .env file is supposed to be used for variable interpolation only (${VAR} substitution in the compose file), not for runtime injection.

As @nuxwin correctly pointed out in the issue discussion, the previous PRs went in the wrong direction by splitting .env into per-service files or adding database columns. The root cause is simpler: Coolify should not be injecting .env via env_file at all.

Fix

Removed the auto-injection of env_file: ['.env'] from three places:

1. ApplicationDeploymentJob::deploy_docker_compose_buildpack() — was overwriting env_file for all services after parsing
2. applicationParser() in parsers.php — was appending .env to env_file for compose v3+ parsing
3. serviceParser() in parsers.php — same issue for one-click services

The .env file is still created and written with all the environment variables. Docker Compose will still read it automatically for ${VAR} interpolation in the compose file — that’s standard behavior and doesn’t require env_file.

Any user-defined env_file entries in the compose file are preserved (minus .env itself, to clean up any previously injected references).

Single-container deployments (dockerimage, dockerfile, nixpacks) are not affected since they only have one service.

Backward compatibility

Existing users who rely on Coolify env vars being available as runtime vars inside their containers will need to add environment: or env_file: to their compose file explicitly. This is standard Docker Compose usage.

For example, if they had a var DB_PASSWORD set in Coolify UI and used it in their app container, they’d add to their compose file:

services:
  app:
    environment:
      - DB_PASSWORD=${DB_PASSWORD}

This is how Docker Compose is supposed to work — interpolation from .env, explicit declaration for runtime.

What I did NOT change

• No database migrations
• No new UI fields
• No new columns or models
• The .env file generation is untouched — it still gets created for interpolation
• Single-container deployments still work exactly as before