# Modular Services meeting #11 2026-11-06

**URL:** https://discourse.nixos.org/t/modular-services-meeting-11-2026-11-06/81084
**Category:** Development
**Created:** [November 9, 2026, 8:32pm UTC](https://discourse.nixos.org/t/modular-services-meeting-11-2026-11-06/81084 "2026-11-09T20:32:01Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![kiara](https://discourse.nixos.org/user_avatar/discourse.nixos.org/kiara/32/37249_2.png) [@kiara](https://discourse.nixos.org/u/kiara)
#### Post date: [November 9, 2026, 8:32pm UTC](https://discourse.nixos.org/t/modular-services-meeting-11-2026-11-06/81084/1 "2026-11-09T20:32:01Z")

</div>

Attendees: @eveeifyeve, @roberth, @lassulus, @kiara, + 1 guest

## Discussion

### Conventions and reusable pieces

- @eveeifyeve: could we standardize conventions with specific files for aspects like portability, modular services and package modules? How do we work with multiple module `_class`es?
- @kiara: my recent PRs help in this direction:
  - [portable generation of configuration files](https://github.com/NixOS/nixpkgs/pull/577887)
  - [portable `argv` construction](https://github.com/NixOS/nixpkgs/pull/583340)

- @kiara: making settings loadable right into NixOS was interesting. Exposing these reusable pieces (config file generation, `argv`) is good low-hanging fruit.
- @lassulus: for config file construction this is the right abstraction, and other things can be built on top of it. Reduced scope is good. wrappers targets systemd and command wrappers. Not sure about the rest of the ecosystem. string-value configs instead of files.

### systemd integrations

- @eveeifyeve: we have multiple systemd integrations that do not have matching interfaces. Do we want to standardize those? Should we create a file in `lib` that has the systemd hardening options?
- @kiara: we have a lot of examples of systemd hardening to mine, and NixOS already has a hardened profile.
- @eveeifyeve: to help with hardening, we could expose the service configuration at the system service level as well as the user creation level:

```nix
system.services.instance = {
  imports = [pkgs.ghostunnel.services.default];
  ghostunnel.serviceConfig = {
    # NixOS options, or the options of another class.
    # For example, NixOS would implement the systemd `serviceConfig` options.
  };
};

```

- @eveeifyeve: Package modules are the same as modular services, with the wrapper logic consolidated:
  - config: `pkgs.modules.example.configFile`
  - definition: `pkgs.modules.example.definition`
  - systemd unit: `pkgs.modules.example.systemdUnit`

- @eveeifyeve: packages would be split up to a `/modules` directory, inside the folder that contains `package.nix`. It could hold package configuration, wrapper and modular service modules under `passthru.modules`.

### PR review

- [modular-services: add user creation/spec support](https://github.com/NixOS/nixpkgs/pull/579760)
  - @roberth: rewriting the logic of `absoluteServicePath`.

- [portable `argv` construction](https://github.com/NixOS/nixpkgs/pull/583340)
  - @eveeifyeve: probably needs moving from `pkgs`.
  - @kiara: done
  - @eveeifyeve: I would rather see the code placed together with their package. could we use `importApply`, so that the module we need for docs is separate?
  - @kiara: the NixOS docs eval sandbox cannot access modules in packages.

## Action items

- @eveeifyeve: test implementations of [portable `argv` construction](https://github.com/NixOS/nixpkgs/pull/583340).