Redox OS
5 min read
Redox is a Unix-like operating system written from scratch in Rust, built around a microkernel design with a focus on safety, reliability, and security. It was created by Jeremy Soller (an engineer at System76) and first published on April 20, 2015. The name plays on redox (reduction–oxidation) chemistry — a nod to Rust, the language it is written in.

Rather than being a Linux distribution, Redox is a complete operating system of its own: kernel, drivers, C library, shell, GUI, and userland are all original and implemented primarily in Rust. Its design draws inspiration from seL4, MINIX, Plan 9, BSD, and Linux.

Microkernel Design
Unlike a monolithic kernel (such as Linux) where drivers, filesystems, and networking all run in privileged kernel space, Redox keeps the kernel minimal. Most components — device drivers, filesystems, network stacks, and other services — run as ordinary user-space processes.

The benefit is fault isolation: a crashing driver or filesystem cannot take down the whole system, and the small trusted kernel is far easier to audit. Combined with Rust's compile-time memory safety, this makes the system substantially more resilient than a traditional Unix kernel. The trade-off is the extra message passing (IPC) between the kernel and user-space services.

Everything is a URL (Schemes)
Redox generalizes the classic Unix idea that "everything is a file" into "everything is a URL". Every resource is named by a URL of the form scheme:reference, and is opened, read, and written just like a file.

A scheme is the part before the : and identifies which provider handles the resource — for example:
• file:/home/user/notes.txt — the filesystem
• tcp:127.0.0.1:8080 — a TCP socket
• display: — the screen / framebuffer

The key idea is that schemes are implemented by user-space scheme providers. A driver or service simply registers a scheme and then services open/read/write calls against it. This is the mechanism that lets drivers and system services live in user space while still presenting a uniform, file-like interface to applications. It is the Redox equivalent of device files and virtual filesystems, but more general and fully programmable from userland.

Components
• RedoxFS — the native filesystem, a copy-on-write design inspired by ZFS, with support for features like checksumming.
• relibc — a C standard library written from scratch in Rust. It implements the C/POSIX API on top of the Redox kernel, which is what allows existing C software to be ported and run. relibc can also target Linux.
• Orbital — the display server and window manager, providing the graphical environment (orbital: and display: schemes).
• Ion — the default command-line shell.
• Sodium — a vi-like text editor.
• pkgutils — the package manager used to install and manage software.

COSMIC Desktop
Redox shares a close relationship with System76's COSMIC desktop environment (also written in Rust). Since 2024, work has gone into running COSMIC applications on Redox, giving it a path toward a modern, fully-featured graphical desktop that is developed in tandem with a mainstream Linux desktop.

Compatibility & Architectures
Redox aims for source-level compatibility with Unix software: thanks to relibc and a POSIX-oriented userland, many programs can be recompiled and run with little or no modification, though it is not binary-compatible with Linux.

Supported architectures: i686, x86-64, AArch64, and 64-bit RISC-V.

Nix Support
Because Redox is a from-scratch target rather than a Linux distribution, getting software onto it means cross-compiling from a host machine (usually Linux). Nix is a natural fit here: its builds are reproducible and toolchain-driven, so a single fix to a cross-toolchain package can unlock a large number of dependent packages at once.

Two related efforts exist:

• Redox as a Nixpkgs target — Redox was added to Nixpkgs as a cross target (x86_64-unknown-redox), with platform definitions in lib/systems and slightly patched gcc and rustc that can emit Redox binaries. The first build is slow because Nix builds the Redox toolchain from source. In practice, only a small fraction of Nixpkgs' ~60k packages cross-compile cleanly to Redox.

• redoxpkgs (nix-community/redoxpkgs) — a Nix overlay / flake that wraps Nixpkgs to fix packages broken under the Redox cross target, with the intent of upstreaming patches over time. Binary cache is provided via Cachix. Typical workflow:

shell
# Cross-compile a package to Redox
nix-build . -A pkgsCross.x86_64-unknown-redox.cowsay

# Then mount the Redox filesystem and copy the resulting
# binaries out of /nix/store onto it to run them under Redox.

• redox-nix (redox-os/redox-nix) — provides a reproducible way to build Redox itself on Nix/NixOS without constantly sending upstream patches. The long-term ambition is to replace Redox's GNU make build system and build each component as a separate Nix derivation.

A further (aspirational) goal is to port Nix to run natively on Redox, so packages could be built and installed on the OS itself rather than cross-compiled on Linux and copied over.

Status
Redox is open source under the MIT License and is developed in the open on GitLab. As of 2025/26 it remains pre-1.0 (latest tagged release 0.9.0, September 2024) and is considered experimental — usable for development and experimentation but not yet a daily-driver OS. Development continues actively, with recent work focused on boot resilience, relibc, RedoxFS, and bringing up COSMIC.