- Hydra has gained a massive performance improvement due to [some database schema changes](https://github.com/NixOS/hydra/pull/710) by adding several IDs and better indexing. However, it's necessary to upgrade Hydra in multiple steps:

  - At first, an older version of Hydra needs to be deployed which adds those (nullable) columns. When having set [stateVersion ](options.html#opt-system.stateVersion) to a value older than `20.03`, this package will be selected by default from the module when upgrading. Otherwise, the package can be deployed using the following config:

    ```nix
    { pkgs, ... }:
    {
      services.hydra.package = pkgs.hydra-migration;
    }
    ```

- Automatically fill the newly added ID columns on the server by running the following command:

  ```ShellSession
  $ hydra-backfill-ids
  ```
  ::: {.warning}
  Please note that this process can take a while depending on your database-size!
  :::

- Deploy a newer version of Hydra to activate the DB optimizations. This can be done by using hydra-unstable. This package already includes [flake-support](https://github.com/nixos/rfcs/pull/49) and is therefore compiled against pkgs.nixFlakes.

  ::: {.warning}
  If your [stateVersion](options.html#opt-system.stateVersion) is set to `20.03` or greater, hydra-unstable will be used automatically! This will break your setup if you didn't run the migration.
  :::

  Please note that Hydra is currently not available with nixStable as this doesn't compile anymore.

  ::: {.warning}
  pkgs.hydra has been removed to ensure a graceful database-migration using the dedicated package-attributes. If you still have pkgs.hydra defined in e.g. an overlay, an assertion error will be thrown. To circumvent this, you need to set [services.hydra.package](options.html#opt-services.hydra.package) to pkgs.hydra explicitly and make sure you know what you're doing!
  :::

- The TokuDB storage engine will be disabled in mariadb 10.5. It is recommended to switch to RocksDB. See also [TokuDB](https://mariadb.com/kb/en/tokudb/).

## Other Notable Changes {#sec-release-20.03-notable-changes}

- SD images are now compressed by default using `bzip2`.

- The nginx web server previously started its master process as root privileged, then ran worker processes as a less privileged identity user (the `nginx` user). This was changed to start all of nginx as a less privileged user (defined by `services.nginx.user` and `services.nginx.group`). As a consequence, all files that are needed for nginx to run (included configuration fragments, SSL certificates and keys, etc.) must now be readable by this less privileged user/group.

  To continue to use the old approach, you can configure:

  ```nix
  {
    services.nginx.appendConfig =
      let
        cfg = config.services.nginx;
      in
      "user ${cfg.user} ${cfg.group};";
    systemd.services.nginx.serviceConfig.User = lib.mkForce "root";
  }
  ```

- OpenSSH has been upgraded from 7.9 to 8.1, improving security and adding features but with potential incompatibilities. Consult the [ release announcement](https://www.openssh.com/txt/release-8.1) for more information.

- `PRETTY_NAME` in `/etc/os-release` now uses the short rather than full version string.

- The ACME module has switched from simp-le to [lego](https://github.com/go-acme/lego) which allows us to support DNS-01 challenges and wildcard certificates. The following options have been added: [security.acme.acceptTerms](options.html#opt-security.acme.acceptTerms), [security.acme.certs.\<name\>.dnsProvider](options.html#opt-security.acme.certs), [security.acme.certs.\<name\>.credentialsFile](options.html#opt-security.acme.certs), [security.acme.certs.\<name\>.dnsPropagationCheck](options.html#opt-security.acme.certs). As well as this, the options `security.acme.acceptTerms` and either `security.acme.email` or `security.acme.certs.<name>.email` must be set in order to use the ACME module. Certificates will be regenerated on activation, no account or certificate will be migrated from simp-le. In particular private keys will not be preserved. However, the credentials for simp-le are preserved and thus it is possible to roll back to previous versions without breaking certificate generation. Note also that in contrary to simp-le a new private key is recreated at each renewal by default, which can have consequences if you embed your public key in apps.