Cloudron Forum

Surprised to find this here! I've been developing apps for this since 2019. Yesterday, I finally made a Cloudron package for the Armadietto server https://github.com/rosano/armadietto-cloudron

Deleting all executions still didn't move the database down from 500mb, but after running VACUUM FULL execution_data it's now 13mb. I''ll take it.

@joseph it's the execution_data table but I'm not sure how to figure out where the bloat is. the LLM queries are giving me mostly table size but nothing more detailed.

Is it normal for the database to be half a gigabyte?

I have deleted all my executions several times but it doesn't seem to change anything. Also just set export DB_SQLITE_VACUUM_ON_STARTUP=true in /app/data/env.sh, but after restarting it seems to take the same amount of space. When I run SELECT pg_size_pretty(pg_database_size('XXXXX')) it says

pg_size_pretty 
----------------
 594 MB
(1 row)

Is there some data stuck in there that I can see and remove somehow?

@girish Works thank you. I see you already updated the docs!

When I run the export command as per Cloudron docs:

gosu cloudron /app/code/node_modules/.bin/n8n export:credentials --all

I get a bunch of warnings, and then it seems to not find any credentials:

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.
User settings loaded from: /app/data/user/.n8n/config

There is a deprecation related to your environment variables. Please take the recommended actions to update your configuration:
 - N8N_RUNNERS_ENABLED -> Running n8n without task runners is deprecated. Task runners will be turned on by default in a future version. Please set `N8N_RUNNERS_ENABLED=true` to enable task runners now and avoid potential issues in the future. Learn more: https://docs.n8n.io/hosting/configuration/task-runners/

Error exporting credentials. See log messages for details.
No credentials found with specified filters
No credentials found with specified filters

Nothing appears in the logs.

Searching for "No credentials found with specified filters" brings up two topics from the n8n forum (first, second) but I'm not sure if there's something I can use there. Any advice?

I'm running version 1.85.4 / io.n8n.cloudronapp@3.76.0 and recently did a rapid series of upgrades from a 2023 version of n8n.

Ghost recently made a UI for this https://ghost.org/changelog/signup-spam-protection/

@jdaviescoates i didn't know about the lifecycle settings, tried it and it reduced total size by 90% after a few days

@joseph i think this was around the time i switched from aws to backblaze, but i understand it didn't transfer pre-existing backups, only starting fresh, although i could be wrong. will try deleting everything if needed, but so far the previous solution works for me

i gather that there may be some things left beyond the retention policy, but it seems like everything or many/most things are kept forever. some of the dates in /snapshots go back to june/july of last year, over 6 months, and i have maybe only ever made a special manual snapshot or said 'keep this' once or twice. i expect most of these should be deleted by now, do i have the wrong idea?

my backblaze storage bill seems to be increasing every month and i think it's due to cloudron backups. my retention policy is 1 month but it seems like older backups / snapshots are not getting deleted:

i'm confused also looking at this directory as the main folder seems time-based and the subfolder /snapshot seems app-based. this subfolder seems to also have many old versions beyond retention policy.

manually cleaning this up is very cumbersome in backblaze as their checkboxes are not html but pictures or something, so one must literally click all of them. i tried cloudron's 'cleanup backups' which seems to only consider ones within my 1 month retention policy. not sure if it's aware of the files beyond that.

Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-21-040001-622/app_XXXXX_v2.26.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-20-100002-716/app_XXXXX_v2.25.0 keep/discard: preserveSecs
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-20-040001-314/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-19-040001-285/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-18-040001-307/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-17-040001-202/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-16-040001-480/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-15-040001-449/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-14-040001-497/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-13-100004-538/app_XXXXX_v2.24.0 keep/discard: keepWithinSecs
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-13-040001-279/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-12-040001-348/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-11-040001-615/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-10-040001-315/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-09-040001-222/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-08-040001-314/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner cleanupAppBackups: applying retention for appId 1bba7e1f-a2f5-4bd9-b2be-3a60d0153669 retention: {"keepLatest":true,"keepWithinSecs":2592000}

i didn't find any solutions in these related topics:

• Backups before retention policy not being deleted. Bug?
• Scaleway backups retained > retention policy
• Backup retention time

any suggestions?

@nebulon said in "fatal: not a git repository":

Have you tried to use a subfolder in /app/data/ for this? This is where data is kept persistently in Cloudron.

Been using this folder and seems like it has had no issues for a week or two now thanks for clarifying

I have been pulling an external git repository via n8n into the container's /tmp folder and have pushed changes successfully via an active workflow. At some point the workflow fails because of a fatal: not a git repository error and I'm not sure why this happens.

When navigating to the .git folder via the container's web terminal in Cloudron, the data inside looks like this:

total 104
drwxr-xr-x  8 cloudron cloudron  4096 May 14 12:00 .
drwxr-xr-x  7 cloudron cloudron  4096 May 14 12:00 ..
-rw-r--r--  1 cloudron cloudron     5 May 14 07:08 COMMIT_EDITMSG
-rw-r--r--  1 cloudron cloudron    92 May 14 07:08 FETCH_HEAD
-rw-r--r--  1 cloudron cloudron    41 May 14 07:08 ORIG_HEAD
drwxr-xr-x  2 cloudron cloudron  4096 May  3 10:17 branches
-rw-r--r--  1 cloudron cloudron   333 May 14 07:08 config
drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 hooks
-rw-r--r--  1 cloudron cloudron 56770 May 14 07:08 index
drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 info
drwxr-xr-x  3 cloudron cloudron  4096 May  3 10:18 logs
drwxr-xr-x 52 cloudron cloudron  4096 May 14 07:08 objects
drwxr-xr-x  5 cloudron cloudron  4096 May  3 10:18 refs

When cloning/pulling the repo fresh to a new folder, it looks slightly different but I'm not sure what would make it behave differently.

total 116
drwxr-xr-x  8 cloudron cloudron  4096 May 19 07:10 .
drwxr-xr-x  7 cloudron cloudron  4096 May 19 07:10 ..
-rw-r--r--  1 cloudron cloudron     5 May 19 07:10 COMMIT_EDITMSG
-rw-r--r--  1 cloudron cloudron    92 May 19 07:10 FETCH_HEAD
-rw-r--r--  1 cloudron cloudron    23 May 19 07:10 HEAD
-rw-r--r--  1 cloudron cloudron    41 May 19 07:10 ORIG_HEAD
drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 branches
-rw-r--r--  1 cloudron cloudron   333 May 19 07:10 config
-rw-r--r--  1 cloudron cloudron    73 May 19 07:10 description
drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 hooks
-rw-r--r--  1 cloudron cloudron 57218 May 19 07:10 index
drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 info
drwxr-xr-x  3 cloudron cloudron  4096 May 19 07:10 logs
drwxr-xr-x 14 cloudron cloudron  4096 May 19 07:10 objects
-rw-r--r--  1 cloudron cloudron   114 May 19 07:10 packed-refs
drwxr-xr-x  5 cloudron cloudron  4096 May 19 07:10 refs

I found one answer suggesting to copy .git/ORIG_HEAD to .git/HEAD in the broken repo, but that didn't change anything and creates another fatal: detected dubious ownership in repository at XXXXX error.

As it functions for weeks and then suddenly stops, I wonder if it's not an n8n issue and something that happens at the Cloudron or OS level. If there are any guesses about that I would appreciate it.

For now I just manually delete the folder and pull again, but this defeats the purpose of using an automation system; I can also delete as part of the workflow, but wanted to avoid pulling a large amount of data everytime.

@girish said in App Proxy set host header:

@rosano so your plausible is running with a different domain with https and you are proxying from cloudron with another domain name ?

they recommend setting the Host header to plausible.io, for example with nginx. I suppose that's what the App Proxy was doing before the update. I imagine it's not the direction Cloudron is going, in which case a hostable fork of the previous version would be amazing.

@girish said in Cloudron 7.6 released:

app proxy: Host header is set to match the proxy domain instead of the target domain

I think this change broke my App Proxy for Plausible analytics. Would be nice to have the previous behaviour (or fork the older version).

good finds here! will check out the first one's podcast too.

@jdaviescoates thanks for mentioning that, yes i think there are tons of self-hosted solutions out there and i would like to highlight what is possible with one-click (as not everyone can deal with github READMEs). hope to improve easy indie and maybe integrate with apps from that other topic ️

@girish said in Questions about Cloudron Gogs Config File Settings:

It seems the config docs (https://gogs.io/docs/advanced/configuration_cheat_sheet) is now broken.

source still available https://github.com/gogs/docs/blob/b3379ec57b24f2a9a079c0cd9fede86fec6e3a99/en-US/advanced/configuration_cheat_sheet.md

@Kubernetes i'm having difficulty making time to do a PR, feel free to copy

I understand GitHub Pages and Surfer can only point domains at the root, so they host one 'site' at a time. Is there a best practice for hosting multiple static sites on a single Cloudron app? Is it possible to map multiple domains to separate directories in Surfer?

In the topics Best App to Set up Static websites? and Best Choice for Static Website I didn't see something similar.

@nebulon seems also that the swap file was commented out in /etc/fstab (again not sure why/how) so it doesn't persist across restarts, and I guess the script you posted wouldn't affect this.

# /apps.swap  none  swap  sw  0 0

After uncommenting and reboot now, there seems to be a swap file via swapon:

/apps.swap file 3.7G 1.8M   -2

And all apps are running / stopped as expected, nothing hanging thanks for your patience and help .

I wonder what about this could have to do with the latest Cloudron update as I didn't touch anything in the last days and everything seemed to be fine.

@rosano I might have misread #Port 22 as Port 22 as it seems to have been commented out (not sure how/why). Uncommenting and rebooting enables ssh login via ip address again. Computers are hard