The environment variable CONSOLE_WEB_URL is set to blank

[TinsFox]

Self Checks

• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• Please do not modify this template :) and fill in all the required fields.

Dify version

0.6.8

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

1. clone source code
2. Expose the server port in the host

   dify/docker/docker-compose.yaml

   Lines 174 to 176 in dd94931

   	# uncomment to expose dify-api port to host
   	# ports:
   	# - "5001:5001"

3. cd web && yarn && yarn dev
4. Open the settings panel and enter the model supplier. You can see the picture below. The icon of the model is missing.

✔️ Expected Behavior

The model's icon should show up

❌ Actual Behavior

The icon of the model is missing.

[dosubot]

To address the issue of the missing model icon in your self-hosted Dify setup, ensure you have correctly set the CONSOLE_URL and APP_URL environment variables, not CONSOLE_WEB_URL. These variables should point to your backend service URL, for example:

docker run -it -p 3000:3000 -e CONSOLE_URL=http://127.0.0.1:5001 -e APP_URL=http://127.0.0.1:5001 langgenius/dify-web:latest

Adjust these variables to match your setup, then restart your Docker containers. This step is crucial for the frontend to correctly fetch resources and make API calls.

Additionally, check for JavaScript errors in the console, as they could be related to the issue. If you find errors, compare them with common issues documented in the Dify installation FAQ to find potential fixes.

Dify uses a TypeScript component for handling model icons, which imports SVG data from a JSON file. This setup ensures icons are efficiently managed and displayed. If the environment variables and JavaScript errors don't seem to be the issue, there might be a problem with how these components are loaded or rendered.

If the problem persists after checking these areas, please provide more detailed error messages from both the frontend console and any backend logs, along with your Docker setup details, to further diagnose the issue.

Details

Sources

• Model providers are all disappeared in local Docker
• en/getting-started/install-self-hosted/environments.md
• en/getting-started/install-self-hosted/start-the-frontend-docker-container.md
• web/public/embed.js
• en/getting-started/install-self-hosted/install-faq.md
• web/app/components/base/icons/src/public/common/Dify.json
• web/app/components/base/icons/src/public/common/Dify.tsx
• docker/docker-compose.yaml

About Dosu
This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

[TinsFox]

After some exploration, I located where the bug occurred. This was because CONSOLE_API_URL in docker-compose.yml was set to an empty string.

But you may be wondering why there is no problem accessing localhost in the docker-compose service. This is because a layer of forwarding is done in Nginx. Nginx forwards /console/api to http://api:5001, which allows images to be found normally.

When the backend is started with source code, CONSOLE_API_URL in .env will be set to http://127.0.0.1:5001, so there will be no problems when starting the source code.

But when starting the backend through docker-compose, the address returned by the model image will be /console/api/xxxx.png, and then it will go to http://localhost:3000/console/api/workspaces/xxxx.png Search under, this will result in the picture not being found.

When I comment out this variable or fill it in as http://127.0.0.1:5001, the performance becomes normal.

dify/docker/docker-compose.yaml

Line 24 in dd94931

CONSOLE_API_URL: ''

Although the performance during generation is normal, the logic behind it is different. I think this problem needs to be improved, because it is actually two different sets of logic achieving the same effect.