Cloudron Forum

Hi,
I created a sample R Studio cloudron App as a proof of concept and installed it on my cloudron.
It seems to work quite nicely for a single user

https://github.com/nottheend/r-app

@robi said:

that's what tailscale is for

For encryption of the traffic?

By your post I realised a flaw which can be easily fixed: I changed the post to make ollama listen to the docker bridge only. Should be sufficient if Ollama is only used by cloudron

Strongly not advised to run Ollama locally on a (bare metal) host and Open WebUI with cloudron on a production server.

But if you do, you need to open ports by creating /home/yellowtent/platformdata/firewall/ports.json on the host and add this to open the standard Port for Ollama:

{
  "allowed_tcp_ports": [11434],
  "allowed_udp_ports": []
}

Afterwards restart firewall on the host
sudo systemctl restart cloudron-firewall

Also ensure that ollama listens to the docker bridge to the containers:

In Bash on Host:

# create override
sudo mkdir -p /etc/systemd/system/ollama.service.d

# set Environment Variable
echo '[Service]
Environment="OLLAMA_HOST=172.18.0.1:11434"' | sudo tee /etc/systemd/system/ollama.service.d/override.conf

# Systemd reload and Ollama restart
sudo systemctl daemon-reload
sudo systemctl restart ollama

# verify
ss -tuln | grep 11434

# should now listen on 172.18.0.1 like this:
# tcp LISTEN 0 4096 172.18.0.1:11434 0.0.0.0:*

Then switch to the Open WebUI app, in the settings, set this as the connection:
http://172.18.0.1:11434

Strongly not advise to run Ollama in parallel as described here for Production servers. Updates can break things, in worst case Cloudron but at least Ollama driver incompatibilities.

Update: All apps in error state after Cloudron restore

After restoring Cloudron, all my apps ended up in an error state. I've been digging into the logs and wanted to share what I found in case it's relevant to my setup or helps others.

The key error from the app task log:

Error: ENOENT: no such file or directory, scandir '/mnt/managedbackups/<uuid>/2026-06-10-000001-121/app_<myapp>.<mydomain>_v3.12.2'

So during the restore, Cloudron tries to download the app backup from /mnt/managedbackups/..., but that path doesn't exist. This then causes the task to crash with an AssertionError rather than a clean BoxError, which is probably also worth flagging as a minor bug.

I suspect this is related to my specific setup: I have an external backup location that is no longer mounted (as described earlier in this thread). Cloudron appears to be pointing the restore at that unmounted path.

Resolution that worked for me: Explicitly restoring each app from its most recent backup (rather than letting the automatic restore run) resolved the error state. Ideally, this should be the default behaviour during a Cloudron restore anyway, restoring from the most recent available backup, so this might be worth looking into.

Happy to provide more details if useful.

Update: Day 5 of the mystery backup issue

After 4 days of backups appearing to succeed (no errors in the notification centre), the backup finally failed on day 5 with this error:

Jun 07 01:24:44 BoxError: Not enough disk space for backup. Needed: 47.1GB Available: 45.71GB
    at runBackupUpload (file:///home/yellowtent/box/src/backuptask.js:192:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async uploadAppSnapshot (file:///home/yellowtent/box/src/backuptask.js:359:34)
    at async backupAppWithTag (file:///home/yellowtent/box/src/backuptask.js:382:26)
Jun 07 01:24:44 Exiting with code 0

This is confusing because:
The server's local disk has about 60 GB free
I don't see any backup files actually being written to the server itself
So I'm not sure what disk or location this error is even referring to. I need to investigate further, but I'm posting this in case it helps explain what's been going wrong.

Thread summary so far: There seem to be a few possibly related issues:

• Missing backups: For one app no backups were created from one day onwards. Though a second identical app was unaffected. Only discovered through a Cloudron restauration
• Backup to phantom location: After migrating to a new server, backups to a disconnected external drive kept succeding for 4 days. On day 5, that same location finally failed with a "not enough space" error referencing a disk that doesn't match anything visible on the server.
• Unreliable integrity check: Integrity check succeeded for backups which didn't contain the backup of the app in question (prior to restauration). Even on the backups to the phantom location, the integrity check kept succeeding

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