Welcome to the NixOS Router documentation. This guide will help you install, configure, and maintain your NixOS-based router.
Quick Links
- Installation Guide - Get started with installing the router
- Upgrading Guide - Learn how to upgrade your router
- Verification - Verify your router is working correctly
- WebUI Documentation - Learn about the web interface features
- Configuration - Configure all aspects of your router
This manual will eventually describe how to install, use, and extend Home Manager.
- GitHub - nix-community/home-manager: Manage a user environment using Nix [maintainer=@khaneliman, @rycee] · GitHub
- Home Manager - NixOS Wiki
- Home Manager - Official NixOS Wiki
Docs for bleeding edge master can be found at https://docs.helix-editor.com/master.
See the usage section for a quick overview of the editor, keymap section for all available keybindings and the configuration section for defining custom keybindings, setting themes, etc. For everything else (e.g., how to install supported language servers), see the Helix Wiki.
Refer the FAQ for common questions.
This docs/ directory is the documentation “source of truth” that lives alongside the code and evolves with it.
- Start with SUMMARY.md as the navigation spine.
- Add pages incrementally; the structure is designed to work well with future tooling (mdBook, Zola, Docusaurus, etc.).
Renode is an open source software development framework with commercial support from Antmicro that lets you develop, debug and test multi-node device systems reliably, scalably and effectively.
Renode strengths:
- full determinism of execution, shared virtual time
- transparent & robust debugging, tracing, analysis, even in multi-node setups
- easy integration with your everyday tools, plugins
- rich model abstractions with additional functionality "for free" + modular platform
description format - automated tests and CI integrations, other collaboration features
It lets you run, debug and test unmodified embedded software on your PC - from bare System-on-Chips, through complete devices to multi-node systems.
This version of the text assumes you’re using Rust 1.85.0 (released 2025-02-17) or later with edition = "2024" in the Cargo.toml file of all projects to configure them to use Rust 2024 Edition idioms. See the “Installation” section of Chapter 1 for instructions on installing or updating Rust, and see Appendix E for information on editions.
The HTML format is available online at https://doc.rust-lang.org/stable/book/ and offline with installations of Rust made with rustup; run rustup doc --book to open.
Several community translations are also available.
With ansible-builder you can configure and build portable, consistent, customized Ansible control nodes that are packaged as containers by Podman or Docker. These containers are known as execution environments. You can use them on AWX or Ansible Controller, with Ansible Navigator, for local playbook development and testing, in your CI pipelines, and anywhere else you run automation.
You can design and distribute specialized execution environments for your Ansible content, choosing the versions of Python and ansible-core you want, and installing only the Python packages, system packages, and Ansible collections you need for your tasks.
Ansible Runner is a tool and python library that helps when interfacing with Ansible directly or as part of another system whether that be through a container image interface, as a standalone tool, or as a Python module that can be imported. The goal is to provide a stable and consistent interface abstraction to Ansible. This allows Ansible to be embedded into other systems that don’t want to manage the complexities of the interface on their own (such as CI/CD platforms, Jenkins, or other automated tooling).
Topics
This table links to the changelogs for each major ansible-core release. These changelogs contain the dates and significant changes in each minor release. Dates listed indicate the start date of the maintenance cycle.
Sometimes tests need to invoke functionality which depends on global settings or which invokes code which cannot be easily tested such as network access. The monkeypatch fixture helps you to safely set/delete an attribute, dictionary item or environment variable, or to modify sys.path for importing.
The monkeypatch fixture provides these helper methods for safely patching and mocking functionality in tests:
- monkeypatch.setattr(obj, name, value, raising=True)
- monkeypatch.delattr(obj, name, raising=True)
- monkeypatch.setitem(mapping, name, value)
- monkeypatch.delitem(obj, name, raising=True)
- monkeypatch.setenv(name, value, prepend=None)
- monkeypatch.delenv(name, raising=True)
- monkeypatch.syspath_prepend(path)
- monkeypatch.chdir(path)
- monkeypatch.context()
All modifications will be undone after the requesting test function or fixture has finished. The raising parameter determines if a KeyError or AttributeError will be raised if the target of the set/deletion operation does not exist.
Cloud-init is the industry standard multi-distribution method for cross-platform cloud instance initialization. It is supported across all major public cloud providers, provisioning systems for private cloud infrastructure, and bare-metal installations.
During boot, cloud-init identifies the cloud it is running on and initializes the system accordingly. Cloud instances will automatically be provisioned during first boot with networking, storage, SSH keys, packages and various other system aspects already configured.
Cloud-init provides the necessary glue between launching a cloud instance and connecting to it so that it works as expected.
For cloud users, cloud-init provides no-install first-boot configuration management of a cloud instance. For cloud providers, it provides instance setup that can be integrated with your cloud.
If you would like to read more about what cloud-init is, what it does and how it works, check out our high-level introduction to the tool.
Welcome to the OpenZFS Documentation. This resource provides documentation for users and developers working with (or contributing to) the OpenZFS project. New users or system administrators should refer to the documentation for their favorite platform to get started.
Fedora CoreOS is an automatically updating, minimal, monolithic, container-focused operating system, designed for clusters but also operable standalone, optimized for Kubernetes but also great without it. Its goal is to provide the best container host to run containerized workloads securely and at scale.
Fedora CoreOS is an open source project associated with the Fedora Project.
Welcome to OpenTofu 1.9! This version brings you a host of new features like provider iteration, the -exclude flag and more. If you are coming from a previous OpenTofu or Terraform version you can read the details about the new features here »
Nix is a purely functional package manager. This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built. Nix stores packages in the Nix store, usually the directory /nix/store, where each package has its own unique subdirectory such as
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/
where b6gvzjyb2pg0… is a unique identifier for the package that captures all its dependencies (it’s a cryptographic hash of the package’s build dependency graph). This enables many powerful features.
Build Your Own Darknet
Discover the simplest way to re-enter independent computing with our framework. Placing control directly at your fingertips.
Nix is a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible.
- Resources
- Learning
- Discovery
- Installation Media
- Channel History
- Deployment Tools
- Virtualisation
- Command-Line Tools
- Development
- DevOps
- Programming Languages
- Arduino
- Clojure
- Crystal
- Elm
- Gleam
- Haskell
- Haxe
- Lean
- Node.js
- OCaml
- PHP
- PureScript
- Python
- Ruby
- Rust
- Scala
- Zig
- NixOS Modules
- NixOS Configuration Editors
- Overlays
- Distributions
- Community
The Pain of NixOS Beginners - Documentation and Flakes
NixOS is a highly distinctive Linux distribution built upon the Nix package manager, with a design philosophy that sets it apart from traditional distributions like Ubuntu, CentOS, Arch Linux and others.
One of NixOS's major advantages over other distributions lies in its reproducibility and declarative configuration, allowing users to replicate consistent system environments across multiple machines.
While NixOS is powerful, its strength also comes with increased system complexity. This makes it more challenging for newcomers. One major challenge is that the knowledge accumulated on other Linux distributions is not easily transferable to NixOS. Another is that official and community documentation is often scattered and outdated. These issues have troubled many NixOS beginners.
One can observe these issues with the experimental feature of the Nix package manager called Flakes. Inspired by package managers like npm and Cargo, Flakes uses flake.nix to record all external dependencies and flake.lock to lock their versions. This significantly enhances the reproducibility and composability of the Nix package manager and NixOS configurations.
Flakes' advantages have made it widely popular within the community: according to official surveys, over half of the new Nix repositories created on GitHub now utilize Flakes.
However, to maintain stability, the official documentation covers barely any Flakes-related content. This has left many Nix/NixOS users feeling confused. They see everyone using Flakes and want to learn it too, but find nowhere to start, often having to piece together scattered information, search through Nixpkgs source code, or seek help from more experienced users.
This manual describes how to install, use and extend NixOS, a Linux distribution based on the purely functional package management system Nix, that is composed using modules and packages defined in the Nixpkgs project.
Additional information regarding the Nix package manager and the Nixpkgs project can be found in respectively the Nix manual and the Nixpkgs manual.
If you encounter problems, please report them on the Discourse, the Matrix room, or on the #nixos channel on Libera.Chat. Alternatively, consider contributing to this manual. Bugs should be reported in NixOS’ GitHub issue tracker.
