Hello Cloudron Support Team,
Thank you for integrating Beszel into Cloudron! I’m now trying to install the Beszel agent on my Cloudron server using the binary installer, but the agent stays offline. Could you please advise:
Are there any firewall rules or network settings I need to adjust to allow the agent to connect?
Is there a recommended installation method for Cloudron that differs from the standard binary approach?
I appreciate your help!
@joseph You can go ahead and close this thread.
Yes, I did install the same version as my backup, but unfortunately, that didn’t help.
In the end, I had to reinstall the server completely and upgrade to 8.3.1 again.
It’s clear that backups need to be properly saved.
Thanks for your help anyway.
Thanks for the quick reply.
I performed several service restarts, and finally — after about 12 hours — the upgrade completed successfully.
Memory isn't an issue in my case. I’ve allocated the maximum allowed RAM for all services. The server has 128 GB of RAM and 32 CPU cores, so the system resources are more than sufficient.
That said, it wasn’t immediately clear that everything was progressing normally — it looked like the process was stuck for a long time.
I apologize if some of my earlier comments came off the wrong way — I was just genuinely frustrated, as this was the first time an upgrade took so long in production, with no way to stop or roll back.
Also, having to migrate to a new server after the first failed attempt added to the pressure.
I've made my conclusions — and for the next production Cloudron server, I’m seriously considering switching to a different pricing plan with support included.
If any of my previous posts seemed too harsh or inappropriate in tone, please feel free to delete them — no hard feelings.
Thanks again for the clarification and support.
@mazarian didn't understand you.
Yes, I did update to 8.3.1 — and I’m highlighting the issues that happen after the upgrade.
This is a community forum, and I’m not contacting support asking anyone to urgently fix my server.
I handled everything myself, including a full recovery from backups and getting all apps back online manually.
I posted here to share the issue, specifically that apps were unavailable for hours, and to suggest that maybe the upgrade scripts could be improved or at least include warnings for such cases.
Yes, I’m already considering moving to a paid support plan — that’s clear.
But I fail to see how faster support would help with the fact that an upgrade process locks up all apps, shows endless Redis errors, and triggers long PostgreSQL operations.
This forum exists exactly for this kind of discussion.
If moderators feel my messages are out of place — they’re free to delete them.
But please don’t jump in if you don’t understand the issue. I’m sharing a real-world problem that any production user could face — and I believe it’s important to speak up.
Another question:
Why am I seeing so many Redis errors after the PostgreSQL upgrade?
Here’s a snippet from the logs:
2025-03-24T22:06:01.057Z box:services Waiting for redis-39d103ac-9d2b-44f1-9e38-63605e9da5d0
2025-03-24T22:06:01.059Z box:services Attempt 1 failed. Will retry: Network error waiting for redis-39d103ac-9d2b-44f1-9e38-63605e9da5d0: connect ECONNREFUSED 172.18.0.21:3000
2025-03-24T22:06:16.211Z box:services startRedis: stopping and deleting previous redis container redis-3a4d573e-8262-4609-b56e-ecb2837a53d7
2025-03-24T22:06:16.631Z box:services startRedis: starting redis container redis-3a4d573e-8262-4609-b56e-ecb2837a53d7
2025-03-24T22:06:16.634Z box:shell services: /bin/bash -c docker run --restart=always -d --name=redis-3a4d573e-8262-4609-b56e-ecb2837a53d7
And yet, in the Cloudron dashboard, all Redis services appear as running.
This is insane — I rebooted the server, and the PostgreSQL upgrade process restarted again.
And still, all my apps remain stuck in the state:
Restarting - Waiting for platform to initialize
It’s a complete deadlock, and I have no visibility or control over what’s happening.
One more note:
I strongly recommend everyone to use Cloudron in real-case scenarios — not just for testing.
For example: try running n8n + NocoDB (both available in your App Marketplace) with 300–500 GB of data.
Let’s imagine a realistic use case:
Now try upgrading Cloudron in that environment…
It would be interesting to see how the platform handles it. 
If you’d like, I’d be happy to help create real-world test cases like these — they might help uncover issues before production users hit them.
Also, just to emphasize how critical this is:
It’s crazy — I’ve been sitting here for 6 hours, watching all my apps stuck in
Restarting - Waiting for platform to initialize
Meanwhile, the upgrade script is running endlessly, doing some kind of background database operations.
Then come the Redis errors, and even after restarting the server, the system starts upgrading the PostgreSQL database again.
This feels like a never-ending loop with no control or visibility into what’s happening. For production environments, this is just not acceptable.
I really hope that people who haven’t upgraded yet will read this post and maybe think twice — or better, go find two days to enjoy life instead of debugging this mess.
@joseph, @girish — let me help clarify some real-world use cases your clients face:
We use NocoDB, Directus, n8n, and similar tools with large datasets.
Cloudron is an excellent hosting platform and fully capable of being used in production environments.
However, it’s concerning to see how the update logic currently works — for example, during a version upgrade, the script upgrades the database and freezes all other apps.
Imagine a client running NocoDB with 500 GB of data — even if it's the only app, this can be a serious issue.
You've added powerful applications to the Cloudron App Store that are clearly meant for serious, data-heavy production use. But this makes it even more critical to improve update and recovery mechanisms.
Please consider implementing the following improvements:
I’m even willing to pay for such improvements as an optional feature or extension.
I’ve already invested a lot of time trying to resolve these issues, and I’m still stuck — any help or solution would be highly appreciated.
After a second attempt to upgrade to version 8.3.1, I'm still encountering serious issues.
I’ve already spent a significant amount of time creating a new server and restoring from backups. Once again, during the upgrade to 8.3.1, all apps with PostgreSQL are stuck in the state:
Restarting - Waiting for platform to initialize
Checking the box logs, I see repeated PostgreSQL backup and export operations, for example:
2025-03-24T20:10:48.541Z box:services Backing up postgresql
2025-03-24T20:10:49.129Z box:services pipeRequestToFile: connected with status code 200
2025-03-24T20:10:49.152Z box:services exportDatabase: Exporting addon postgresql of app 36863357-62c8-4750-9f7e-a20040bc1d15
...
2025-03-24T20:11:34.186Z box:services exportDatabase: Exporting addon postgresql of app 42f73f7a-f67b-4690-871a-f422c56bf4fd
I'm unsure if I should just wait — and if so, how long?
Why is there no way to stop this process or manually recover my apps?
From a user experience perspective, this feels unfriendly and very frustrating.
Has anyone successfully upgraded to 8.3.1?
At this point, I’ve already spent over a week trying to make it work.
@joseph thanks for help! yes it helped. app imported , app in "running" state. but for some reason can't start app. it's n8n app.
error:
=> Setting permissions
Mar 21 10:03:56 => Starting N8N
Mar 21 10:03:57 Last session crashed
Mar 21 10:03:57 Permissions 0644 for n8n settings file /app/data/user/.n8n/config are too wide. This is ignored for now, but in the future n8n will attempt to change the permissions automatically. To automatically enforce correct permissions now set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true (recommended), or turn this check off set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false.
Mar 21 10:03:57 User settings loaded from: /app/data/user/.n8n/config
Mar 21 10:04:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.229:5678
Mar 21 10:04:07 Initializing n8n process
Mar 21 10:04:08 Migration "AddWebhookId1611144599516" failed, error: column "webhookId" of relation "webhook_entity" already exists
Mar 21 10:04:08 Migrations in progress, please do NOT stop the process.
Mar 21 10:04:08 Starting migration AddWebhookId1611144599516
Mar 21 10:04:08 There was an error running database migrations
Mar 21 10:04:08 column "webhookId" of relation "webhook_entity" already exists
Mar 21 10:04:08 n8n ready on 0.0.0.0, port 5678
Mar 21 10:04:10 => Healtheck error: Error: read ECONNRESET
Mar 21 10:04:10 => Ensure directories
Mar 21 10:04:10 => Loading configuration
Mar 21 10:04:10 => Setting permissions
Mar 21 10:04:10 => Starting N8N
Mar 21 10:04:11 Permissions 0644 for n8n settings file /app/data/user/.n8n/config are too wide. This is ignored for now, but in the future n8n will attempt to change the permissions automatically. To automatically enforce correct permissions now set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true (recommended), or turn this check off set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false.
Mar 21 10:04:11 User settings loaded from: /app/data/user/.n8n/config
Mar 21 10:04:12 Last session crashed
Mar 21 10:04:12 BoxError: Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/46322ece-e828-4c6c-a4a2-e8391f2e395f/postgresqldump to http://172.18.30.2:3000/databases/db46322ecee8284c6ca4a2e8391f2e395f/restore?access_token=b34f5810ef1bca9de0e9ae8f2cf579dc8c6dee98de19c0e678aab0133d9393324478b02763b955a2caf9eca347a812de339642143c9ddf5525e51081d31d190f7c7d170d3e5e88ec4a4a2986ad047d7dd93c121440852b7c63d5d3ba43f03304855d21ffe00ab24a4ad217c13e3d9181771d595d2d04e9556cc6a7c2ab3cecdb&username=user46322ecee8284c6ca4a2e8391f2e395f: status 500 complete false
Mar 21 10:04:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.229:5678
Mar 21 10:04:22 Initializing n8n process
Mar 21 10:04:22 n8n ready on 0.0.0.0, port 5678
Mar 21 10:04:22 Migrations in progress, please do NOT stop the process.
Mar 21 10:04:22 Starting migration AddWebhookId1611144599516
Mar 21 10:04:22 Migration "AddWebhookId1611144599516" failed, error: column "webhookId" of relation "webhook_entity" already exists
Mar 21 10:04:22 There was an error running database migrations
Mar 21 10:04:22 column "webhookId" of relation "webhook_entity" already exists
Mar 21 10:04:24 => Ensure directories
Mar 21 10:04:24 => Loading configuration
Mar 21 10:04:24 => Setting permissions
Mar 21 10:04:25 => Starting N8N
Mar 21 10:04:25 Permissions 0644 for n8n settings file /app/data/user/.n8n/config are too wide. This is ignored for now, but in the future n8n will attempt to change the permissions automatically. To automatically enforce correct permissions now set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true (recommended), or turn this check off set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false.
Mar 21 10:04:25 User settings loaded from: /app/data/user/.n8n/config
Mar 21 10:04:26 Last session crashed
@joseph , thanks for tutorial!
I did this , but in the end of import I have error:
External Error: Error loading fsmetadata.json:ENOENT: no such file or directory, open '/mnt/cloudron-volume-2/appsdata/46322ece-e828-4c6c-a4a2-e8391f2e395f/fsmetadata.json'
please let me know if this can be fixed
@joseph ,
I've set up a new server and am in the process of restoring from AWS backups. However, I noticed that automatic backups were disabled for some apps, and the only available backups on AWS are quite old.
I have already switched Cloudron’s DNS to the new server. The old server is still active, and I would like to manually migrate specific apps from it to the new server.
Could you provide a step-by-step guide or tutorial on how to manually transfer these apps while preserving their data and configurations?
Thanks in advance for your help!
Best regards,
Ivan.
@joseph , but I have separate volumes of apps(
please is it possible just update current to 8.3 ? I am wondering, I just need to ignore state of apps.
@joseph , Ok, I will write. just interesting if I can stop all apps by one command and make hard update to 8.3?
@joseph , ok, how to resolve this?
is there are way to make hard update of cloudron? ignoring state of apps
@joseph
"The confusion is that if everything is reverted to 8.2.4, that message should never appear"
yes it's interesting. can't understand wha's going on. I just can told you that I have setup like in your docs here:
https://docs.cloudron.io/storage/#default-data-directory
My platformdata , boxdata, appsdata on seperate volume.
I did restore from hetzner backup of main server disk.
@joseph , my data is moved.
I did it several month ago according docs:
https://docs.cloudron.io/storage/#default-data-directory
it's symlinks. you may check:
root@tc-cloudron:/home/yellowtent# ls -lah
total 28K
drwxr-xr-x 4 yellowtent yellowtent 4.0K Feb 6 11:04 .
drwxr-xr-x 6 root root 4.0K Mar 9 2023 ..
lrwxrwxrwx 1 root root 34 Jan 23 00:58 appsdata -> /mnt/tc-cloudron-volume-1/appsdata
-rw-r--r-- 1 yellowtent yellowtent 220 Jan 6 2022 .bash_logout
-rw-r--r-- 1 yellowtent yellowtent 3.7K Jan 6 2022 .bashrc
drwxr-xr-x 8 yellowtent yellowtent 4.0K Feb 2 10:16 box
lrwxrwxrwx 1 root root 33 Jan 23 00:58 boxdata -> /mnt/tc-cloudron-volume-1/boxdata
-rw-r--r-- 1 yellowtent yellowtent 0 Dec 11 2022 .cloud-locale-test.skip
drwx------ 2 yellowtent yellowtent 4.0K Apr 2 2023 .gnupg
lrwxrwxrwx 1 root root 38 Jan 23 01:05 platformdata -> /mnt/tc-cloudron-volume-1/platformdata
-rw-r--r-- 1 yellowtent yellowtent 807 Jan 6 2022 .profile
@joseph , please check output:
root@tc-cloudron:~# cat /home/yellowtent/box/VERSION
8.2.4
root@tc-cloudron:~# cat /home/yellowtent/platformdata/VERSION
8.2.4root@tc-cloudron:~#
backups stored on AWS.
but I can't understand should I do manual restore of every app?) I have around 100 apps.
can I just make hard update of cloudron?
and I can't make restore of apps due to status "Restarting - Waiting for platform to initialize"
all apps in this state now.
@joseph , I can't do anything now, and can't restores apps from backups.
all apps in state "Restarting - Waiting for platform to initialize"
due to redis issue.
How to force fix this? really need help 8 hours of outage