Dify.ai, a self-hosted prompt-management tool

[james]

Hello @timconsidine

When you update the CloudronManifest.json file at e.g.: https://communityapps.appx.uk/cloudron-dify/CloudronVersions.json installation that used this URL will pickup the update automatically.

[girish]

@timconsidine if you want (to increase you work ), you can open a separate package updates thread for a package.

[RoundHouse1924]

FWIW, Dify.ai is licensed under a modified version of the Apache License 2.0 with additional conditions:-
https://github.com/langgenius/dify/blob/main/LICENSE

[LoudLemur]

This post is deleted!

[timconsidine]

@LoudLemur also already packaged as community app
If you don’t check before posting, you risk becoming a bot posting slop

[LoudLemur]

@timconsidine This is a good point. If I do try these in the future, I shall be sure of checking if they are packaged first. It is useful to check if the estimates prove accurate though.

Can you remember if this was actually hard?

[ekevu123]

@LoudLemur said:

@ekevu123 https://forum.cloudron.io/topic/12472/please-use-this-template-to-make-an-app-wishlist-request/13

Thank you for pointing out the template, but when I posted this, this didn't exist yet and I didn't want to go through my posts retroactively.

[timconsidine]

Updated my Dify community app to upstream 1.14.2 with sandbox enabled

https://communityapps.appx.uk/cloudron-dify/CloudronVersions.json

I'm not a Dify expert. Started it mostly for RAG, but I use my own simpler more-focussed custom RAG apps. Looking for use cases for Dify.

[LoudLemur]

@timconsidine

Bug report for the Cloudron Dify community package: plugins fail: "failed to find uv path"

Package: io.timconsidine.dify (community), version 2.0.15, image forgejo.tcjc.uk/cca/cloudron-dify:2.0.15
Cloudron: 9.x

Symptom

Installing any model-provider plugin from the Marketplace (e.g. Text Embedding Inference / langgenius/huggingface_tei) fails with:

failed to launch plugin: failed to find uv path: failed to find uv path: exit status 1
failed to init environment

Because in Dify 2.0 every model provider is a Python plugin, this blocks all providers — embeddings, LLMs, and rerank — so the app can't be wired to any model.

Root cause (verified in the running container)

The image does not contain the uv binary, but the plugin daemon shells out to uv to build each plugin's Python venv.

• which uv, find / -name uv -type f, /app/code/api/.venv/bin/uv, and python -c "import uv" all come up empty.
• start.sh expects uv: it creates /app/data/cache/uv and /app/data/uv/python and exports UV_CACHE_DIR / UV_PYTHON_INSTALL_DIR, but the binary itself was never installed, and no UV_PATH is set.
• The plugin daemon's PATH (inherited from start.sh → supervisord) is /app/code/api/.venv/bin:/usr/local/...:/usr/bin:... — all read-only, none containing uv.

It is not fixable at runtime by the operator: the rootfs is read-only, and start.sh regenerates /app/data/api-env on every boot, so there is no persistent hook to add uv or UV_PATH.

Suggested fix (image-side)

Install uv into the image and make it discoverable to the plugin daemon. Any one of:

1. In the Dockerfile, install uv into the API venv: pip install uv (puts uv in /app/code/api/.venv/bin, already on the daemon's PATH), or copy the static binary: COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv.
2. Optionally also export an explicit UV_PATH=/usr/local/bin/uv (or the venv path) in start.sh so the daemon doesn't rely on PATH lookup.

After that, confirm a Marketplace plugin (e.g. langgenius/huggingface_tei) installs and a Rerank model can be added.

Note

Pin/ship a known uv version for reproducibility. This is the same class as langgenius/dify#19522, but here uv is genuinely absent from the image rather than mis-detected.

[timconsidine]

@LoudLemur away currently but will look into it in my return