F
Hi @djxx,
that sounds like a slight misconception about the httpPort attribute. The value basically tells Cloudron that when it receives a request for that app on port 443, so e.g. you open https://yourapp.cloudron.demo, then this request will be proxied to the port specified in the attribute.
If your app requires port 5280 to be open, then rather https://docs.cloudron.io/packaging/manifest/#tcpports is the value you are looking for.
@andreasdueren thanks for the step by step. I did not have time to really dive into this from my side, but this seems to have done the trick.
This made me look into my chatwoot instance and it also looks to be broken. Need to do some further investigation, but a rollback of the app results in an error.
https://forum.cloudron.io/topic/13412/8.3.0-postgres-upgrade-failure
I ran into the same issue. For me all postgres databases were empty and the fix was to restore these specific apps from a backup from before the upgrade.
Yes, I had the same issue and posted in https://forum.cloudron.io/topic/13412/8.3.0-postgres-upgrade-failure about it. Looking at the Nextcloud database I came to the realisation that all Postgres Databases were lost during the upgrade, but a restore from before brought these apps back.
I have to say that every now and then magic links are neat and useful. Going the oidc route I think Cloudron has already done quite some steps to get rid of passwords for the login.
But please don't make me rely on a java monster to achieve this. For the usual installation it just takes away too many resources.
The tragedy of the commons all over again...
I guess it can be seen as a benefit if your software is not complete open source, which will force people trying to sell your software in public tenders to at least get in contact with you to negotiate their purchasing prices. But even there are exceptions.
I have to say that I mostly scanned the text and did not read it completely, but the feeling I get from it (looking at the criteria suggestions in the appendix) is that this will limit the overall amount of oss being proposed in public tenders. Because having to prove that you are a regular contributor of code or have active influence on the project seems like a high step to reach.
Open source is not one, open source is a bricklayer house made out of a thousands of small bricks.
PS: and if you don't want others to change your code and make changes closed source, why don't you use a software license that would forbid this?
I could not let go if it, so I kept digging a bit. I had previously reset the memory limit back to its default, but bumped it to 6gb now for another test. This time the restore of Nextcloud went through. So now everything is operational again (and I also cleaned out some apps that had errors, but I was not using anyways anymore).
To get back to a working state I needed to restore each up using a postgres database to the state from before the upgrade to 8.3.0. Else the app would have no data in their databases (Mastodon users and toots gone, Matrix rooms gone, for example).
The things you notice when you take a closer look at everything running on your Cloudron. The Minio logo is mostly transparent, but has two white spots in the upper left corner.
I first thought my monitor was dirty and then was confused when the dirt moved when scrolling.
Original logo as displayed on cloudron: 
Ah, it seems the restore is failing because of memory limits.
2025-03-11T09:52:46.768Z box:shell
<--- Last few GCs --->
[190237:0x38f032d0] 122923 ms: Scavenge 250.0 (257.7) -> 249.5 (258.0) MB, 1.20 / 0.00 ms (average mu = 0.249, current mu = 0.130) allocation failure;
[190237:0x38f032d0] 122934 ms: Scavenge 250.2 (258.0) -> 249.7 (258.2) MB, 1.16 / 0.00 ms (average mu = 0.249, current mu = 0.130) allocation failure;
[190237:0x38f032d0] 123102 ms: Mark-Compact 250.3 (258.2) -> 248.4 (258.2) MB, 159.94 / 0.00 ms (average mu = 0.304, current mu = 0.366) task; scavenge might not succe
ed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
2025-03-11T09:52:46.772Z box:shell 1: 0xb8ced1 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
2025-03-11T09:52:46.773Z box:shell 2: 0xf06460 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
2025-03-11T09:52:46.773Z box:shell 3: 0xf06747 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
2025-03-11T09:52:46.774Z box:shell 4: 0x11182e5 [node]
2025-03-11T09:52:46.774Z box:shell 5: 0x1118874 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
2025-03-11T09:52:46.775Z box:shell 6: 0x112f764 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char
const*) [node]
2025-03-11T09:52:46.775Z box:shell 7: 0x112ff7c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFl
ags) [node]
2025-03-11T09:52:46.776Z box:shell 8: 0x1106281 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::Allocatio
nOrigin, v8::internal::AllocationAlignment) [node]
2025-03-11T09:52:46.777Z box:shell 9: 0x1107415 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::Allocati
onOrigin, v8::internal::AllocationAlignment) [node]
2025-03-11T09:52:46.778Z box:shell 10: 0x10e4a66 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal
::AllocationOrigin) [node]
2025-03-11T09:52:46.779Z box:shell 11: 0x1540896 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
2025-03-11T09:52:46.779Z box:shell 12: 0x1979ef6 [node]
2025-03-11T09:52:46.926Z box:shell Finished with result: core-dump
Main processes terminated with: code=dumped/status=ABRT
Service runtime: 2min 3.531s
CPU time consumed: 2min 51.745s
2025-03-11T09:52:46.927Z box:shell Service box-task-19660 failed to run
2025-03-11T09:52:46.932Z box:shell Service box-task-19660 finished with exit code 3
2025-03-11T09:52:46.935Z box:shell tasks: /usr/bin/sudo -S -E /home/yellowtent/box/src/scripts/starttask.sh 19660 /home/yellowtent/platformdata/logs/dd5f0f98-2b81-495d-88
28-9c967128304a/apptask.log 15 400 0 errored BoxError: tasks exited with code 3 signal null
at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19)
at ChildProcess.emit (node:events:519:28)
at ChildProcess._handle.onexit (node:internal/child_process:294:12) {
reason: 'Shell Error',
details: {},
code: 3,
signal: null
}
2025-03-11T09:52:46.935Z box:tasks startTask: 19660 completed with code 3
I will need to continue checking and maybe doing a manual postgres store later this evening.
Ah, I just found the error. For whatever reason the 2fa got disabled for my user and therefore the cli app did not ask for it. My password manager always filled out the 2fa field so I was unaware that it had actually been deactivated.
I just checked on my desktop system. And here I do have the same behaviour, but with a more recent node version. (i moved .cloudron.json away before running this).
$ cloudron login my.demo.cloudron.io
Username: cloudron
Password:
Login successful.
felix@clifford:~$ cloudron list
Id Location Manifest Id State
------------------------------------ ------------------------- -------------------------------------- -------
0bd45384-26e9-4c06-a1b2-f8ba55529841 demo.cloudron.io org.apache.guacamole.cloudronapp@2.3.0 running
30c49bfe-8adf-4644-a030-fd95f00f5632 peertube.demo.cloudron.io org.joinpeertube.cloudronapp@4.0.2 running
3113d78a-0e94-4d82-95eb-9ecb7a44185e n8n.demo.cloudron.io io.n8n.cloudronapp@3.72.0 running
3d397748-d96d-45bc-b6fe-ddb597e4c853 itt.demo.cloudron.io tech.ittools.cloudron@1.6.1 running
918eac5f-7b25-4487-b0e6-4e99768996ee mtest.demo.cloudron.io com.github.bitwardenrs@1.19.2 running
felix@clifford:~$ cloudron logs
Could not determine app. Use --app to specify the app
felix@clifford:~$ cloudron logs --app demo.cloudron.io
/home/linuxbrew/.linuxbrew/lib/node_modules/cloudron/src/actions.js:970
req.on('response', function (response) {
^
TypeError: req.on is not a function
at Command.logs (/home/linuxbrew/.linuxbrew/lib/node_modules/cloudron/src/actions.js:970:13)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
Node.js v23.7.0
Logging in into my own Cloudron still skips the 2fa step. Yes, the system just got upgraded to 8.3.0.
I just installed the Cloudron cli on a new system (Ubuntu noble with npm from the distributions repository) and I was surprised that it did not ask for my totp.
$ cloudron login my.cloudron
Username: felix
Password:
Login successful.
$ cloudron --version
5.14.0
edit. It seems the cli is broken on the system in more ways:
$ cloudron logs --app video.cloudron
/usr/local/lib/node_modules/cloudron/src/actions.js:970
req.on('response', function (response) {
^
TypeError: req.on is not a function
at Command.logs (/usr/local/lib/node_modules/cloudron/src/actions.js:970:13)
Node.js v18.19.1
For me apps that are using the Postgres database all ran into an error after the upgrade. The task that failed was for example An error occurred during the operation: : Error setting up postgresql. Status code: 500 message: the database system is in recovery mode. Some apps such as chatwoot were happy just retrying the task, while peertube still complains about the oidc plugin and nextcloud about oc_appconfig missing.
Still investigating on my end.
Edit: when it comes to Nextcloud it seems all tables were dropped. Unfortunately the restore of the Nextcloud app fails with Task Error: Task 19659 crashed with code 3. The last I see in the web log viewer is it reaching 65% of file restore.
@SansGuidon I guess I should have completely reread your initial post before dropping the link 
Maybe he meant https://docs.cloudron.io/networking/#blocklist instead
@humptydumpty said in At home self-hosted Cloudron - migrate to larger main disk. Advice and sanity check my thoughts.:
Having a GUI is preferable.
I would also have recommended dd 
Something I havent used in ages, but i think would satisfy the gui criteria is https://clonezilla.org/
@ei8fdb said in At home self-hosted Cloudron - migrate to larger main disk. Advice and sanity check my thoughts.:
Install same <?> Ubuntu OS and Cloudron version?
If you clone the disk from your old nvme to the new one (and afterwards extend your partitions) they you can spare yourself the work with the fresh install and redoing your mount configuration.
If i remember correctly in the past the json response from the app store included the total install count of the app, but that has been removed meanwhile as it seems.
But total numbers probably expose too much behind the scenes knowledge anyways.
Another manufacturer with an app store concept used to publish their "top 10 app" once per quarter before they abandoned their market place. maybe that could be an interesting (and hopefully not too repetitive) marketing piece?
@girish said in Solr and Adding a New Mail Domain:
When the mail service is restart [..] the email apps [..] are also restarted
Without having explicitly tested this, but I think there is a possibility for clients getting confused when clients briefly see:
This app is currently not responding. Please try refreshing the page in a few minutes.
While still a http return of 200 is given (which does seem to be the case here). But on the other hand I also don't think that this specifically could trigger password prompt, since whatever the client sends as basic auth here would just be accepted by the server and not rejected.
@crazybrad said in Solr and Adding a New Mail Domain:
Any advice based on your Kopano knowledge with EAS?
I'm not overly familiar with Sogo, but you mentioned desktop so I am guessing you are referring to Microsoft Outlook on the desktop. ActiveSync was never really made for desktop applications and therefore potentially syncing gigabytes from many folders (coupled with very large request/response sizes) can put quite some load on the server and in my experience also leads to issues on the client sooner or later. That is why we have abandoned that approach and switched to an implementation of mapi over http for this client in our latest product. The sogo documentation already lists some of the limitations of that approach as well.
On point that is made here is problematic from an implementation standpoint:
ActiveSync clients keep connections open for a while. Each connection will grab a hold on a sogod process so you will need a lot of processes to handle many clients. Make sure you tune your SOGo server when having lots of ActiveSync clients.
Blocking a worker for an idling open request will waste a lot of resources. We had the same issue in the past, but for us it was just a php connection being held open. For better scalability we are now parking these connections in a separate "proxy" to free resources in our actual server. But this is something that Sogo would need to implement (as in develop such a proxy and hand the connections off) and nothing that you as the user can influence. Generally speaking as long as you have set your client to use "push" there is nothing you can do to lessen the load on the server.