Isn't this more of an outsystems platform governance task. We normally create a LifeTime Team with all the demo/sample apps. Then the team will not have the permission to deploy those to other environments.

Hi @Daniël Kuhlmann 

My primary idea was, in the Forge, there are components that demonstrate how to use or extend the functionality of other components.  

These related components, often samples or examples, should be grouped together under the main component's Forge listing instead of being listed separately.

For example, 
The pdfJS Viewer Reactive is the main component. 
Sample PDF Viewer and PDF Viewer From Binary Data components are exactly similar and demonstrates how to use it, perhaps with a small addition like dynamically generating URLs.  

Instead of listing Sample PDF Viewer and PDF Viewer From Binary Data components  separately, they should be linked or nested within the pdfJS Viewer Reactive Forge page.  

This consolidated approach improves discoverability, allowing users exploring the main component to easily find relevant examples and extensions.  It also avoids the need for hierarchical component structures. 

Agreed on @Daniël Kuhlmann Comment.
usually Tech will deploy the code with necessary permission. It will be always checked by which module/application need to be deployed.

Got it @Neha Agrawal, thanks for the additional clarification

@Rahul Sahu, 

Of course, before any deployment, the architects and tech leads will thoroughly review the code and remove any unnecessary application layers. 

Our main concern with Forge Components is ensuring that any related demos and samples should be connected to the actual, viable solution instead of being treated as an individual forge component.