@girish Should be opt-in. In cases where a Cloudron server has multiple developers, I don't want my developers to upload code to be built on my server

@girish automatic schema validation by the IDE

@joseph I know about this file. Maybe what I meant wasn't as clear as I thought

What I'd like is to have the readily available JSON schema, online.

For an example, see:

• https://goauthentik.io/blueprints/schema.json
• https://github.com/goauthentik/version

It'd be useful for development purposes to have the CloudronManifest JSON schema published online.

@girish Increasing the task memory did it. Issue solved.

@girish Bumped the memory from the default (?) 1GB to 4GB. Right now, it seems like an app backup worked correctly. My Cloudron has quite a lot of stuff, so an global backup takes longer. I'll report back.

@girish There are no memory usage spikes coinciding with the timestamp of the error. Also, I have the same issue on another Cloudron.

Where should I bump the memory of backup task? Trying it out.

I am using the s3-v4-compat (rsync) backup target, with OVH S3's product. All my system backups exit with a code 70. It seems like backups roll on for a bit, and then exit with said code.

The same happens with app backups, making their updates impossible unless skipping the backup for them.

This issue happened since the upgrade from 8.3.2 to 9.0.10

Logs

Nov 18 23:02:06 box:taskworker Terminated
Nov 18 23:02:06 Exiting with code 70

We can see here with the "Upload finished" lines that the backup seemingly works for a while, but then exits.

Troubleshooting Already Performed

None, I can't control the backup process.

System Details

Cloudron version
9.0.10

Ubuntu version
Ubuntu 22.04.4 LTS Linux 5.15.0-161-generic

Vendor
DigitalOcean

CPU
8 Core "DO-Premium-AMD"

Memory
33.65 GB RAM & 1.03 GB Swap

Fixed with https://github.com/louislam/uptime-kuma/releases/tag/2.0.2.

As suspected, comes from upstream

See https://github.com/louislam/uptime-kuma/issues/6223#issuecomment-3433199988

Shouldn't be a Cloudron issue.

Description

See the issue @ https://github.com/louislam/uptime-kuma/issues/6223

Basically, it's affecting a bunch of my apps on Cloudron as I have multiple of them on the same subdomain as my Uptime Kuma instance.

I don't anything other than Cloudron applications on this subdomain, and none of them have been compromised.

Steps to reproduce

I updated Uptime Kuma to the version 2.0.1, and a few minutes after my subdomain got flagged.

Logs

N/A

Troubleshooting Already Performed

Went and requested a review from Google on their search console. Unfortunately, it's said it can take multiple days or weeks.

I open this topic in the case an issue on Cloudron's side is known.

System Details

Generate Diagnostics Data

v8.3.2 (Ubuntu 22.04.4 LTS)

VendorDigitalOcean
ProductDroplet
CPU8 Core "DO-Premium-AMD"
Memory33.65 GB RAM & 1.03 GB Swap
Uptime17 days

@luckow I don't believe we have a MariaDB addon.

I've opened an issue upstream, as starting the update triggered a false positive alert from Google Chrome on my subdomain:

• https://github.com/louislam/uptime-kuma/issues/6223

@girish yeah of course, it just gave me a good excuse to report some of my findings

Great work on this release as always.

In the API Token creation dialog, the submit button should be disabled if the name input's empty.

"Enable 2FA" button is inactive, at least on the demo. (may be intentional)

Users settings page form does not have a "Save" button to submit changes. That's a bit of a stretch, but some users can be fast to mis-click a switch.

Not a bug, but adding a "Copy details" to copy to clipboard the Cloudron server details may be useful for support.

For the Platorm Updates page, move the update logs to it's own "Update Events" table, instead of a dropdown.

For future reference, a column with the event type in the Event Log table might be a nice addition.