Is NixOS configuration a unified interface for managing the whole system?

Modules are the convenient high-level interface, but they aren’t magic wrappers around every possible Linux component. A module may generate configuration files, install a package, create a systemd unit, perform validation, and connect related options together. If a program has no dedicated module, you can still add its package or define a custom systemd service and configuration yourself using the general NixOS options.

It also helps to think of Nix as a build and dependency system underneath the configuration. A system rebuild evaluates your options into derivations, builds anything that is missing, and assembles the resulting system from immutable content in the Nix store. The final system exposes the appropriate commands and links, while the declared configuration remains the source of truth.

Broadly, yes—but there’s an important distinction. NixOS configuration is a unified, declarative entry point for describing the desired state of the system. NixOS modules translate options such as boot.loader.grub.enable or a service’s enable option into the underlying files, packages, systemd units, and setup steps. You generally don’t need to install GRUB or enable a module-provided service separately; rebuilding the system applies those declarations.

The abstraction is not a replacement for the underlying runtime tools. You can still use systemctl, journalctl, and similar commands to inspect logs, test services, or troubleshoot. However, changes made interactively with those tools are usually temporary: the next rebuild may replace them with whatever your Nix configuration declares. The configuration is what makes the intended state reproducible and persistent.