NixOps: what starts the key systemd services?

According to NixOps documentation:

Each key gets a corresponding systemd service "${keyname}-key.service" which is active while the key is present, and otherwise inactive when the key is absent.

I was working with NixOps keys until I found out that the corresponding "${keyname}-key.service" was dead:

[root@myhost:~]# l /run/keys/
total 4.0K
drwxr-x---  2 root keys   0 Mar 31 08:52 .
drwxr-xr-x 17 root root 520 Mar 31 08:52 ..
-rw-r--r--  1 root root   0 Mar 31 08:52 done
-rw-------  1 root root   6 Mar 31 08:52 mysecret

[root@myhost:~]# systemctl status mysecret-key.service 
● mysecret-key.service
   Loaded: loaded (/nix/store/m6swycz0jrv6fb2kphzwsxp78m5giy9w-unit-mysecret-key.service/mysecret-key.service; linked; vendor preset: enabled)
   Active: inactive (dead)

[root@myhost:~]# systemctl cat mysecret-key.service 
# /nix/store/m6swycz0jrv6fb2kphzwsxp78m5giy9w-unit-mysecret-key.service/mysecret-key.service
[Unit]

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/da0h55nhsipysryz9zcb9i7chbqffa45-glibc-locales-2.30/lib/locale/locale-archive"
Environment="PATH=/nix/store/xjg5di581iw6hn1yvj83p93fj5bk20ix-inotify-tools-3.20.1/bin:/nix/store/sn2fzbavnsb9sfff39ylkd6njfmh9gif-coreutils-8.31/bin:/nix/store/0c9izfknmjqgxwlnszi35ps5ds35yfi1-findutils-4.7.0/bin:/nix/store/g9317haqh75hj5x05yq6na2y21xcl2a5-gnugrep-3.4/bin:/nix/store/r540lhrdmgzccx3q6s55w08bikj7z5l>
Environment="TZDIR=/nix/store/rqzv14x4jnw5025n6r2chr6ar8wadr8g-tzdata-2019c/share/zoneinfo"



ExecStart=/nix/store/ziq0rhbnxripn4v41v7g8ixicy3kc3xb-unit-script-mysecret-key-start 
ExecStartPre=/nix/store/2v0xhz005ca61qlnw5jsxiymz7bhmrzs-unit-script-mysecret-key-pre-start
Restart=always
RestartSec=100ms
TimeoutStartSec=infinity

After a reboot and a nixops deploy, the unit is still dead. So, what is actually supposed to start a "${keyname}-key.service"?

I re-read the documentation more carefully:

{
  machine =
    { config, pkgs, ... }:
    {
      deployment.keys.my-secret.text = "shhh this is a secret";

      systemd.services.my-service = {
        after = [ "my-secret-key.service" ];
        wants = [ "my-secret-key.service" ];
        script = ''
          export MY_SECRET=$(cat /run/keys/my-secret)
          run-my-program
        '';
      };
    };
}

These dependencies will ensure that the service is only started when the keys it requires are present.

I now understand that it is my-service.service that triggers the starts of my-secret-key.service.

In my initial post, I though that my-secret-key.service was supposed to start automatically, and then you would hook up my-service.service to start on it such as:

systemd.services.my-service = {

  wantedBy = [ "my-secret-key.service" ];
  after = [ "my-secret-key.service" ];

  …

};

I found this sentence a bit misleading (emphasis is mine)

Each key gets a corresponding systemd service "${keyname}-key.service" which is active while the key is present, and otherwise inactive when the key is absent.