Cloudron Forum

@LoudLemur i'm working a lot with strapi, developed plugins and more So yeah, it def. has its limitations or "weird edges", but in general i'm happy with it as backend for my apps. And like you said, strapi is more for serious business depending logic (with more effort in CI/CD) while directus is more for non-technical and quick-deploy setups.

To be honest, the only tricky part (in general for cloudron apps) are the env vars. When updating an app, always make sure to FIRST set the new env vars (it only works when the app is running... and if the app depends on a var to start, well.... ) and THEN update the container. I'm using Buddy selfhosted as my CI/CD and build a template which i can just duplicate for every cloudron app.
Push to git -> build image -> push image -> set env vars on cloudron -> update cloudron

@fbartels said:

@fanvyr said:

For a Cloudron app that means building a new image, push it and update your app. No magic. (And for sure no complicated strapi transfer workaround needed....).

Maybe what is then needed is a kind of example or started git project that one can fork and add their own personal website on top of this fork. Maybe add example github/gitea actions to it.

Why that, the original post here covers it pretty much with Step 5 (building the image and pushing) and Step 6 (instead of install use update...)

Important: Use (Docker) Container Versioning for your custom strapi-cloudron-app.

@LoudLemur said:

Strapi: Strapi (Node.js headless CMS) loves the latest Node 24, MongoDB 8, and Redis.

Not true. Strapi dropped NoSQL DB Support. Link.

@LoudLemur said:

The Cloudron Strapi package runs with a read-only /app/code filesystem. This means the Content-Type Builder is permanently unusable in production mode, and there is no supported way to deploy custom content types to it. Schema files cannot be written via transfer, push, or direct filesystem access.
The only partial workaround is: build content types locally in dev mode → use strapi transfer --exclude files to push to production. However this only works if the schemas already exist on the destination, which they cannot, making it a circular problem.

This is not "because of running in read-only filesystem" - its by design. Link.

To manage Collections or Content-Types, you always have to build in local dev setup and push the changes. For a Cloudron app that means building a new image, push it and update your app. No magic. (And for sure no complicated strapi transfer workaround needed....).

Which, to be honest, IS ALWAYS a good idea, because you're messing with the Database... Even worse, a prod one in that case (Like Directus...)

So, (just my opinion...) i'd rather use Strapi with a dev / staging cycle and have clear easy migrations instead of a "heart operation" with directus... sure you can develop your directus upgrade locally, but then the CI/CD turns into hell...
(This is of course assuming you don't mean some small self-project or no business logic depends on it. If not - Directus may actually a good choice.)

Yeah, the skins do help a little, but they all.... well suck to be honest haha.
Bringing back somekind of built-in darkmode / toggle would be amazing, but depends on NodeBB - i get it. A quick research did not show any current discussions there... only that its "available in harmony" which is not really true though...

ah, you can select a different personal skin, there are about 4 kind-of darky skins.. forum/user/[username]/settings

how? saw its built in with harmony nodeBB theme, but... hm
can you use it?! How to activate?

hey guys,

is there no option to build in or activate a darkmode here in the forum?
Thought most of us are more nightly active... cannot keep the tab open for long.. quite a downer in terms of bug report writing

@robi said:

@girish Can a migrations check be added to run until none remain, which hopefully evades the stuck condition too?

this would actually be a good addition to the CLI toolset...
@girish @james

Hey @max
nice to hear, thanks. And even better that your migration directly solved it

https://forum.cloudron.io/topic/14767/error-accessing-dashboard-after-update-from-8.x-to-9.x-read-this

@nebulon very understandable. Thought more from the perspective that you are a more smaller team, it would add faster iterations. And i think nuxt is very much for the long run here, but the argument of dependencies and updates is very valid.. Did you guys consider making the dashboard "pluginable" for theming or even more open-source so others can help? But while writing this i have to admit, that this will also add a lot of work...
Given the current situation i think you guys deliver a great product. Hope you are also here for the long run.

Let me know if i can help somehow, beside of late night fix reports ( :

@girish said in Cloudron 9.0.15 - upgrade experience / questions:

@fanvyr it's intentional to ship the source code. We want users to have a copy of not just the build but also the source code and the build tools. If one knows how, they can trivially change the source files and build dist. Personally, I would love to see this in all the stuff I use I like this kind of freedom, to be able to inspect, change and learn.

Love it. Will play a little around with it.

@girish
Just looked at your dashboard vue.js project.... man u guys are wasting a lot of time by not using nuxt..

edit: uff, total chaos in that project xD sorry... (and you're shipping dev files as well, just FYI... like... EVERYTHING....)

Thanks. Originally didn't want to publish it, but it got late... u know how it is

Ah, and by the way.. found another issue in the 20250724141339-backups-add-siteId.js migration, related to backupSites and something about theOneFormat and transfers... but would have to dig into it again... don't want to right now to be honest

So, this is just a quick post because i'm still crying (but maybe it helps someone)

After (automatically) having my cloudron instance upgraded, i couldn't access the dashboard anymore, but (most of) the apps where still working. Also no CLI / remote access.

---

Edit and TL'DR:
Sorry, but it was very late.
TL'DR: the "addons" object in (every) cloudron app's cloudronManifest.json (especially custom, self made ones) is NOT OPTIONAL because of a bug in a migration file. You need to manually modify the apps in the mysql apps table. See below.

---

Okay, history:

The SSH troubleshoot command cloudron-support --troubleshoot revealed

root@xx /var/backups # cloudron-support --troubleshoot
Vendor: Gigabyte Technology Co., Ltd. Product: xx
Linux: xx
Ubuntu: noble 24.04
Processor: xx
BIOS Intel(R) Core(TM) i9xx
RAM: 131811572KB
Disk: /dev/md2        2.5T
[OK]	node version is correct
[OK]	IPv6 is enabled and public IPv6 address is working
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	nginx is running
[OK]	dashboard cert is valid
[FAIL]	-> Could not load dashboard website with loopback check <- 
root@xx /var/backups # 

It was NOT a DNS or IP issue. (Cloudflare as DNS provider with no changes, all IP's/DNS's resolved correctly)
Checking the NGINX's logs revealed, the upstream connection failed to the /openid path:

Dec 16 16:10:16 xx nginx[146916]: 2025/12/16 16:10:16 [error] 146916#146916: *2528 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.16.72, server: my.xx.com, request: "GET /openid/.well-known[xx]>

Cool... (well not)...

The "dashboard" nginx configuration file for that location:

location ~ ^/openid/ {
    proxy_pass http://127.0.0.1:3005;
}

okay, so port 3005... nothing running there (ss -ltnp | grep 3005)

hm, okay... the box.js should handle the start of the matching process, the logs revealed (crash loop):
(sudo tail -n 200 /home/yellowtent/platformdata/logs/box.log) :

2025-12-16T19:55:41.714Z box:server ==========================================
2025-12-16T19:55:41.715Z box:server            Cloudron 9.0.13  
2025-12-16T19:55:41.715Z box:server ==========================================
2025-12-16T19:55:41.715Z box:platform initialize: start platform
2025-12-16T19:55:41.716Z box:tasks stopAllTasks: 0 tasks are running. sending abort signal
2025-12-16T19:55:41.716Z box:shell tasks: /usr/bin/sudo --non-interactive /home/yellowtent/box/src/scripts/stoptask.sh all
2025-12-16T19:55:41.756Z box:locks releaseAll: all locks released
2025-12-16T19:55:41.758Z box:reverseproxy writeDashboardConfig: writing dashboard config for xxx.com
2025-12-16T19:55:41.763Z box:shell reverseproxy: /usr/bin/sudo --non-interactive /home/yellowtent/box/src/scripts/restartservice.sh nginx
2025-12-16T19:55:42.026Z box:updater notifyBoxUpdate: update finished from 8.3.2 to 9.0.13
2025-12-16T19:55:42.027Z Error starting servers
2025-12-16T19:55:42.027Z BoxError: Unknown column 'completed' in 'field list'
2025-12-16T19:55:42.027Z     at Object.query (/home/yellowtent/box/src/database.js:96:22)
2025-12-16T19:55:42.027Z     at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
2025-12-16T19:55:42.027Z     at async list (/home/yellowtent/box/src/tasks.js:163:21)
2025-12-16T19:55:42.027Z     at async Object.setCompletedByType (/home/yellowtent/box/src/tasks.js:172:21)

Okeee... Looks like a failed update... to be precise a failed migration...
"Unknown column "completed" in "field list" -> at tasks (lets check migrations related to tasks table) (/home/yellowtent/box/migrations)

voila -> 20250716130216-tasks-add-completed.js looks matching...

but that means, the migration did not run successfully...
lets check which ones we're missing:

cd /home/yellowtent/box

HOME=/home/yellowtent BOX_ENV=cloudron \
DATABASE_URL=mysql://root:password@127.0.0.1/box \
node_modules/.bin/db-migrate check

if your result IS NOT AN EMPTY ARRAY... (well, you have unapplied migrations).

Simplest: try to apply them. But lets kill the crash loop process first: sudo pkill -f /home/yellowtent/box/box.js

Okay:

cd /home/yellowtent/box

HOME=/home/yellowtent BOX_ENV=cloudron \
DATABASE_URL=mysql://root:password@127.0.0.1/box \
node_modules/.bin/db-migrate up

(well obviously they failed...).

mine was:

[ERROR] AssertionError [ERR_ASSERTION]: ifError got unwanted exception: Cannot read properties of undefined (reading 'oidc')
    at /home/yellowtent/box/node_modules/db-migrate/lib/commands/on-complete.js:15:14
    at tryCatcher (/home/yellowtent/box/node_modules/bluebird/js/release/util.js:16:23)
    at Promise.successAdapter (/home/yellowtent/box/node_modules/bluebird/js/release/nodeify.js:22:30)
    at Promise._settlePromise (/home/yellowtent/box/node_modules/bluebird/js/release/promise.js:601:21)
    at Promise._settlePromiseCtx (/home/yellowtent/box/node_modules/bluebird/js/release/promise.js:641:10)
    at _drainQueueStep (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:97:12)
    at _drainQueue (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:102:5)
    at Async.drainQueues [as _onImmediate] (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:15:14)
    at process.processImmediate (node:internal/timers:485:21)
    at exports.up (/home/yellowtent/box/migrations/20250713133718-oidcClients-separate-ids-for-oidc-proxyauth.js:9:29)

-> Cannot read properties of undefined (reading 'oidc')

looking at the migration itself:

use strict';

exports.up = async function (db) {
    const allApps = await db.runSql('SELECT * FROM apps');

    for (const app of allApps) {
        const manifest = JSON.parse(app.manifestJson);
        // assume apps only have one of them
        if (manifest.addons.oidc) {
            await db.runSql('UPDATE oidcClients SET id=? WHERE id=?', [ ${app.id}-oidc, app.id ]);
        } else {
            await db.runSql('UPDATE oidcClients SET id=? WHERE id=?', [ ${app.id}-proxyauth, app.id ]);
        }
    }
};

exports.down = async function (db) {
};

AHA. They are trying to access the addons object in the cloudronManifest.json
Thats weird. Should be better escaped...
if (manifest.addons.oidc) { <- results in an error if addons is not defined.
(@cloudron: fix the migration with if (manifest.addons?.oidc))

Well... i obviously have apps installed which do not have addons object in the manifest, as not needed AND DECLARED AS OPTIONAL!!!

Lets check which ones (i have A LOT of custom apps..).
To check which ones we need to access the mysql db (as we're talking about migrations...), because we cannot remotely uninstall apps, as the CLI is not working (no auth process, which we found out) (By the way: the packaged cloudron-support on-side cli is really useless...)

lets connect to the mysql... how.. uff...
-> Ah, the start.sh script (/home/yellowtent/box/setup/start.sh) reveals an access, we can login with

sudo mysql -u root -ppassword

(yes, double "P")

maan, where are they... looking for the mysql cheatsheets.. (no guarantee for correct sql-syntax in this drunklatenightcryingbugfixsessionblogpost)

Okay. First, we know from the start.sh script the DB is called box, lets use it:

use box;

okay, we have an apps table (show tables;)... describing it reveals a manifestJson column, nice. (describe apps;)
So, lets get all apps and just check which manifestJson does not contain addons at all:

select id from apps where manifestJson is not null and manifestJson not like '%"addons"%';

okay... got 5 apps... well i did them quite some time ago... interestingly was one of them already un-installed ?! weird.

as i don't want to touch the migrations (would be a way easier fix, but not really longterm-stable, think backups, server-transfer etc), we just temporarily add an empty addons object to the manifest, so the migration-script "can try to find the oidc section. (whats it for anyway? need to research that...)

lets globally add the addons object if not present, do not want to do it row-by-row (which should usually be done in a live prod system with checks etc...)
(tired in the morning? try deleting a table in the prod DB, that will get you awake )

sql query to add an empty object for all rows where it doesnt exist(well, the word addons, but should be failsave, right?):

update apps set manifestJson = JSON_SET(manifestJson, '$.addons', JSON_OBJECT()) where manifestJson is not null and manifestJson not like '%"addons"%';

puh. okay. lets re-run the migrations:

cd /home/yellowtent/box

HOME=/home/yellowtent BOX_ENV=cloudron \
DATABASE_URL=mysql://root:password@127.0.0.1/box \
node_modules/.bin/db-migrate up

if you get no error ( i had another issue, but was my error (deleted a remote backupSite, don't ask....))
we verify that really all migrations are applied now:

node_modules/.bin/db-migrate check

should result in something like Migrations to run: []

NICE. Okay, let a final sudo reboot correctly start all systems again.

-> Done. (uih, the UI changed...)

(how to mark a topic/post as resolved here?! )

FUCK did you save my day Can't believe there is still no official option for that...

any updates here? would love to have strapi here as well...

hey, sorry for the late response.
nah, i had a different issue with that.

i wanted to migrate to a new server. Don't know the exact server versions right now.
But in general it was like that:
My old server was on something like 8.1.x. The fresh installed server was on 8.2.1. (or similar)
So, to make a backup and import it, it says i have to match the server version. So i tried to update to old server, but i got only the option to update to a NEWER version then the fresh installed one, i think 8.2.3, which also was a "beta". so no chance, to only update to the matching stable version to the new server...
i ended up re-installing the fresh server to an older version, and enabled auto-update.

i understand to not make the effort for subscribing to beta releases, but at least let us select to which version to update... would be nice
Otherweise, the migration worked pretty nice. i would point out a few things (DNS stuff), but in general - good work!

i'm running 6 instances of invoice ninja with cloudron, each setup at a different time (well, over time more..)
i had problems with ALL, created before a specific time (don't know when right now).
But yeah, changing the phantomjs var from false to true solved it for me. Weirdly enough, the DB vars are double in the configs... why?
Thinking about setting up fresh instances and export/import all the clients... man....
But thanks for the advices here. (don't get the emoji ones, but at least we're having fun while noone appreciate our work )
have a good one!