🐞 Bug: `.env` behaves differently than native compose

[tanasegabriel]

Bug Description

The native (e.g. docker compose) behaviour for a .env file in a project is to make its contents available to docker itself, but not expose them automatically to any containers. Variables defined that way can be passed to the containers using the environment attribute - this is useful for using interpolation.

When trying to use this approach, I noticed that all variables defined in the .env file are deployed to all containers in the project, which is unexpected.

Steps To Reproduce

1. Create a project with two containers and an .env file. Do not use the env_file attribute.
2. Start the project and inspect the environment variables of the two containers. They will incorrectly share the variables defined in .env.

Expected Behavior

Arcane should not force pass all environment variables to all containers and it should stay close to the native compose way of dealing with environment variables files.

Actual Behavior

Arcane unexpectedly passes all environment variables to all containers

Screenshots

No response

Arcane Version

v1.11.0

Installation Method

Docker Compose (Recommended)

Environment Type

Local Docker (Single instance)

Database Type

SQLite (Default)

Operating System

Linux

Docker Version

29.1.3

Browser & Version

No response

Relevant Logs or Error Messages

### With the project deployed with Arcane:


➜  dco exec -it nginx_1 sh -c "printenv | grep ARCANE"
ARCANE_dev=true
ARCANE_DOMAIN=arcane.dev
ARCANE_DEV=true
➜  dco exec -it nginx_2 sh -c "printenv | grep ARCANE"
ARCANE_domain=my_subdomain.arcane.dev
ARCANE_DOMAIN=arcane.dev
ARCANE_DEV=true


### With the project deployed with `docker compose`:


➜ docker compose up -d
[+] up 2/2
 ✔ Container nginx_1 Recreated                                                                                                                                 0.3s 
 ✔ Container nginx_2 Recreated                                                                                                                                 0.3s 
➜  dco exec -it nginx_1 sh -c "printenv | grep ARCANE"
ARCANE_dev=true
➜  dco exec -it nginx_2 sh -c "printenv | grep ARCANE"
ARCANE_domain=my_subdomain.arcane.dev
➜  test

Docker Compose Configuration

services:
  nginx_1:
    image: nginx:alpine
    container_name: nginx_1
    environment:
      ARCANE_dev: ${ARCANE_DEV}

  nginx_2:
    image: nginx:alpine
    container_name: nginx_2
    environment:
      ARCANE_domain: my_subdomain.${DOMAIN}

Environment Configuration (.env file)

ARCANE_DOMAIN=arcane.dev
ARCANE_DEV=true

Additional Context

I currently work around this by using a different name for my .env file and just passing this to arcane’s container via env_file. This makes the variables available for docker compose without deploying them to the containers themselves. And on my host, to maintain the native behaviour (compose automatically loads any file named .env), I set COMPOSE_ENV_FILES=${project_dir}/.vars.env