The goal of a layered design#
Nix defines the desktop, system services, and development environments; use Flatpak, Distrobox, or virtual machines for components that need a different runtime, a distribution-specific toolchain, or specialized applications. The goal of layering is to make dependencies, state, permissions, and recovery paths clear, rather than to claim that every layer provides absolute isolation.
Layer 1: The host and development foundation#
Keep the desktop, terminal, networking, input methods, Git, and essential system integration on the host. Put project compilers, cross-compilation toolchains, and language dependencies in a project-level devShell, with pinned inputs and a lock file. When using a Python environment manager, also define its writable directories and lock files explicitly, so project dependencies do not become mixed into the system profile.
Validate the system closure, tool versions inside the project shell, and actual compilation results separately. A configuration that builds only shows that the declarations are valid; it does not prove that hardware access or desktop sessions work correctly.
Layer 2: Flatpak applications and permissions#
Flatpak can handle desktop software that needs an independent application runtime. Assign clear responsibility for managing application packages, remotes, permission overrides, and user data. services.flatpak.packages and services.flatpak.overrides are commonly provided by the third-party nix-flatpak module; they are not native options included in every NixOS configuration. Import and pin that module before using them.
Give each application access only to the directories it needs, and check Wayland/X11, D-Bus, portals, networking, and input-method integration separately. Declaring permissions does not guarantee 100% security; application versions, runtimes, and portal behavior can also change the effective permission boundary. Use the following read-only commands to verify the actual state:
flatpak info --show-permissions <APP_ID>
flatpak override --show <APP_ID>Layer 3: Distrobox compatibility environments#
Distrobox provides a mutable distribution userspace, suitable for existing distribution packages, specialized plugins, or tools that are difficult to adapt directly. Before creating one, decide on the container image, version, separate HOME, and shared directories. Avoid exposing the entire host HOME by default to applications that do not need it.
# 示例：使用单独 HOME；实际 image 应锁定版本或 digest
distrobox create --name compat-dev --image <CONTAINER_IMAGE> --home ~/containers/compat-dev
distrobox enter compat-dev
# 在容器内，按需导出桌面入口
distrobox-export --app <APPLICATION>For convenience, Distrobox integrates host directories, display, audio, and devices; it is not a security boundary for untrusted software. Installing software inside a container changes its state and does not replace the host Nix configuration. Record the container setup steps and package state, and test exported entry points, hardware permissions, and GUI startup separately.
Layer 4: KVM and virtual machines for specialized applications#
Applications that run only on other operating systems can live in KVM/QEMU virtual machines. Allocate vCPUs, memory, and storage according to the workload. First verify that the full VM boots and that its licenses, drivers, and applications work; then consider shared directories, the clipboard, or RDP window integration.
RDP integration tools such as WinApps can display guest application windows on the host desktop. Compatibility depends on the guest OS, RDP service, tool version, and compositor; do not assume every application will behave like a native program. Shared directories, device passthrough, and remote display all reduce the original scope of isolation.
Layer 5: Tasks on a separate server#
Services suited to long-running operation can be deployed to a separate server, with a controlled administrative entry point kept locally. Separate configuration, runtime data, secrets, and backups; cloud outages, network interruptions, and costs introduce additional operational constraints. Record deployment build, test, and switch steps separately from runtime observations. Being able to connect from a local terminal does not establish that the service is working correctly.
Acceptance checks and recovery#
| Layer | What to verify | Recovery basis |
|---|---|---|
| Host and devShell | Pinned versions, tool paths, actual compilation, and desktop behavior | NixOS generation, project lock file, and source code |
| Flatpak | Package versions, effective permissions, input methods, and portal behavior | Recorded remotes/versions and application data backups |
| Distrobox | Image, separate HOME, exported entry points, devices, and scope of sharing | Container definition, package state, and data backups |
| Virtual machine | Boot, applications, and boundaries for sharing and passthrough | Disk backups/snapshots and guest configuration |
| Server | Activated generation, networking, and service operation | A working previous system, console access, data backups, and a reviewed cloud resource plan |
References & further reading
- Distrobox uses and boundaries ↗
- Flatpak sandbox permissions ↗
- nix-flatpak declarative module ↗
- Official WinApps repository ↗
Adapted from technical notes. Examples use generic names.