[Bug]: ENV file not being created during deploy?

[byronwall]

Description

I am getting an error when trying to deploy an updated LibreChat. It fails with message below about env being a directory

The application is already deployed and running OK, but I want to update it. Unfortunately, I cannot determine what is going wrong on the re-deploy.

Since I did not want to mess with a volume or .env file, I copied all of the expected settings to Coolify's ENV section.

Am I missing something obvious, or is there something odd going on with ENV variables?

A snippet of that section shown here:

Minimal Reproduction (if possible, example repository)

Repo: https://github.com/byronwall/LibreChat

Steps:

1. Previously deployed this commit: byronwall/LibreChat@c315ae6
2. Updated repo and attempted to deploy again - fails

I am trying to deploy with the deploy-compose.yml file: https://github.com/byronwall/LibreChat/blob/main/deploy-compose.yml

version: "3.8"
services:
  api:
    # build:
    #   context: .
    #   dockerfile: Dockerfile.multi
    #   target: api-build
    image: ghcr.io/danny-avila/librechat-dev-api:latest
    container_name: LibreChat-API
    ports:
      - 3080:3080
    depends_on:
      - mongodb
      - rag_api
    restart: always
    extra_hosts:
    - "host.docker.internal:host-gateway"
    env_file:
      - .env
    environment:
      - HOST=0.0.0.0
      - NODE_ENV=production
      - MONGO_URI=mongodb://mongodb:27017/LibreChat
      - MEILI_HOST=http://meilisearch:7700
      - RAG_PORT=${RAG_PORT:-8000}
      - RAG_API_URL=http://rag_api:${RAG_PORT:-8000}
    volumes:
      - type: bind
        source: ./librechat.yaml
        target: /app/librechat.yaml
      - ./images:/app/client/public/images
      - ./logs:/app/api/logs
  client:
    build:
      context: .
      dockerfile: Dockerfile.multi
      target: prod-stage
    container_name: LibreChat-NGINX
    ports:
      - 3002:80
    depends_on:
      - api
    restart: always
  mongodb:
    container_name: chat-mongodb
    # ports:  # Uncomment this to access mongodb from outside docker, not safe in deployment
    #   - 27018:27017
    image: mongo
    restart: always
    volumes:
      - ./data-node:/data/db
    command: mongod --noauth
  meilisearch:
    container_name: chat-meilisearch
    image: getmeili/meilisearch:v1.7.3
    # ports: # Uncomment this to access meilisearch from outside docker
    #   - 7700:7700 # if exposing these ports, make sure your master key is not the default value
    env_file:
      - .env
    environment:
      - MEILI_HOST=http://meilisearch:7700
      - MEILI_NO_ANALYTICS=true
    volumes:
      - ./meili_data_v1.7:/meili_data
  vectordb:
    image: ankane/pgvector:latest
    environment:
      POSTGRES_DB: mydatabase
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypassword
    restart: always
    volumes:
      - pgdata2:/var/lib/postgresql/data
  rag_api:
    image: ghcr.io/danny-avila/librechat-rag-api-dev-lite:latest
    environment:
      - DB_HOST=vectordb
      - RAG_PORT=${RAG_PORT:-8000}
    restart: always
    depends_on:
      - vectordb
    env_file:
      - .env

volumes:
  pgdata2:

Exception or Error

Relevant part:

[2024-May-03 02:47:34.495108] tee: /data/coolify/applications/n0844g0/.env: Is a directory
[2024-May-03 02:47:34.565642] Oops something is not okay, are you okay? 😢
[2024-May-03 02:47:34.567588] tee: /data/coolify/applications/n0844g0/.env: Is a directory

Full log:

[2024-May-03 02:47:27.382953] Starting deployment of danny-avila/-libre-chat:main-j880wgg to localhost.
[2024-May-03 02:47:27.536922] Preparing container with helper image: ghcr.io/coollabsio/coolify-helper:latest.
[2024-May-03 02:47:27.641163]

[COMMAND] docker rm -f q04coos
[OUTPUT]
Error response from daemon: No such container: q04coos

[2024-May-03 02:47:27.755827]

[COMMAND] docker run -d --network coolify --name q04coos --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/coollabsio/coolify-helper:latest
[OUTPUT]
2be8de8aa61ec4862cd5184edf9581268cded549deb81141396c2423368af712

[2024-May-03 02:47:28.412146]

[COMMAND] docker exec q04coos bash -c 'GIT_SSH_COMMAND="ssh -o ConnectTimeout=30 -p 22 -o Port=22 -o LogLevel=ERROR -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" git ls-remote https://github.com/byronwall/LibreChat main'
[OUTPUT]
cb48f8de243ec400346e7d3be987a27726a5bfce refs/heads/main

[2024-May-03 02:47:28.424488] ----------------------------------------
[2024-May-03 02:47:28.426820] Importing byronwall/LibreChat:main (commit sha cb48f8de243ec400346e7d3be987a27726a5bfce) to /artifacts/q04coos.
[2024-May-03 02:47:28.566198]

[COMMAND] docker exec q04coos bash -c 'git clone -b "main" https://github.com/byronwall/LibreChat /artifacts/q04coos && cd /artifacts/q04coos && GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" git -c advice.detachedHead=false checkout cb48f8de243ec400346e7d3be987a27726a5bfce >/dev/null 2>&1 && cd /artifacts/q04coos && sed -i "s#git@\(.*\):#https://\1/#g" /artifacts/q04coos/.gitmodules || true && cd /artifacts/q04coos && GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" git submodule update --init --recursive && cd /artifacts/q04coos && GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" git lfs pull'
[OUTPUT]
Cloning into '/artifacts/q04coos'...

[2024-May-03 02:47:31.219782]

[COMMAND] docker exec q04coos bash -c 'git clone -b "main" https://github.com/byronwall/LibreChat /artifacts/q04coos && cd /artifacts/q04coos && GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" git -c advice.detachedHead=false checkout cb48f8de243ec400346e7d3be987a27726a5bfce >/dev/null 2>&1 && cd /artifacts/q04coos && sed -i "s#git@\(.*\):#https://\1/#g" /artifacts/q04coos/.gitmodules || true && cd /artifacts/q04coos && GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" git submodule update --init --recursive && cd /artifacts/q04coos && GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" git lfs pull'
[OUTPUT]
sed: /artifacts/q04coos/.gitmodules: No such file or directory

[2024-May-03 02:47:34.495108] tee: /data/coolify/applications/n0844g0/.env: Is a directory

[2024-May-03 02:47:34.565642] Oops something is not okay, are you okay? 😢

[2024-May-03 02:47:34.567588] tee: /data/coolify/applications/n0844g0/.env: Is a directory

Version

4.0.0 beta 271

[byronwall]

My Coolify instance bumped to beta 277 but still experiences the same problems. I did not expect a fix based on release notes but wanted to provide an update if that's any help.

Dumb question: are the ENV variables specified in the Coolify settings supposed to end up in a .env file that eventually ends up in the Docker scope? That is, should this work the way I assume, or am I wrong? I read through a bit of the PHP code, and it seemed that Coolify is trying to write a .env based on the settings, but I don't have a good way to debug it.

If I'm wrong about these ending up in a .env, I can easily modify the compose file to call out the variables, but I was hoping to avoid that because I'm lazy.

As an aside, thanks for building and maintaining Coolify. It really is a powerful platform that lets me not worry about a bunch of these details that I know are no fun to get right.

[byronwall]

So I got this working. I think the problem was me. Or at least my ignorance kept me from solving things when I first reported the issue.

I eventually read the error message closely and SSH'ed into the box to troubleshoot. Ultimately, .env actually was a directory for some reason. I simply did rmdir .env to knock it out and start over. That immediately allowed Coolify to progress and build containers.

I'm not sure how it got into that state. When I originally went looking for the .env file, I forgot that ls does not show dot files by default. I assume that no .env was present. I should really stop forgetting how ls works. After I eventually ran ls -a, it became clear that something existed as .env, but it was indeed a directory.

After things deployed again, I changed an ENV var in the Coolify configuration. After another deploy, I confirm that setting correctly ended up in the .env file on disk, and the app reflects the change.

I guess my only comments at this point are:

• Try to find smarter users
• Consider improving the documentation and ENV var page to reflect the possible paths that ENV vars get into the container. In my case, changes on the Coolify Environment Variable page definitely get written to a .env file that the container uses. Given that, the yellow text saying This variable is not found in the compose file, so it won't be used. is downright confusing.
• Similarly, the copy at https://coolify.io/docs/knowledge-base/environment-variables is not particularly helpful at describing what happens.

Feel free to close this issue, unless you see anything actionable. I am good to go.