Some apps may require extra PHP extensions to be installed.
This can be configured with the [](#opt-services.nextcloud.phpExtraExtensions) setting.

Alternatively, extra apps can also be declared with the [](#opt-services.nextcloud.extraApps) setting.
When using this setting, apps can no longer be managed statefully because this can lead to Nextcloud updating apps
that are managed by Nix:

```nix
{ config, pkgs, ... }: {
  services.nextcloud.extraApps = with config.services.nextcloud.package.packages.apps; [
    inherit user_oidc calendar contacts;
  ];
}
```

Keep in mind that this is essentially a mirror of the apps from the appstore, but managed in
nixpkgs. This is by no means a curated list of apps that receive special testing on each update.

If you want automatic updates it is recommended that you use web interface to install apps.

## Known warnings {#module-services-nextcloud-known-warnings}

### Logreader application only supports "file" log_type {#module-services-nextcloud-warning-logreader}

This is because

* our module writes logs into the journal (`journalctl -t Nextcloud`)
* the Logreader application that allows reading logs in the admin panel is enabled
  by default and requires logs written to a file.

If you want to view logs in the admin panel,
set [](#opt-services.nextcloud.settings.log_type) to "file".

If you prefer logs in the journal, disable the logreader application to shut up the
"info". We can't really do that by default since whether apps are enabled/disabled
is part of the application's state and tracked inside the database.

## Maintainer information {#module-services-nextcloud-maintainer-info}

As stated in the previous paragraph, we must provide a clean upgrade-path for Nextcloud
since it cannot move more than one major version forward on a single upgrade. This chapter
adds some notes how Nextcloud updates should be rolled out in the future.

While minor and patch-level updates are no problem and can be done directly in the
package-expression (and should be backported to supported stable branches after that),
major-releases should be added in a new attribute (e.g. Nextcloud `v19.0.0`
should be available in `nixpkgs` as `pkgs.nextcloud19`).
To provide simple upgrade paths it's generally useful to backport those as well to stable
branches. As long as the package-default isn't altered, this won't break existing setups.
After that, the versioning-warning in the `nextcloud`-module should be
updated to make sure that the
[package](#opt-services.nextcloud.package)-option selects the latest version
on fresh setups.

If major-releases will be abandoned by upstream, we should check first if those are needed
in NixOS for a safe upgrade-path before removing those. In that case we should keep those
packages, but mark them as insecure in an expression like this (in
`<nixpkgs/pkgs/servers/nextcloud/default.nix>`):
```nix
/* ... */
{
  nextcloud17 = generic {
    version = "17.0.x";
    sha256 = "0000000000000000000000000000000000000000000000000000";
    eol = true;
  };
}
```

Ideally we should make sure that it's possible to jump two NixOS versions forward:
i.e. the warnings and the logic in the module should guard a user to upgrade from a
Nextcloud on e.g. 19.09 to a Nextcloud on 20.09.