@fanvyr fair point, and I'll hold my hands up on both counts.
On the MongoDB thing: you're right, I was working from stale information. Strapi dropped NoSQL support a while back. Corrected.
On the read-only filesystem critique: I think I framed this wrong. After sitting with your reply and looking at this more carefully, the Content-Type Builder being unavailable in production isn't a Cloudron constraint being imposed on Strapi — it's Strapi's own documented stance. They explicitly discourage using the Content-Type Builder in production regardless of your hosting environment, because schema changes belong in version control and should be deployed deliberately. Cloudron's immutable container model is actually aligned with that philosophy, not fighting it.
The real workflow is:
Develop and modify content types locally in dev mode
Schema files land in src/api/ in your Git repo
Rebuild your Docker image with the updated schemas baked in
cloudron update --image to deploy
That's not a workaround, it's just treating your CMS schema like code, which is the right call when business logic depends on it.
Where I think the "unsuitable" framing has some merit is for a narrower use case: someone who wants a fully self-contained admin experience where non-technical editors can modify the data model directly in the browser in production, with no local dev environment involved. For that specific workflow, Directus (schema-in-database) is genuinely a better fit on Cloudron. But that's a workflow preference, not a fundamental incompatibility.
So to revise my original position: Strapi on Cloudron is well-suited for teams who treat their CMS like code, schemas in Git, changes shipped via image builds, proper dev/staging/prod cycle. If that matches how you work, it's a great fit. If you want point-and-click schema changes in production with no local tooling, look at Directus.
Thanks for the correction!
