Feature Requests

Strapi Cloud already allows configuring a Base directory for a branch (e.g. strapi/ inside a monorepo). This correctly defines where the Strapi application is located for the build, but auto-deploys are still triggered on every commit to the branch, even if no files inside the base directory were changed. In monorepo setups (Nx, Turborepo, Yarn/pnpm workspaces), this leads to: – Unnecessary Strapi Cloud deployments when changes only affect other apps or libraries in the repository. – Difficulty integrating Strapi Cloud into a unified release process where CI decides which apps need to be deployed. – The need to choose between auto-deploying on every commit, or disabling auto-deploy and having no supported way to trigger strapi deploy from CI (because the CLI requires interactive login). Requested enhancements: 1) Path-aware auto-deploy: When a Base directory is configured, only trigger auto-deploys if commits modify files under that directory. 2) CI-friendly, non-interactive deployment: Provide a CI/service token or similar mechanism (e.g. STRAPI_CLOUD_TOKEN) so that strapi deploy can be executed from CI/CD pipelines without a browser-based login flow (like Vercel, Netlify, Amplify). These changes would make Strapi Cloud behave predictably in monorepos, reduce redundant deployments, and allow modern CI/CD pipelines (Nx/Turborepo/other monorepo tools) to control when Strapi is actually deployed.

Setting the stage of the review via API would be a game changer for automated processes/reviews. I have a use case where the editor uploads a file and I would do OCR on it to pre-populate other fields. Unfortunately, i'm not able to get the list of available stages for that workflow, so to be able to advance it.

It was able to implement the nesting dynamic route. The current version I am using in my project is "@strapi/strapi": "5.27.0". Via Front end is not possibile to do, and, after my changes attached, if I try to save, the Content-Type Builder section receives a generic error, and I need to edit every part of the sections manually. Is there already an issue connected to this business case? Thanks

Update the current EditForm to include a rotate button that works during resizing/cropping image.

I believe it would greatly improve the user experience if we can add a "folder-like" grouping function to content types (single type and collection type), so that if you have a lot of content types (for example if you have like 50 webpages, you will have like 50 single types), it really makes a lot more sense to have groups. For now users can only mitigate this by using some naming conventions, but I doubt if this is an elegant solution.

There is no filter by status ('Published' or 'Draft'). It is difficult for the author to track on the status of the entries without filtering the entries on the status in the List View Page. It would be nice to address this and add this feature. Thank You.

Currently typescript compilation is a bottleneck when the app is trying to start, taking upto 16seconds in my case. The bun runtime promises and seems to provide faster startup times. We can provide a way to ignore typescript compilation when the runtime is bun. The current implementation looks for the presence of tsconfig.json to identify if the project is a typescript project and dynamically changes the outdir.

It would be amazing if the image editor in the Media Library allowed for the selection of a focal point of the image so devs can crop responsive images accordingly. See for instance: https://docs.imgix.com/tutorials/focal-point-cropping

It feels like this is a completely missing feature of the filter feature. Found it surprising that this feature didn't exist. You can filter by createdAt, updatedAt but not state (draft/published).

If non licalized content type has a relation to a localized content type. Then in non-localized contet, it's possible to select only relation to a default locale. It should allow to choose a relation to a content with any locale.