Nextcloud is an open-source, self-hostable cloud platform. The server setup can be automated using services.nextcloud. A desktop client is packaged at pkgs.nextcloud-client. The current default by NixOS is nextcloud24 which is also the latest major version available.

Nextcloud is a PHP-based application which requires an HTTP server (services.nextcloud optionally supports services.nginx) and a database (it's recommended to use services.postgresql). A very basic configuration may look like this: { pkgs, ... }: { services.nextcloud = { enable = true; hostName = "nextcloud.tld"; config = { dbtype = "pgsql"; dbuser = "nextcloud"; dbhost = "/run/postgresql"; # nextcloud will add /.s.PGSQL.5432 by itself dbname = "nextcloud"; adminpassFile = "/path/to/admin-pass-file"; adminuser = "root"; }; }; services.postgresql = { enable = true; ensureDatabases = [ "nextcloud" ]; ensureUsers = [ { name = "nextcloud"; ensurePermissions."DATABASE nextcloud" = "ALL PRIVILEGES"; } ]; }; # ensure that postgres is running *before* running the setup systemd.services."nextcloud-setup" = { requires = ["postgresql.service"]; after = ["postgresql.service"]; }; networking.firewall.allowedTCPPorts = [ 80 443 ]; } The hostName option is used internally to configure an HTTP server using PHP-FPM and nginx. The config attribute set is 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. In case the application serves multiple domains (those are checked with $_SERVER['HTTP_HOST']) it's needed to add them to services.nextcloud.config.extraTrustedDomains. Auto updates for Nextcloud apps can be enabled using services.nextcloud.autoUpdateApps.

Unfortunately Nextcloud appears to be very stateful when it comes to managing its own configuration. The config file lives in the home directory of the nextcloud user (by default /var/lib/nextcloud/config/config.php) and is also used to track several states of the application (e.g., whether installed or not). All configuration parameters are also stored in /var/lib/nextcloud/config/override.config.php which is generated by the module and linked from the store to ensure that all values from config.php can be modified by the module. However config.php manages the application's state and shouldn't be touched manually because of that. Don't delete config.php! This file tracks the application's state and a deletion can cause unwanted side-effects! Don't rerun nextcloud-occ maintenance:install! This command tries to install the application and can cause unwanted side-effects! Nextcloud doesn't allow to move more than one major-version forward. E.g., if you're on v16, you cannot upgrade to v18, you need to upgrade to v17 first. This is ensured automatically as long as the stateVersion is declared properly. In that case the oldest version available (one major behind the one from the previous NixOS release) will be selected by default and the module will generate a warning that reminds the user to upgrade to latest Nextcloud after that deploy. This error usually occurs if the initial installation (nextcloud-occ maintenance:install) has failed. After that, the application is not installed, but the upgrade is attempted to be executed. Further context can be found in NixOS/nixpkgs#111175. First of all, it makes sense to find out what went wrong by looking at the logs of the installation via journalctl -u nextcloud-setup and try to fix the underlying issue. If this occurs on an existing setup, this is most likely because the maintenance mode is active. It can be deactivated by running nextcloud-occ maintenance:mode --off. It's advisable though to check the logs first on why the maintenance mode was activated. Only perform the following measures on freshly installed instances! A re-run of the installer can be forced by deleting /var/lib/nextcloud/config/config.php. This is the only time advisable because the fresh install doesn't have any state that can be lost. In case that doesn't help, an entire re-creation can be forced via rm -rf ~nextcloud/.

By default, nginx is used as reverse-proxy for nextcloud. However, it's possible to use e.g. httpd by explicitly disabling nginx using and fixing the settings listen.owner & listen.group in the corresponding phpfpm pool. An exemplary configuration may look like this: { config, lib, pkgs, ... }: { services.nginx.enable = false; services.nextcloud = { enable = true; hostName = "localhost"; /* further, required options */ }; services.phpfpm.pools.nextcloud.settings = { "listen.owner" = config.services.httpd.user; "listen.group" = config.services.httpd.group; }; services.httpd = { enable = true; adminAddr = "webmaster@localhost"; extraModules = [ "proxy_fcgi" ]; virtualHosts."localhost" = { documentRoot = config.services.nextcloud.package; extraConfig = '' <Directory "${config.services.nextcloud.package}"> <FilesMatch "\.php$"> <If "-f %{REQUEST_FILENAME}"> SetHandler "proxy:unix:${config.services.phpfpm.pools.nextcloud.socket}|fcgi://localhost/" </If> </FilesMatch> <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> DirectoryIndex index.php Require all granted Options +FollowSymLinks </Directory> ''; }; }; }

Nextcloud apps are installed statefully through the web interface. Some apps may require extra PHP extensions to be installed. This can be configured with the setting. Alternatively, extra apps can also be declared with the 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. If you want automatic updates it is recommended that you use web interface to install apps.

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-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 shold keep those packages, but mark them as insecure in an expression like this (in <nixpkgs/pkgs/servers/nextcloud/default.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.