nix-decred/docs/dcrd.md

dcrd options

dcrd uses rpc credentials, so it's recommended to secure your secrets using a tool like sops-nix.

sops-nix

Render dcrd.conf with sops-nix and point the service at it. Example:

{ config, lib, pkgs, ... }:
{
  # Define credentials as secrets
  sops.secrets."dcrd/rpcuser" = {};
  sops.secrets."dcrd/rpcpass" = {};

  # Render dcrd.conf owned by the dcrd service user/group
  sops.templates."dcrd.conf" = {
    owner = config.services.dcrd.user;
    group = config.services.dcrd.group;
    mode = "0440";
    restartUnits = [ "dcrd.service" ];
    content = ''
      [Application Options]
      # example settings
      rpcuser=${config.sops.placeholder."dcrd/rpcuser"}
      rpcpass=${config.sops.placeholder."dcrd/rpcpass"}
    '';
  };

  # Ensure dcrd only starts when the config exists
  systemd.services.dcrd.unitConfig.ConditionPathExists =
    config.sops.templates."dcrd.conf".path;

  # Point the module to the rendered config
  services.dcrd = {
    enable = true;
    configFile = config.sops.templates."dcrd.conf".path;
  };

}

Notes

Instead of using DynamicUser, the module necessarily runs dcrd as a fixed User/Group and uses a non-private state directory so rpc.cert can be read by intended consumers.

• dcrd writes rpc.cert into its data dir (--appdata, defaulting to /var/lib/dcrd).
• Consumers (e.g., wallets, tooling) often need to read rpc.cert without elevated privileges.
• With DynamicUser=true, systemd places state under /var/lib/private/dcrd and uses an ephemeral UID, which prevents other users/services from traversing the directory and reading rpc.cert.