Hey dify team I need know how can I access the document which i have already uploaded in self-hosted dify via docker

[raj-triforce]

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.

Dify team
I’m using self-hosted Dify via Docker and have already uploaded documents to the system. I’m able to retrieve and process the content using the Document Extractor node.
However, I’d like to access the original uploaded file itself inside a Code node, so I can manipulate it directly using Python (for example, read the file, transform it, or pass it to another library).
Is there a supported way to:
Access the uploaded document file from a Code node?
Obtain a file path, file object, or build a URL for the uploaded document?
Or otherwise programmatically retrieve the raw file within a workflow?
If this isn’t currently supported, any recommended workaround would be appreciated.
Thanks in advance!

@dosubot

2. Additional context or comments

No response

[dosubot[bot]]

You can access the original uploaded document file in a Code node by using the signed URL provided in the file metadata. In Dify workflows, uploaded files are exposed as variables (often in sys.files or as node outputs), and each file dict includes a url field—a signed, temporary download link. In your Python code node, you can fetch and manipulate the file like this:

import requests

# Suppose 'file_info' is the file metadata dict passed to your code node
file_url = file_info['url']  # This is the signed download URL

response = requests.get(file_url)
response.raise_for_status()
file_bytes = response.content

# Now you can process file_bytes as needed (e.g., pass to another library)

If you have multiple files, iterate over sys.files and use each file's url field.

If the url is missing or invalid (e.g., missing http://), check your Docker .env file and set FILES_URL to your Dify server's accessible address (including the scheme and port), then restart your Docker containers. This ensures URLs are generated correctly for local storage setups. More details and troubleshooting steps are available in this discussion: source.

Direct access to the backend storage filename (the randomized file in your Docker volume) is not exposed by default for security reasons. If you need to pass the backend filename to another system, you can modify the Dify backend code to include the storage_key in the file metadata by updating the to_dict() method in api/core/file/models.py, then restart Dify. See how to do this here: source.

Code nodes run in a sandboxed environment and cannot access the file system directly or import backend modules—use the signed URL approach for file access.

For dataset documents, there is also an API endpoint that returns a signed download URL, but this is only for files attached to datasets, not general workflow uploads.

This signed URL method is the recommended and secure way to programmatically retrieve and manipulate uploaded files in Dify workflows.

To reply, just mention @dosu.

---

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

   

[raj-triforce]

@dosubot but this link have expirations i need link which i can access whenever i wanted and also wanted to know how much expiration is there on signed file link and can we increase via env or by anything

[dosubot[bot]]

Signed file links in Dify expire after a default of 5 minutes (300 seconds), controlled by the FILES_ACCESS_TIMEOUT environment variable. You can increase the expiration by setting FILES_ACCESS_TIMEOUT to a higher value in your .env or Docker Compose config and restarting your containers—for example, 86400 for 24 hours or even longer if needed. However, there’s no built-in way to make links truly permanent; setting a very large timeout is possible but not recommended, as it increases the risk of unauthorized access if a link is leaked. Setting FILES_ACCESS_TIMEOUT to 0 will cause links to expire instantly, not disable expiration. For truly permanent, non-expiring links, backend code changes are required, which is not recommended for most setups due to security concerns. More details here: source, source.

To reply, just mention @dosu.

---

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

   

[raj-triforce]

I have question so now I'm working with two workflow, one triggers another using http node, so if some user uploaded file and he wanted to regenerate the outcomes so they can just invoke the, workflow again so what I'm doing is sending the upload_file_id to the my another workflow which is receiving the upload_file_id and by that doc extractor is getting the file and is able to get the content but, doc extractor is not using the url which is provided by start node rather it creates its own or what seems i dont know what is happening under hood of doc extractor so i found 2 different urls when tracing one is working another is not working the not working url is called in doc extractor remote_url, and working one is called url and now the url which start node exposes the same remote_url which is obvious now.

and when i saw what is my code node is taking input is the same url which is not working in doc extractor, now i need to access the working url please if some one or @dosubot if you know please let me know.


working url is marked in green, and not working in red and another screen shot is of code node which is not working obviously.

doc extractor:
working one : /files/04a6d6c3-7cde-40a1-878d-abec5f3c179f/file-preview?timestamp=1767694474&nonce=656a7e961661ddaafdd7aadec2058be6&sign=X5VbbZ0mGLdovzBJx3s1fnqHsZklmYTk4Vw3dAnBcMQ%3D

non-working: /files/04a6d6c3-7cde-40a1-878d-abec5f3c179f/file-preview?timestamp=1767683836&nonce=877964ae510e10426a41108fb3b55fbb&sign=y8_dAum_qKjCPsIypXwfg43jv-LgZ1EogeS3kf0tIcY%3D

code node:
non-working: /files/04a6d6c3-7cde-40a1-878d-abec5f3c179f/file-preview?timestamp=1767683836&nonce=877964ae510e10426a41108fb3b55fbb&sign=y8_dAum_qKjCPsIypXwfg43jv-LgZ1EogeS3kf0tIcY%3D

[dosubot[bot]]

Here’s what’s happening: the doc extractor generates a fresh signed URL for the file each time it runs, which is why its "url" field works. The "remote_url" you see is either a static remote link (for remote uploads) or a stale signed URL that’s expired—so passing it between workflows or into a code node doesn’t work.

To reliably access the file in chained workflows or code nodes, always pass the upload_file_id, not a static URL. Then, at the point you need to access the file (e.g., in your code node), generate a fresh signed URL using the upload_file_id. This ensures the link is valid and hasn’t expired.

Here’s a Python snippet you can use in a code node (if you can securely provide SECRET_KEY and FILES_URL as environment variables):

import os, time, hmac, hashlib, base64, urllib.parse

def get_signed_file_url(upload_file_id, secret_key, files_url):
    timestamp = str(int(time.time()))
    nonce = os.urandom(16).hex()
    msg = f"file-preview|{upload_file_id}|{timestamp}|{nonce}"
    sign = hmac.new(secret_key.encode(), msg.encode(), hashlib.sha256).digest()
    encoded_sign = base64.urlsafe_b64encode(sign).decode()
    query = {
        "timestamp": timestamp,
        "nonce": nonce,
        "sign": encoded_sign
    }
    url = f"{files_url}/files/{upload_file_id}/file-preview?{urllib.parse.urlencode(query)}"
    return url

# Usage:
# secret_key = os.environ["SECRET_KEY"]
# files_url = os.environ["FILES_URL"]
# file_url = get_signed_file_url(upload_file_id, secret_key, files_url)

Security note: Exposing SECRET_KEY to code nodes is risky—only do this if you trust the environment. If you can’t expose SECRET_KEY, you’ll need to generate the signed URL in a backend or trusted service and pass it to the code node at runtime.

For Docker setups, make sure FILES_URL is set to an address accessible by your code node (not localhost inside the container), and restart your containers after changing it.

Best practice: never pass static URLs between workflows; always pass upload_file_id and generate a fresh signed URL when you need to access the file. This matches how the doc extractor works internally and avoids expired links.
Reference: Dify file URL signing logic

To reply, just mention @dosu.

---

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

   

[heathdutton]

In the Code node, you can access uploaded files via their URL. The file info passed to your workflow includes a url property.

Example in Code node:

import requests

def main(file_url: str) -> dict:
    response = requests.get(file_url)
    content = response.content
    # do your processing here
    return {"result": "processed"}

The files are stored in the storage/ directory (mapped to /app/api/storage in Docker). But accessing via URL is the cleaner approach since it handles auth signatures automatically.

If you need the raw path, check your volume mapping - typically ./volumes/app/storage on the host.

Does that help?