styrene-edge

Infrastructure-as-code and provisioning toolchain for Styrene mesh devices. An opinionated path to stand up NixOS devices that join the mesh by default.

Status: Alpha Source: GitHub

What It Does

styrene-edge is a device support repository — the equivalent of a firmware tree or board support package. It contains NixOS configurations, device profiles, and provisioning scripts for edge hardware. Contributors work here to add new device patterns; operators interact with it through the styrened TUI, which fetches device profiles at runtime.

Styrix

The NixOS configuration for edge devices is named Styrix (Styrax + Nix). Styrix is NixOS with styrened, RNS, BATMAN-adv, and the Imperial CRT console theme baked in. It’s not a fork — it’s opinionated NixOS configuration.

Supported Devices

Provisioning Paths

x86 (USB installer): TUI prepares bootable USB with NixOS ISO, configs, and a polymerize.sh script. Boot the target device from USB, run polymerize, reboot into a mesh-enabled system.

ARM (direct SD): nix build produces a complete SD card image via the flake. Cachix binary cache (styrene.cachix.org) serves pre-built aarch64 images — no cross-compilation needed. Write to SD, insert, boot.

Firmware Manifest

External firmware (RNode, Meshtastic) is tracked via a manifest-based system rather than vendoring binaries or using git submodules:

• firmware/sources.yaml — Pins upstream releases by version and sha256 hash. Covers RNode Firmware (per-board .zip artifacts) and Meshtastic (per-platform binaries).
• firmware/fetch.sh — Downloads and verifies pinned artifacts at provision time. Supports --update-hashes to recompute checksums when bumping versions.
• Actual binaries are gitignored (firmware/rnode/, firmware/meshtastic/); only the manifest and fetch script are committed.

This pattern extends to future styrened-rs firmware for ESP32 — the same manifest tracks Styrene’s own edge binaries alongside third-party firmware.

ESP32 Bring-Up

styrene-edge includes a 4-phase plan for running styrene-rs on ESP32 hardware:

Phase 1 uses the HDLC framer already in styrene-rs (transport/iface/hdlc.rs) as the building block for the KISS serial interface. See rust-migration for the broader Rust strategy.

Repository Structure

styrene-edge/
├── sbc/
│   ├── flake.nix               # Nix flake for SD card images
│   ├── common/
│   │   ├── base.nix            # styrene.base NixOS module
│   │   ├── batman-mesh.nix     # styrene.mesh BATMAN-adv module
│   │   ├── styrened.nix        # styrene.daemon module
│   │   └── cosmic-desktop.nix  # styrene.desktop COSMIC DE module
│   ├── rpi4/configuration.nix
│   ├── rpi-zero2w/configuration.nix
│   ├── x86-generic/
│   │   ├── configuration.nix
│   │   └── polymerize.sh
│   └── t100ta/
│       ├── configuration.nix
│       └── polymerize.sh
├── firmware/                    # Upstream firmware manifests
│   ├── sources.yaml            # Pinned releases (version + sha256)
│   └── fetch.sh                # Download and verify artifacts
├── forge/                      # Styrene Forge (media prep)
│   ├── data/devices.yaml       # Device catalog
│   └── services/
│       ├── media_writer.py
│       └── bundle_builder.py
├── keys/                       # Builder SSH keys (public only)
├── mcu/                        # Microcontrollers (RP2040, ESP32, nRF)
└── router/                     # OpenWrt mesh routers

Usage

# Build SD card image for RPi 4
nix build ./sbc#packages.aarch64-linux.rpi4-sd

# Launch Forge TUI for USB media preparation
just run

# Run polymerize on target device after booting USB
sudo /iso/styrene/polymerize.sh

See Also

• styrened — core daemon installed on every provisioned device
• styrened — daemon + TUI that consumes device profiles at runtime
• Hardware — supported devices and recommendations
• Components — detailed component reference