Enable Gemini 2.5 Pro Function Install on Cloudron (needs google-genai)

[go-run-jump]

Hi,

Requesting a fix to allow installing Open WebUI functions that need extra packages on Cloudron.

Specifically, I want to use the function for Google Gemini (https://openwebui.com/f/suurt8ll/gemini_manifold_google_genai). This uses the google-genai package and would enable interacting with the new Gemini 2.5 Pro model – arguably state-of-the-art right now. Importantly it supports features like seeing the model's "thoughts", which is a very interesting capability.

Currently, Open WebUI's function installer tries to install google-genai (or other required packages) to /app/code and fails because it's a read-only filesystem (OSError 30).

Can the Cloudron package be modified so this installer uses /app/data instead, and Python can find the packages there?

Is this fix possible?

Thanks.

[BrutalBirdie]

Hey @go-run-jump since it is the weekend
If you want to tinker a bit, you can create a clone of your OpenWebUI App, put the clone in recovery mode and run the:

/app/pkg/start.sh

yourself.

This way, everything is read-write, and you could start testing if everything else works with the Gemini 2.5 Pro.

Just if you want to tinker

[go-run-jump]

@BrutalBirdie Hey, thanks for the recovery mode tip for weekend tinkering!

I gave it a shot: cloned the app, used recovery mode, and manually ran pip install google-genai in the terminal. That worked, and the Gemini function requiring it did become active in Open WebUI.

Unfortunately, it turns out Google removed the "thoughts" feature via the API recently (see discussion here: https://github.com/googleapis/python-genai/issues/226), so that specific goal is moot now, it seems.

However, this experiment confirms the underlying need. It would still be very valuable if Open WebUI's own mechanism for installing function dependencies (defined in frontmatter) could work correctly on Cloudron by targeting /app/data. This would allow other current or future functions needing packages (beyond just this specific Gemini one) to be installed seamlessly as intended by Open WebUI, without needing manual recovery mode workarounds.

So, the original request to fix that installer path for the Frontmatter mechanism remains relevant for general function extensibility.

Thanks again for the suggestion!