have you tried to invoke the start script from your dockerfile instead of invoking the JAR directly?

Is this AEM Cloud Service? In that case you cannot bypass the CDN from an external endpoint (for security reasons), and therefor you are unable to connect to the origin endpoints (which the CDN itself is connecting to).

This does not work, the cq:page nodetype is pretty much locked down what additional properties you can add to it. cq:lastReplicated is always set on the jcr:content node. (Plus: on a publish instance it is not reliable, because this property is only set on author after the replication has completed....

There is no way to bypass the CDN and dispatcher layer, as the only publicly documented way to access AEM CS is via the hostname which is served via the CDN.

I understand your question in a way, that only a certain usergroup should be able to add/edit the content of a component on a page (it's not about the access to the component definition itself). In that case working with access control on the component definition (somewhere below /apps) won't help y...

I agree with Daniel, I have seen a number of projects, where over the years a few hundreds components were created (and used), ending up with 15 different TextImage components. That's a maintenance nightmare and there are many reasons why projects ended up there (that's a topic for a different day)....

I think that needs a deeper investigation, please raise a support ticket.Please also mention a rough time when you saw it working the last time.

Have you worked through https://experienceleague.adobe.com/en/docs/experience-manager-65/content/security/closed-user-groups#authorization-restricting-read-access already?

I would also recommend to use renderconditions, but instead of rolling your own rendercondition in the first place, you can use the ootb renderconditions, see https://developer.adobe.com/experience-manager/reference-materials/6-5/granite-ui/api/jcr_root/libs/granite/ui/docs/server/rendercondition.ht...