You would add something like:

    services.restic.backups.my_repo.paths = [ config.services.freshrss.dataDir ];

The point is that you write the general part of the restic config (like the schedule and the S3 endpoint) once, in one place (i.e restic.nix). Then each service-specific part of the restic config, like the line above, lives next to other configs for the freshrss service (i.e. freshrss.nix, not restic.nix). Then a build step generates scripts and systemd units for restic from the merged config. This makes it very easy to remove any service and all traces of it, even when it has “cross-cutting” configs.

▲ neobrain 7 hours ago | parent [-]

Just adding to this since the point might be lost for people new to nix:

You can assign a value to `services.restic.backups.my_repo.paths = [ ... ]` in multiple places throughout your system configuration. When applying the config, all the values will be merged into a single list.

This is important because other standard tasks besides backup (e.g. firewall, monitoring, ...) also require per-service configuration. If every one of these tasks had only a single place where you needed to put a megalist of services (which is basically how `/etc` works on typical Linux distros!), this would quickly scatter the configuration that pertains to FreshRSS over N different files, making it hard to track where everything lives.

	▲	drdexebtjl 5 hours ago \| parent [-]
		Thanks. I’ve edited my comment it so our answers complement each other better. Aside from services, this pattern is everywhere once you start recognizing it. For example, my Claude Code config in Nix adds CLAUDE.local.md to the global gitignore, my Git config adds aliases to my shell, and my terminal config adds a monospace font to the system fonts.