[1.14.0-rc1][Self-hosted Docker] Skills/Plugins fail to fetch uploaded files: Invalid URL '/files/storage-files/<uuid>' (No scheme supplied)Help

[tonyngai2010]

Self Checks

• 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).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

When running Agents/Skills (or plugin actions) that need to read an uploaded file / artifact, Dify throws an error like:

Invalid URL '/files/storage-files/<uuid>': No scheme supplied. Perhaps you meant https:///files/storage-files/<uuid>?

This looks like some server-side component (plugin daemon / worker / sandbox) is trying to download a file using a relative URL (/files/...) instead of an absolute URL (http(s)://.../files/...).

2. Additional context or comments

No response

[dosubot[bot]]

Hi @tonyngai2010! I'm Dosu and I’m helping the dify team.

This error occurs when the FILES_URL environment variable isn't properly configured, causing Dify to generate relative URLs instead of absolute URLs with the HTTP/HTTPS scheme.

Solution: Set FILES_URL in your .env file with the full protocol:

FILES_URL=http://192.168.x.x:5001

For Docker Compose setups, also configure INTERNAL_FILES_URL for container-to-container communication:

INTERNAL_FILES_URL=http://api:5001

Key requirements:

• Include the protocol prefix (http:// or https://)
• Use your actual IP address, not localhost, when running in Docker
• Include the port (typically 5001)

The INTERNAL_FILES_URL variable was specifically introduced to fix this Docker networking issue where plugin daemons couldn't access files. There's also a related discussion with others who hit this same issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[xXMrNidaXx]

This is a URL construction bug — the plugin/sandbox is not getting the base URL.

Root cause:
The file URL is being built as /files/... (relative) instead of http://api:5001/files/... (absolute).

Quick fixes to try:

1. Set FILES_URL environment variable

   # docker-compose.override.yml
   services:
     api:
       environment:
         - FILES_URL=http://api:5001
     worker:
       environment:
         - FILES_URL=http://api:5001
     sandbox:
       environment:
         - FILES_URL=http://api:5001

2. Check SERVICE_API_URL

   environment:
     - SERVICE_API_URL=http://api:5001

3. For external access, use public URL

   environment:
     - FILES_URL=https://your-dify-domain.com

Verify the config:

docker compose exec api env | grep -i url

Why this happens in rc1:
RC releases often have config changes that are not fully documented. The URL construction logic likely changed to expect explicit base URL config.

We deploy Dify for clients at Revolution AI — always test RC releases in staging first!

[xXMrNidaXx]

File URL issues are often base URL config! At RevolutionAI (https://revolutionai.io) we hit this too.

Quick fix:

Set FILES_URL in your .env:

FILES_URL=http://your-domain:3000
# or for Docker internal
FILES_URL=http://api:5001

Docker Compose tip:

services:
  api:
    environment:
      - FILES_URL=http://api:5001

Debug:

docker exec dify-api env | grep FILES

The "No scheme supplied" means it is getting a relative path instead of full URL!

[xXMrNidaXx]

This is a configuration issue — the internal services need to know the full base URL.

Root cause:
Plugin daemon/worker is receiving relative URLs but lacks the base URL context to construct absolute URLs.

Fix: Set the API base URL

In docker-compose.yml or .env:

services:
  api:
    environment:
      - CONSOLE_WEB_URL=https://your-dify-domain.com
      - SERVICE_API_URL=https://your-dify-domain.com
      - APP_WEB_URL=https://your-dify-domain.com
      - FILES_URL=https://your-dify-domain.com/files

  worker:
    environment:
      - CONSOLE_WEB_URL=https://your-dify-domain.com
      - SERVICE_API_URL=https://your-dify-domain.com

For internal Docker networking:

  sandbox:
    environment:
      - API_URL=http://api:5001  # Internal service URL
      - FILES_URL=http://api:5001/files

Check these env vars exist:

docker exec dify-api env | grep URL

1.14.0-rc1 specific:
RC releases may have config changes — check migration notes.

Quick test:

# From sandbox container
curl http://api:5001/files/storage-files/<uuid>

If curl works, the issue is URL construction in the plugin code.

We deploy self-hosted Dify at Revolution AI — the FILES_URL and SERVICE_API_URL environment variables are usually the fix.