While a small company we have got to the point of re-evaluating some of the original product choices made at the start of our project and the current CMS has come rather high on the list as the current system does not really provide any SLA or backup strategy. Strapi very quickly became the solution to look at as the replacement as being able to deploy as part of our current product stack gives it the same SLA rating as everything else we are doing and its use of a general relational database resolves the backup strategy issues.
Now the feedback. - I’m not a JS developer and have no real understanding of the JS, JT ecosystem, But that should not be an issue as I am interested in Strapi because of its ability to provide a CMS solution not how it is built. Just in the same way that I do not worry about say MariaDB’s or Redis’s development/build environments.What, I am is someone who deploys CI pipelines and system stacks. For the mentioned MariaDB and Redis solutions, this is easy as they support containerisation as standard. Strapi on the other hand seems to have decided for V4.x that containerisation is an end-user problem.
I can say for certain that it truly is an end-user problem as this end-user has already noted does not know (or care much) about the JS/JT ecosystem. Such a situation seems to restrict Strapi to just JS based teams as most other people doing a quick eval are likely to move on when they find the message “Strapi does not build any official container images.” within the docs.
As it is the EOY I have the time to fight with all this environmental setup and I personally believe that Strapi is worth the work to look at, but I’m not sure as a business you could have made it less friendly to environments that operate around the container deployment model.
P.S. If I do create anything that is sharable I’ll do so as it could help the next person who falls down this rabbit hole, but so far I’ve nothing of value - beyond at least having an understanding about how much I do not know.