Code change:
are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>

Related discussion:
text: Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do.