Cloudron Forum

Even if IMO it's not appropriate for this package, the approach to bundle Ollama and Open WebUI together in the same package is an interesting one.

I was wondering if instead of packaging Ollama with it, we could package Pipelines and Open WebUI.

Pipelines in itself is really just a sandboxed runtime for python code, built for use with Open WebUI. It has no frontend, and the same dependencies as Open WebUI.

I think this'll be worth debating when comes the time to publish pipelines to the app store.

If merged, this PR should help us push this app into the store.

@joseph Hm. For some reason, I don't get the notification anymore. That's a weird behavior as the PTR record has existed for a few months now.

Regardless, issue solved.

I have a Cloudron server hosted on a DigitalOcean VPS.

The PTR record on their admin panel says it is present and looking it up using other online tools also shows up the PTR record.

For some reason, the Cloudron notification says it doesn't find one (null)

Port 25 is open.

@robw said in ETA for GPU support? Could we contribute to help it along?:

• If you already have a centrally managed non-Cloudron Ollama server but you want Cloudron for OpenWebUI front ends

Hey, that's my case .

Otherwise, I very much think that separating both of the Cloudron packages will be beneficial. Considering all the example use cases you listed, the need is more than justified.

A lot of companies that might deploy Cloudron for its ease of life features don't necessarily have a VPS with a GPU.

Also, (might help you to deepen your Cloudron knowledge) Cloudron packages usually are only one component/application.

Moreover, OpenWebUI is "just" a UI that supports connections to Ollama and isn't affiliated with it. Meaning that Ollama isn't a dependency of it at all.

I feel like that if GPU support works, having OpenWebUI and Ollama as separate packages would make maintenance easier.

With version 2.0 upcoming, we'll probably have to make somes changes to the package, especially the DB backend.

I'll be looking into it, see what we need to change.

https://github.com/louislam/uptime-kuma/releases/tag/2.0.0-beta.0

@robw

If we installed the NVIDIA Ubuntu GPU drivers in the Cloudron OS and started the OpenWebUI container with the GPU switch, would it just work?

Not necessarily, it depends on the GPU. While it may seem like a good idea, results will be very random. Also, nouveau (or whatever they're called now) drivers are the worst available out there. I've only had good results with nvidia official drivers.

Does installing the GPU drivers interfere with Cloudron's upgrade processes? (In our case, we wouldn't mind having to manage the GPU drivers separately, we don't expect Cloudron to manage non-native additions.)

Yes. Nvidia drivers are a pain to manage and often need debugging.

@girish done and ready @ https://github.com/Lanhild/web-check-cloudron

I've added the proxyAuth addon so that when deployed on Cloudron, only your users can use it.

In the package's start.sh, there is the variable NLTK_DATA set to /app/data/nltk. Though, the following error happening when uploading a markdown document shows that the variable is not assigned/doesn't work.

Sep 06 15:37:14 PermissionError: [Errno 13] Permission denied: '/root/nltk_data'
Sep 06 15:37:14 Traceback (most recent call last):
Sep 06 15:37:14 ^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 06 15:37:14 _download_nltk_packages_if_not_present()
Sep 06 15:37:14 data = loader.load()
Sep 06 15:37:14 download_nltk_packages()
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = func(*args, **kwargs)
Sep 06 15:37:14 elements = list(
Sep 06 15:37:14 elements = list(elements)
Sep 06 15:37:14 elements = self._get_elements()
Sep 06 15:37:14 for e in self._main.iter_elements():
Sep 06 15:37:14 if exceeds_cap_ratio(text, threshold=cap_threshold):
Sep 06 15:37:14 if is_possible_narrative_text(text):
Sep 06 15:37:14 if sentence_count(text, 3) > 1:
Sep 06 15:37:14 os.mkdir(targetpath, 0o700)
Sep 06 15:37:14 return list(self.lazy_load())
Sep 06 15:37:14 return partition_html(
Sep 06 15:37:14 return partition_md(filename=self.file_path, **self.unstructured_kwargs)
Sep 06 15:37:14 self._extract_member(tarinfo, os.path.join(path, tarinfo.name),
Sep 06 15:37:14 self._extract_one(tarinfo, path, set_attrs=not tarinfo.isdir(),
Sep 06 15:37:14 self._handle_fatal_error(e)
Sep 06 15:37:14 self.makedir(tarinfo, targetpath)
Sep 06 15:37:14 sentences = sent_tokenize(text)
Sep 06 15:37:14 tar.extractall(path=nltk_data_dir)
Sep 06 15:37:14 yield from block_item.iter_elements()
Sep 06 15:37:14 yield from block_item.iter_elements()
Sep 06 15:37:14 yield from cls(opts)._iter_elements()
Sep 06 15:37:14 yield from element_accum.flush(ElementCls)
Sep 06 15:37:14 yield from self._element_from_text_or_tail(self.text or "", q, self._ElementCls)

@vladimir-d In the future, I believe we should let the app handle most of it's configuration, environment-wise.

Variables such as RAG_EMBEDDING_MODEL, etc. are all set via the application UI and saved in the config.json file.

Now, for the initial issue of this topic, I've solved it by resetting the embedding model engine.

@vladimir-d

I saw that you've added https://git.cloudron.io/cloudron/openwebui-app/-/blob/main/Dockerfile?ref_type=heads#L46 and https://git.cloudron.io/cloudron/openwebui-app/-/blob/main/Dockerfile?ref_type=heads#L47 in the last package update. However, I've noticed that it breaks RAG in the way that the "Embedding model" in the UI is empty.

I think the solution is to not touch the RAG_EMBEDDING_MODEL or RAG_RERANKING_MODEL variables.

Or is it determined by these settings:

Is there anywhere on an app's settings panel to toggle the app SSO?

e.g.: OpenWebUI has the optionalSso flag in the config. Once the application is installed, is there any way to toggle the SSO from Cloudron's UI. Or is the only way to override the env vars?

@girish Right. Forgot about this, using upstream's HOSTNAME variable to 0.0.0.0 works.

Though, I spoke too fast about the package working, I still have a runtime error after this

Investigating.

@girish

I have successfully packaged Langfuse for Cloudron, available here.

The one thing that does not work half works is startup. When executing node /app/code/langfuse/web/server.js, the app does start and says it listens on port 3000, but healthcheck never resolves/says connection to port 3000 is blocked.

@Lanhild

@girish I am bumping this to know if, with the current Cloudron architecture, this would be feasible?

If so, I think it would be the easiest, least maintenance way to do it, while also keeping the flexibility of custom apps.

Hello,

I'm having an issue regarding the Langfuse app packaging

https://forum.cloudron.io/post/90209

@girish might take a look someday

Reviving this topic as it's been forgotten for a while now. We already have multiple apps with SSH implementations.