Phoronix's Michael Larabel first summarized the report. The project's own news feed confirms that the update went out and opens by calling August "a very exciting month for Redox!" The project's short summary of the post also lists ARM64 multicore support, ring-buffer communication, NUMA support, process priorities, faster native compilation, out-of-memory fixes, QEMU on Redox, easier Linux dual-boot installation, and UEFI boot fixes. The report came out almost four weeks after the month ended. The project put the delay down to heavy development work, time off, conference attendance, and other commitments.
Redox OS August 2026 Update Puts I/O and Memory Topology First
Redox describes itself as "a complete Unix-like general-purpose microkernel-based operating system written in Rust." In a microkernel design, drivers and system services run as separate processes outside the kernel, so they depend heavily on how efficiently those pieces can pass messages to each other. That background explains why so much of the August work is about communication overhead and not about new applications.
The most notable item is the new ring-buffer communication API. Phoronix describes it as similar to Linux's io_uring and says it can improve performance with supported drivers, citing NVMe storage I/O as an example. As general background, not a detail from the Redox report, io_uring on Linux uses shared queues between an application and the kernel so that I/O requests and completions can be batched without a system call for every operation. The Redox version uses the same broad ring-buffer idea for its own communication paths.
The limits of that claim need to be clear. The report ties the benefit to supported drivers, and no published benchmark shows an NVMe speedup yet. Nothing in the available material says the API is compatible with Linux io_uring software, either. It is a performance-oriented mechanism that driver authors can adopt. It is not a compatibility layer.
The same update reports that IPC (inter-process communication) overhead dropped by about 5%, along with a smaller kernel binary and various driver improvements. The 5% figure comes from the project, and no method or baseline has been published. It should not be read as a 5% gain in overall system performance. On a microkernel, though, IPC cost is the tax every driver and service pays, so even single-digit reductions add up across the system.
Initial NUMA Support Points Redox Toward Server Hardware
Redox also gained initial NUMA support in August. NUMA (non-uniform memory access) describes systems where each processor or group of cores has its own "local" memory and reaches other banks more slowly. As general context, this is mostly a feature of multi-socket servers and some high-core-count workstation chips. An OS that knows the topology can place memory and threads to avoid slow cross-node access.
The word "initial" carries weight here. The accessible material lists no supported hardware, topology limits, or performance results, so this should be treated as groundwork, not proof that Redox is ready for servers. Still, the direction matches the project's stated plans. Its 2025/26 priorities, as WebProNews reported them from Phoronix, included variants tailored to specific use cases, including a "Hosted Redox" for virtual machines, a "Redox Server" for edge and cloud environments, and a "Redox Desktop".
The July work built the base for this. In that report, the project said Akshit Gaur's Redox Summer of Code project, implementing an EEVDF scheduler, has completed development and the work has been merged. Gaur also made kernel optimizations that, in a synthetic benchmark, reduced the average time needed for CPU context switch from around ~1.150 microseconds down to around ~250 nanoseconds. A new scheduler, cheaper context switches, NUMA awareness, and the process priorities listed in the August summary all belong to the same effort: making Redox behave sensibly on machines with many cores.
QEMU on Redox Works, Without KVM-Style Acceleration
The QEMU news is the item most likely to be overread. Phoronix reports that QEMU now runs on Redox but has no KVM-like acceleration, so it works but is very slow. In practice, Redox can now run QEMU as an ordinary application and emulate another machine in software. It cannot yet use the processor's virtualization extensions to run guests at near-native speed.
The goal is years old. In a 2021 Redox Summer of Code post, the student porting QEMU explained that Redox's toolchain relied on a supported Linux distribution to build the OS, and that what you could not do was compile and run Redox OS on QEMU on Redox OS. The idea was that once QEMU ran on Redox, "even if it isn't practical," developers could build and test Redox entirely on Redox, with no other operating system involved. The August summary's mention of faster native compilation points the same way. Nothing in the report says self-hosting is complete, but August takes it a step closer.
Virtualization also matters to how Redox is funded. In June the project announced that Redox has been selected for a grant from the NGI Zero Commons fund and NLnet, for our proposal "Virtualized Redox", with the aim of using Redox as a web server and microservices runtime. The €50,000 grant covers four part-time developers for 12 months. Its planned work includes better virtio-net support, RSS, TCP/IP segmentation and checksum offloading, plus virtiofs support, allowing us to share files with the host safely. Those sub-projects are mostly about Redox running as a guest on a hypervisor. QEMU running on Redox is the reverse direction.
Dual Boot From Linux and ARM64 Multicore Widen Where Redox Runs
Two August items affect where Redox can be installed. Phoronix reports that Redox now supports dual-boot installations from Linux, and the project summary calls installation easier. The report is specifically about Linux. It says nothing about dual-booting alongside Windows, and no step-by-step procedure, list of supported distributions, or bootloader details were available. Given that, WindowsForum is not publishing installation instructions. Anyone partitioning a disk for a second OS should have a full backup first.
This builds on July, when OSNews reported that the installer gained new options commonly found in most installers, such as a choice of installation method, network-based installation, and more. The August summary also mentions UEFI boot fixes, which matter for installing on modern PC firmware, though the specific fixes were not described.
On the ARM side, Redox on AArch64 now has initial multi-core CPU support. No specific board, SoC, or core count was named. ARM work has been ongoing: OSNews noted July's improvements to the ARM port, Amlogic Meson UART ARM64 support. Before multicore support, an ARM64 Redox system could effectively use only one core, so this change makes ARM hardware more useful for testing.
What this means for you
Only people who deliberately experiment with alternative operating systems, or developers interested in Rust systems programming, have any reason to act on this update. Redox is still a development-stage OS. Nothing in the August report changes that, and nothing here affects Windows PCs or Windows administration directly.
If you want to try the current state of Redox, the project points testers to daily builds. Its July report said that to test the changes of this month download the server or desktop variants of the daily images. A virtual machine on your existing Windows or Linux system is the low-risk way to look around. Given the thin documentation for the new Linux dual-boot path, real-hardware installation is only for people ready to rebuild a bootloader if something goes wrong.
- The August 2026 Redox report came out on September 25, 2026, and covers development work, not a stable release.
- The new ring-buffer API resembles Linux io_uring in concept, helps only drivers that support it, and has no published NVMe benchmarks.
- NUMA support and ARM64 multicore support are both described as initial, with no hardware compatibility lists.
- QEMU now runs on Redox but without KVM-style acceleration, so guests run in slow software emulation.
- Dual-boot installation is documented as working from Linux only, and no verified procedure or Windows dual-boot path has been published.
- The roughly 5% IPC overhead reduction is the project's own figure and should not be read as an overall performance gain.
Taken together, the August report is plumbing work: a faster communication path for drivers, NUMA awareness, cheaper IPC, and enough of a platform to run QEMU, all in service of the server and virtualization roles that the NLnet-funded "Virtualized Redox" project is paying for over the coming year. The next monthly reports will show whether drivers such as NVMe actually adopt the ring-buffer API and whether QEMU on Redox gets hardware acceleration, and those two changes would turn this month's groundwork into measurable performance.