How to Package and Deploy Strapi v5 as a Custom App on Cloudron
-
@timconsidine This one was largely Claude Opus 4.6 extended
The latest updates in Cloudron really helped.
The latest updates in Cloudron really helped.
Presumably especially the Skills?
-
The latest updates in Cloudron really helped.
Presumably especially the Skills?
Strapi: Strapi (Node.js headless CMS) loves the latest Node 24, MongoDB 8, and Redis. The custom build feature makes it dead simple to package Strapi + custom plugins, database migrations, and even a Svelte/Astro frontend in one app. You get Cloudron’s one-click updates, backups (including DB), SSO, domains, and isolation — while still running the very latest Strapi version with your own custom admin UI or API extensions. Community Strapi packages have existed in the past; now they’re officially encouraged and auto-updating.
Main Improvements & Benefits in 9.1 / 9.1.2
These focus on making Cloudron far more developer-friendly for custom and modern web apps:Custom app build & deploy (biggest new feature): You can now git clone any app package repository and run cloudron install directly on your server. Cloudron builds the Docker image on-the-fly from source. Your app’s full source code is included in backups and can be rebuilt/restored automatically. No more manual Docker packaging or third-party tools needed.
Community Apps: Anyone can publish apps via a simple CloudronVersions.json file hosted anywhere (GitHub, GitLab, etc.). Install them with one click from any URL, and Cloudron tracks the upstream repo for automatic updates. This opens up the ecosystem massively — no waiting for official Cloudron approval.
Updated runtimes:
Node.js 24.x (huge for modern JS/TS stacks)
MongoDB 8
Redis 8.4UX & operational wins:
Much better progress reporting (percentage complete + elapsed/estimated time) for backups and app installs.
Improved notifications view, event log, and backup verification UI.
Faster backups (up to 100× in some cases, carried over from v9).Security:
Native Passkey support (works with YubiKey, Bitwarden, browser passkeys, etc.).
ACME ARI for better certificate management.Overall benefits: Easier self-hosting of custom apps, faster iteration, automatic updates/backups/SSL/domains/isolation, and dramatically reduced maintenance compared to raw Docker or VPS setups.
-
️ Critical limitation: 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.
Directus (also available on Cloudron) stores its schema in the database rather than the filesystem, making it fully compatible with Cloudron's immutable package model. -
Strapi: Strapi (Node.js headless CMS) loves the latest Node 24, MongoDB 8, and Redis. The custom build feature makes it dead simple to package Strapi + custom plugins, database migrations, and even a Svelte/Astro frontend in one app. You get Cloudron’s one-click updates, backups (including DB), SSO, domains, and isolation — while still running the very latest Strapi version with your own custom admin UI or API extensions. Community Strapi packages have existed in the past; now they’re officially encouraged and auto-updating.
Main Improvements & Benefits in 9.1 / 9.1.2
These focus on making Cloudron far more developer-friendly for custom and modern web apps:Custom app build & deploy (biggest new feature): You can now git clone any app package repository and run cloudron install directly on your server. Cloudron builds the Docker image on-the-fly from source. Your app’s full source code is included in backups and can be rebuilt/restored automatically. No more manual Docker packaging or third-party tools needed.
Community Apps: Anyone can publish apps via a simple CloudronVersions.json file hosted anywhere (GitHub, GitLab, etc.). Install them with one click from any URL, and Cloudron tracks the upstream repo for automatic updates. This opens up the ecosystem massively — no waiting for official Cloudron approval.
Updated runtimes:
Node.js 24.x (huge for modern JS/TS stacks)
MongoDB 8
Redis 8.4UX & operational wins:
Much better progress reporting (percentage complete + elapsed/estimated time) for backups and app installs.
Improved notifications view, event log, and backup verification UI.
Faster backups (up to 100× in some cases, carried over from v9).Security:
Native Passkey support (works with YubiKey, Bitwarden, browser passkeys, etc.).
ACME ARI for better certificate management.Overall benefits: Easier self-hosting of custom apps, faster iteration, automatic updates/backups/SSL/domains/isolation, and dramatically reduced maintenance compared to raw Docker or VPS setups.
Strapi: Strapi (Node.js headless CMS) loves the latest Node 24, MongoDB 8, and Redis.
Not true. Strapi dropped NoSQL DB Support. Link.
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.) -
Strapi: Strapi (Node.js headless CMS) loves the latest Node 24, MongoDB 8, and Redis.
Not true. Strapi dropped NoSQL DB Support. Link.
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.)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.
-
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.
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.
-
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 -
Strapi: Strapi (Node.js headless CMS) loves the latest Node 24, MongoDB 8, and Redis.
Not true. Strapi dropped NoSQL DB Support. Link.
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.)@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 deployThat'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! -
@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 deployThat'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!@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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login