Towards declarative deployment

Describe your Issue

The current setup effectively requires several writable and persistent directories, both for writing configs via entrypoints as well as for managing nextcloud itself. Furthermore, by using the entrypoint dockerism, secret values are unnecessarily exposed to env (apps exposing env via debug endpoints is a favorite ;D ).
Furthermore, apps can be installed from within the application.

This makes deployment at scale a game of luck.

Limitations

• unless we add another persistent, writable mount to the app directory, adding new apps requires new images (which is kinda the point of this exercise, but there is a need for clear communication to the user)
• upgrades possibly require some manual management of the config, but at least we have some support for readonly configs in
  https://docs.nextcloud.com/server/25/admin_manual/configuration_server/config_sample_php_parameters.html#config-is-read-only

Approach

I expect this to play out roughly like this and would try to keep it roughly updated to reflect reality as good as it is possible:

First iteration(s)

1. mount emptyDir to initContainer using same image as deployment at config path
2. let entrypoint do its magic
3. start main container with readOnlyRootFilesystem SecurityContext and command/arg skipping entrypoint and without persistence
4. see what breaks [^1]
5. fix it and try again :-)

Next step (possibly trivial)

1. remove secrets from env
2. see what breaks
3. fix it and try again :-)

Further things

• notes.txt mentioning limitations when readOnlyRootFilesystem and no persistence is set
• see if it is necessary to gate initContainer for this scenario or if it actually also improves non-readonly-scenarios by removing secrets form env
• if applicable make consistency check of used config parameters

Related issues

• https://github.com/nextcloud/helm/issues/531

Start with related issue #531 and the chart’s current entrypoint and initContainer configuration; the issue does not name specific files or tests. Compare the proposed readOnlyRootFilesystem and no-persistence deployment with the existing setup, then use the checklist—especially notes.txt and removing secrets from env—to define and verify a bounded implementation.