At the moment the workaround is to do this is, is inside the start script.
REDISCLI_AUTH="${CLOUDRON_REDIS_PASSWORD}" redis-cli -h "${CLOUDRON_REDIS_HOST}" -p "${CLOUDRON_REDIS_PORT}" CONFIG SET maxmemory-policy allkeys-lru
But this way is fragil. When the service is restarted for some reason, the default policy is set.
Now when the maxmen is reached by the app -> 500, because it is not allowed to write anymore.
Oh sorry. 
The doc is even not up2date. In latest version (9.1.5) the response is (unconfigured):
{"allowlist":[],"blocklist":[]}
Depending how old your onlyoffice is:
PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql
PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev710.sql
In case the db schema upgrade is already up2date, the output looks like:
root@78d36e9e-8352-4cd1-a356-42fa5e22702f:/app/code# PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql
psql:/var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql:15: NOTICE: column created_at already exists.
psql:/var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql:15: NOTICE: column password already exists.
DO
Based on the git history, cloudron only did the schema migration for 720.sql.
The Dockerfile should fail on docker build in case there new sql files and apply the sql files. atm rerunning the sql files does not exit with exit code > 0. But I believe it is better to store somewhere which sql-files was already applied, just for case sql file would break something on a rerun.
At the moment cloudron counts only the usage of /app/data, but not the dumps of the latest backup/rest.
The dumps are part of "Everything else (Ubuntu, etc) 123.0 GB".
Feature-Request:
Display the sum of everything in /home/yellowtent/appsdata/1234/, not just the sum of (/home/yellowtent/appsdata/1234/data).
Or extend the current display. appname 1GB data / 1GB misc (Latest db dump etc.).
This can happen in this step:
=> PREV_DOLIBARR_VERSION=`php /app/code/htdocs/install/get-version.php`
Log:
2026-02-07T13:35:00Z ==> Starting Dolibarr
2026-02-07T13:35:03Z #0 /app/code/htdocs/core/class/conf.class.php(561): DoliDBMysqli->query()
2026-02-07T13:35:03Z #1 /app/code/htdocs/install/get-version.php(28): Conf->setValues()
2026-02-07T13:35:03Z #2 {main}
2026-02-07T13:35:03Z PHP Fatal error: Uncaught Error: Call to a member function query() on false in /app/code/htdocs/core/db/mysqli.class.php:355
A shell script with set -e stops when If an error occurs. The script does not have an error handling in such cases, therefore the lock file is still in /tmp.
With error handling
trap 'echo "Houston we have problem"; [[ -f /tmp/install.lock ]] && mv /tmp/install.lock /app/data/dolibarr/install.lock; exit 1' ERR
Relevant part:
//
for await (const line of rl) {
if (!line) continue;
debug(`Current line: ${line}`);
const cacheEntry = JSON.parse(line);
// ...
}
I added the debug. And yes, line is just invalid json.
Log:
// ...
Mar 14 21:19:59 box:syncer Current line: {"path":"data/storage/app/myfile.txt","stat":{"mtime":1723408804000,"size":26604,"mode":33188}}
Mar 14 21:19:59 box:syncer Current line: {"path":"data/storage/app/myfile2
Mar 14 21:19:59 box:backupupload upload completed. error: SyntaxError: Unterminated string in JSON at position 83 (line 1 column 84) at JSON.parse (<anonymous>) at Object.finalize (file:///home/yellowtent/box/src/syncer.js:184:33) at process.processTicksAndRejections (node:internal/process/task_queues:103:5) at async sync (file:///home/yellowtent/box/src/backupformat/rsync.js:211:5) at async Object.upload (file:///home/yellowtent/box/src/backupformat/rsync.js:309:12) at async Object.upload (file:///home/yellowtent/box/src/backuptask.js:101:37)
More context:
root@5fc22e33-ac60-4f99-bbe3-2ca8cf9e12c7:/# ls app/data/storage/app/attachment/6/0/1/myfile2_ foo.pdf
'app/data/storage/app/attachment/6/0/1/myfile2_'$'\342\200\251''foo.pdf'
root@5fc22e33-ac60-4f99-bbe3-2ca8cf9e12c7:/# file app/data/storage/app/attachment/6/0/1/myfile2 _foo.pdf
app/data/storage/app/attachment/6/0/1/myfile2\051foo.pdf: PDF document, version 1.5 (zip deflate encoded)
Roll back for GitLab is a no-go thing. Let's hope that Gitlab does not do something in future update release which would prevent using it.
When configured rsync the database does not benefit of rsync (not really) therefore it should always be compress to save storage/speed up the backup process.
I believe the current implementation of the API does not support paging.
Zone not found: Hetzner DNS error 200
{
"meta": {
"pagination": {
"last_page": 2,
"next_page": 2,
"page": 1,
"per_page": 25,
"previous_page": null,
"total_entries": 29
}
},
"zones": ["25x zones"]
}
The fix is not released.
You could back up the app with another backup destination which does not uses rsync or patch the file manually with https://git.cloudron.io/platform/box/-/commit/6e0dc24ecae47ba3175ce1574a86c6724fbc98aa.diff
The link behind the ?.
Old: https://docs.cloudron.io/certificates/#certificate-providers
New: https://docs.cloudron.io/domains#certificates
When I run sudo systemctl --failed I see that the service is not running. (Ubuntu: 24.04.4 LTS (Noble Numbat))
UNIT LOAD ACTIVE SUB DESCRIPTION
ā unbound-resolvconf.service loaded failed failed Unbound asyncronous resolvconf update helper
Logs:
Apr 27 18:05:19 my.example.org systemd[1]: Started unbound-resolvconf.service - Unbound asyncronous resolvconf update helper.
Apr 27 18:05:19 my.example.org resolvconf[870]: Dropped protocol specifier '.unbound' from 'lo.unbound'. Using 'lo' (ifindex=1).
Apr 27 18:05:19 my.example.org resolvconf[870]: No DNS servers specified, refusing operation.
Apr 27 18:05:19 my.example.org systemd[1]: unbound-resolvconf.service: Main process exited, code=exited, status=1/FAILURE
Apr 27 18:05:19 my.example.org systemd[1]: unbound-resolvconf.service: Failed with result 'exit-code'.
I found a related PR https://github.com/NLnetLabs/unbound-manual/pull/55, which is part of
I am not an expert at the area. But I believe cloudron does not need this service.
I disabled and mask it in one cloudron instance, until now everything seems to working and sudo systemctl --failed is clean again.
sudo systemctl mask unbound-resolvconf.service
sudo systemctl disable --now unbound-resolvconf.service
Is this service required for Cloudron, or is it safe to keep masked?
This is configured in https://example.org/#/email-settings.
Doc https://docs.cloudron.io/email#address-blocklist
Fyi: The frontend uses the same API, so you should see a request to this endpoint.
Please change the title to "Compress database dump when ..."
Warning when navigating inside the backend after upgrade to v19.
Database 'main' is using PostgreSQL 16.11, but this version of GitLab requires PostgreSQL 17. Please upgrade your environment to a supported PostgreSQL version. See database requirements for details.
https://docs.gitlab.com/install/requirements/#database
I wonder that is possible to start the app, perhaps GitLab does not block when configured an external DB.
Use case 1: In one instance I see multiple started, but not finished backup cleaner jobs with the same log message.
box:taskworker Starting task 3335. Logs are at /home/yellowtent/platformdata/logs/tasks/3335.log
box:backupcleaner run: retention is {"keepWithinSecs":604800}
box:shell mounts: mountpoint -q -- /mnt/cloudronbackup
box:database Connection 422 error: Packets out of order. Got: 0 Expected: 7 PROTOCOL_PACKETS_OUT_OF_ORDER
Use case 2: In another instance other error, but also started but not finished.
retention is
{"keepDaily":3,"keepWeekly":4,"keepMonthly":6}
...
2024-11-29T03:30:29.878Z box:tasks update 21410: {"message":"Removing app backup (b178e0a6-ffe8-4ede-976c-c382f998a50d): app_b178e0a6-ffe8-4ede-976c-c382f998a50d_v3.55.0_97d403e1"}
2024-11-29T03:30:30.451Z box:tasks update 21410: {"message":"2024-11-14-030035-138/app_n8n.example.org_v3.55.0: Removing directory /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138/app_n8n.example.org_v3.55.0"}
2024-11-29T03:30:30.523Z box:tasks update 21410: {"message":"Removing directory /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138/app_n8n.example.org_v3.55.0"}
2024-11-29T03:30:30.524Z box:shell filesystem: rm -rf /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138/app_n8n.example.org_v3.55.0
2024-11-29T03:38:00.508Z box:backupcleaner removeBackup: unable to prune backup directory /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138: ENOTEMPTY: directory not empty, rmdir '/mnt/cloudronbackup/my_example_org/2024-11-14-030035-138'
2024-11-29T03:38:00.521Z box:backupcleaner removeBackup: removed 2024-11-14-030035-138/app_n8n.example.org_v3.55.0
...
Use case 2: The Jobs are finished now as a error. Some magic or the there is a hidden timeout.
I would like to see this bugfix already in 8.3.x. Please <3.
Cloudron-Version: 9.1.5
Cli-Version: 8.0.1
Node-Version: v20.20.2
Full error message:
file:///usr/lib/node_modules/cloudron/src/actions.js:1507
stdout.resume(); // drain readable side of Duplex/Transform streams so autoDestroy emits 'close'
^
TypeError: stdout.resume is not a function
at TLSSocket.<anonymous> (file:///usr/lib/node_modules/cloudron/src/actions.js:1507:32)
at TLSSocket.emit (node:events:536:35)
at endReadableNT (node:internal/streams/readable:1698:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
I do not speak so much JavaScript, therefore I ask my computer (claude ;-)), so do not trust 100% the cause/fix.
cloudron pull --app <location> /tmp/somefile.gz .
Any pull of a single file (remote path without trailing /) crashes with:
TypeError: stdout.resume is not a function
at TLSSocket.<anonymous> (file:///usr/lib/node_modules/cloudron/src/actions.js:1507:32)
Root cause
In src/actions.js, runExecSession is called with a fs.createWriteStream as stdout. When the socket closes, the code does:
if (stdout !== process.stdout && typeof stdout.end === 'function') {
stdout.on('close', () => resolve());
stdout.end();
stdout.resume(); // drain readable side of Duplex/Transform streams
}
The comment acknowledges that resume() is only meaningful on Duplex/Transform streams. However, the guard condition only checks for stdout.end, which is true for any Writable ā including fs.WriteStream. Since fs.WriteStream is a plain Writable and not a Duplex, it has no resume() method.
Fix
Add a check before calling resume():
if (typeof stdout.resume === 'function') stdout.resume();
Workaround
Downgrade to v7.1.2.
Checked this on a cloudron which created 3 month ago. resolvconf not installed, but unbound-resolvconf.service.
Since Cloudron v10 it is possible to set the redis maxmemoryPolicy via manifest.
We use redis for caching and set the allkeys-lru maxmemoryPolicy, but today since cloudron updated to 10.0.4, it seems the policy was reset to his default maxmemory-policy. The app could not caching anymore, because it reached the maxmemory, which can not happen with the policy.