Cloudron Forum

Thanks for the quick reaction!!

I am facing an unexpected behaviour. Steps to reproduce:

1. Open the /_admin interface of an installed surfer app
2. Select index.html (or any file)
3. Click on 'Download'

Expected result:
File downloads

Actual result:
Screen shows: This app is currently not responding. Please try refreshing the page in a few minutes.

In the logs I see this error:

Jun 05 04:38:24 get: /app/data/public
Jun 05 04:38:44 2026-06-05T03:38:44Z 
Jun 05 04:38:44 2026-06-05T03:38:44Z 
Jun 05 04:38:44     at FSReqCallback.oncomplete (node:fs:199:5)
Jun 05 04:38:44     at SendStream.emit (node:events:518:28)
Jun 05 04:38:44 Node.js v22.14.0
Jun 05 04:38:44 TypeError: contentDisposition is not a function
Jun 05 04:38:44 ^
Jun 05 04:38:44 at SendStream.send (/app/code/node_modules/send/index.js:508:8)
Jun 05 04:38:44 at SendStream.setHeader (/app/code/node_modules/send/index.js:739:8)
Jun 05 04:38:44 at SendStream.setServMiddlewareHeaders (file:///app/code/server.js:58:75)
Jun 05 04:38:44 at onstat (/app/code/node_modules/send/index.js:615:10)
Jun 05 04:38:44 file:///app/code/server.js:58
Jun 05 04:38:44 if ('download' in res.req.query) res.setHeader('Content-Disposition', contentDisposition(path));
Jun 05 04:38:45 2026-06-05T03:38:45Z 
Jun 05 04:38:45 => Ensure permissions
Jun 05 04:38:45 => Start the server
Jun 05 04:38:45 Base path: /app/data/public
Jun 05 04:38:45 Config file /app/data/.surfer.json not found
Jun 05 04:38:45 Listening on http://localhost:3000
Jun 05 04:38:45 Loading rich mime-types from /usr/share/mime/globs2
Jun 05 04:38:45 Using config file at: /app/data/.surfer.json
Jun 05 04:38:45 Using tokenstore file at: /app/data/tokens.json
Jun 05 04:38:45 Warning: connect.session() MemoryStore is not
Jun 05 04:38:45 designed for a production environment, as it will leak
Jun 05 04:38:45 memory, and will not scale past a single process.

Additional information:

• I tried to restart the app many times
• I recently restored the app from a backup
• the app version is on Surfer 6.6.1. Same behaviour was on 6.6.0
• Downloading the file from the Files Manager works seamlessly

Additional wish: is it possible that releases contain some hint on what changed in a package update? The latest update 6.6.1 didn't contain information. Neither on Github nor directly in the notes. I also checked the notes in https://git.cloudron.io/packages/surfer-app. I found changelog which was maintained until 9.4.7

I guess I have more questions around the integrity check: What is the exact criteria for "green" or "red"?

Here's why I'm asking: After recovering my Cloudron, I noticed that one backup location, an external drive, is still present in the configuration. BUT: that external drive is no longer mounted (or even connected, for that matter). I haven't disabled the location in Cloudron yet.

Now here's the surprising part for me: Cloudron still claims it performed a backup to that location. And when I run the integrity check on that backup, it shows up as green. For a backup that, as far as I can tell, doesn't actually exist on accessible hardware.

I realise I might not fully understand how ext4 mounts work behind the scenes, but I do know that the physical hardware isn't connected. So this makes me wonder: how does the integrity check actually work under the hood? Does it only check metadata or local records, rather than verifying the actual remote files?

Would love to understand this better, because right now a "green" integrity result feels less reliable than I initially thought.

Thanks for bearing with me.

Thanks. Let me add some context:

It is about firefly-iii app. There are 2 of them: firefly-iii-green app and firefly-iii-red app.

But for red the Backup looks like this:

While for green it looks like this (locations are fine, just not on the Screenshot):

Both follow the same retention policy.
Is the integrity checking if all expected backups are available?

There are 2 Backup locations available and supposed to be used, and they are missing similarly in both locations.
When I open the logs via the GUI I only get the last day and the failure event happend before

Hi All,

I love the newly introduced integrity check for Backups! I did it for the backup in question and it turned green. Happy.

Later, unexpected error, I need to restore Cloudron from Backup. Unfortunately, one important backup is missing in the backups. It is missing since the upgrade of Cloudron from 9.1.7 to 9.2.0 but this might be just coincidence.
Because I have another app of the same type which was perfectly fine backed up.

Is the integrity check also checking, if all Apps are backed which are supposed to be backed up?

Thinking about it, that may be a difficult check, but somehow I was expecting it.

I missing 4 Backups for that application. I checked the Backup location storage and I don't see that app there (so UI seems to be correct).

Just for everyone who is trying the same approach:

I strongly discourage to use Ollama self managed next to Cloudron as a prod server.

After updating the GPU drivers, the server is not bootable anymore.

@james said:

demand is not enough for this feature to be put up higher in the prioritisation queue

Thanks.

I am still interested in the technical part:
Would it be possible to route all the traffic of cloudron through a VPN? Probably not, because a server need to be publicly propagated via DNS (IP resolution), right?

So just to understand it right: Is the solution for this feature request to 1) "route all traffic to the cloudron VPN endpoint via a third party VPN?
Technically the "endpoint" would still "Just arrive within the network of the cloudron server", is it?

(I may still have some gaps in understanding the whole VPN/Networking topic)

I'll stick with:

@nebulon said:

But if this is not a production server, this is probably fine.

Added cron job:

0 3 * * 0 curl -fsSL https://ollama.com/install.sh | sh && systemctl restart ollama.service

Hoping for native GPU support in the Cloudron Ollama package at some point

The ollama installation is reachable within the servers network (though not towards the internet).

I was able to connect the IP Address of the Docker Container of Open WebUI, which acts like an Gateway to the host. (Can share more on this if needed).
This port is not publicly available to the internet.

I am just wandering: What would be the best way to update Ollama?
The page recommends just rerunning the install script:

https://docs.ollama.com/faq#how-can-i-upgrade-ollama

Thank you for the detailed response.

I appreciate that you follow the principles which makes a longer life of the cloudron product more probable 🫶

When I read the docs, I understand it is not advised to change any firewall configuration on the server itself. However: How can I access from then Open WebUI App the Ollama instance, running on the host on the relevant port?

I already configured it to bind to 0.0.0.0 for that port, but it seems to be a restriction from the Open WebUI App Container itself.

As you said, it might not be advised for a Prod-Instance. But what would be the least not advised configuration?

Hi, as discussed here and here: using local GPU (if available) with Ollama is critical for getting performance.

Therefore: Is it possible to install Ollama locally on the server (outside of Cloudron for direct GPU Support) and then install the Ollama Cloudron package to continuously update Ollama? Or is there any other way to automatically keep Ollama up to date?

I love the professional level Cloudron reached!

Is there a complexity or a legal issue to not continuing the implementation?

Thank you @james!

And I just realised, that "Last run:" refers to the end of the creation of the backup. Now things match again

I love the improved backup functionalities and more detailed information regarding backups in recent releases, thanks!

What happens between the scheduled start of a backup and the time a backup is created?
In my case: What happened between 23:00 and 3:38 AM?

Let me add the context:

• Backup schedule is set to 23:00 daily. When is that? If I believe "System" --> "Setting" it would be my GMT timezone, because there it says: "UI timestamps always follow the browser’s time zone."

• When I check the system logs, I can see exactly at 23:00 a task, is that the beginning of the backup process?

2026-04-24T23:00:00.009Z locks: write: current locks: {"full_backup_task_8663c238-b4f3-482b-8c4c-a6809dcdeed9":null}
2026-04-24T23:00:00.009Z locks: acquire: full_backup_task_8663c238-b4f3-482b-8c4c-a6809dcdeed9
2026-04-24T23:00:00.018Z tasks: startTask - starting task 7538 with options {"timeout":86400000,"nice":15,"memoryLimit":1024,"oomScoreAdjust":-999}. logs at /home/yellowtent/platformdata/logs/tasks/7538.log
2026-04-24T23:00:00.018Z tasks: updating task 7538 with: {"pending":false}
2026-04-24T23:00:00.018Z shell: tasks: /usr/bin/sudo --non-interactive -E /home/yellowtent/box/src/scripts/starttask.sh 7538 /home/yellowtent/platformdata/logs/tasks/7538.log 15 1024 -999

• However looking at the creation time of the backup in "Backup" --> "Sites" (in Backup "Info") it says: "created at 03:38 AM".
• On the properties of the same backup, I can see "Backup duration: 2h 38m 4s"

That my backup takes almost 3 hours is fine with me. But I would like to understand what is happening before the backup is actually "created".

I checked the system logs but I didn't find much revealing. The Update Schedule is set to 5 AM, and it may interfere with the Backup? Is there a recommendation for doing either the Backup or the update first? I also read that before updates an Backup is taken automatically and I am not sure if that would be skipped if there is a recent backup.

Any hint would be appreciated! And sorry for squeezing in many questions in that post, but it may reveal some context.

If you're as lazy as I am, here is the summary of the brilliant insights from this thread:

1. Enable 'json' in SearXNG (will not make the search interface public):

• Open settings.yml for editing, e.g. via File Manager
• Add json in search under formats
  Example:

formats:
  - html
  - json <-- add this

• Note the Port in of SearXNG

2. Configure OpenWebUI App to use SearXNG as web search:

• In OpenWebUI, go to Admin Settings → Web Search
• Enter URL: Paste the Searxng URL but replace <searx app id> and <searx port> (App id to be found from cloudron dashboard; port as noted above, default port is probably 8888. )

http://<searx app id>:<searx port>/search?q=<query>&language=auto&time_range=&safesearch=0&categories=social+media,map,it,general,science,news&format=json

This bypasses OAuth internally so that OpenWebUI directly accesses SearXNG

An automatically created badge from Cloudron's perspective:

1. App Verification and Registry

   • After the app is reviewed and approved, Cloudron adds it to its verified apps registry, which includes metadata like app ID, name, version, and verified status.

2. Badge Graphic Creation

   • Cloudron prepares a badge image (SVG or PNG) showing "Packaged by Cloudron" or a similar verified label. This badge image is hosted on Cloudron's servers or CDN.

3. Generate Standardized Markdown Snippet

   • Cloudron creates a standardized Markdown snippet that developers can embed into their README or website. The snippet typically looks like this:

   [![Packaged by Cloudron](https://cloudron.example.com/badges/appid.svg)](https://cloudron.example.com/apps/appid)
   

   • Here, the image URL links to the dynamically generated badge image, and the anchor URL links to the app's Cloudron info page. Probably this can be done here, taking comentario as an random example: https://www.cloudron.io/store/app.comentario.cloudronapp.html

4. Badge Hosting and Dynamic Updates

   • The badge image URL is managed by Cloudron, allowing automatic updates if badge styles, wording, or verification states change. All instances where the badge is embedded will reflect updates immediately.

5. Developer/User Integration

   • Cloudron provides the app developer or user with this snippet along with clear instructions to paste it into their GitHub README or other documentation.

6. Automatic Badge Rendering

   • When README files or web pages load, the badge image is fetched from Cloudron's servers and displayed in place, confirming official packaging and build trust visually.

This automated generation and hosting process allows Cloudron to centrally manage trust badges and makes it very easy for app maintainers to add a professional verification mark to their repos without manual image management or styling.

Cloudron has proven to be stable over years.

Therefore, an app selected by cloudron is a kind of "quality seal".

If a (Github) Project had a "packaged by Cloudron" this may have a promotional effect for Cloudron: users may become curious and may end up as customers of Cloudron.

It could start with an low effort "verification" page on a cloudron domain, which shows that the app is actually packed. Even more low effort, the appstore link could be used.
Additionally, it would be good to have a hint in the app packaging doc: "you can create a badge like that:..."

Be integrated into the Cloudron packaging pipeline to automate badge assignment on successful builds and tests. A reliable, persistent badge would act like a "verified publisher" or quality seal widely trusted for years, reassuring users about app stability and Cloudron support.

Happy for any other comments, since I am not that deeply into the publisher game on Github and other platforms.

@girish nice, happy to hear!

Use Case:
When changing the backup provider in Cloudron, there may be existing archived apps. These are stored in the old backup location.

Current Issue:
The existing process requires users to manually move all existing backup files, including those of archived apps, to the new backup storage. There is a major risk that the archived app backups get forgotten or lost because this is not prominently shown. Especially since these backups are "silently" referenced by config files.

Feature Suggestion:
I propose adding an automatic migration feature or, at minimum, a warning/notification system during the backup provider change if archived app backups exist.

Reasoning:
Such a feature would help prevent accidental loss of archived backups, improve usability, and reduce manual work during critical backup provider changes.

This feature could also tie in with the recently discussed Backup integrity - store size and checksum of backups.

Thank you

Element X calls seem to require additional well-known configuration for Matrix RTC for calls.

When I tried to make a call with Element X, I got this error:

Error Code: MISSING_MATRIX_RTC_FOCUS

The issue is discussed here with some workarounds: https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4224

From what I can gather, it seems you need to configure /.well-known/matrix/client or /.well-known/element/element.json with RTC settings, but I'm not sure of the exact setup for Cloudron.

Anyone figured this out?

This discussion might be closely related:
https://forum.cloudron.io/topic/13140/