The secure operating system core that keeps running when parts fail.

DurgX is a small, secure kernel for satellites, drones, factory machines and defense systems. If one driver crashes, only that driver restarts. The rest of your system never stops.

Download durgx.iso (free)Read the docs
Free
ISO download
4.2 MB
whole system image
4 cores
multi-core ready
Rust
memory-safe code

Watch it boot

qemu-system-x86_64 · -smp 4 · serial0
simulated console · mirrors spec v0.1
See where it fits

Where DurgX fits

Built for machines that cannot afford to stop.

Keep scrolling. The chip projects a 3D model of each place DurgX is made for, with what you gain in each.

Satellites and space systems

A glitch in space should not end the mission.

Radiation can corrupt a driver at any time. On DurgX, only that driver stops and restarts. The satellite keeps working.

  • A failing part is isolated and restarted instead of crashing the whole system.
  • Every program gets only the hardware access it was explicitly given.
  • The kernel's own memory is planned up front, so it cannot run out halfway through a mission.
  • You decide the recovery plan: restart, switch the part off, or raise an alert.

What you gain: Longer uptime in places where nobody can walk up and press reset.

Fault isolationAuto-restartLeast privilege

Drones, robots and avionics

A sensor crashes. The drone keeps flying.

Sensor and camera drivers run as ordinary programs with narrow permissions. When one dies, flight control never notices.

  • Flight control continues even if a peripheral driver crashes.
  • Drivers can only touch the exact hardware they were assigned.
  • A restarted driver gets its permissions back and picks up unfinished work.
  • Camera and sensor data moves between programs without being copied.

What you gain: Safer flights and fewer losses from a single faulty peripheral.

Drivers run isolatedAutomatic recoveryFast data path

Factories, energy and industrial control

Predictable timing. Hardened memory.

Control loops need to run on time, every time, and the code in memory must not be quietly rewritten.

  • Time-critical tasks are scheduled first and cannot be pushed aside by normal programs.
  • A steady 100 Hz timing tick keeps scheduling deterministic.
  • Memory is either writable or executable, never both, which blocks a whole class of attacks.
  • Multi-core memory updates stay in sync across all cores.

What you gain: Machines that hit their deadlines and resist tampering.

Hard real-timeMemory protectionMulti-core safe

Defense and high-security systems

Secrets stay separated by hardware, not by policy.

Classified and unclassified programs run in separate memory spaces that physically do not overlap.

  • Hardware enforces the separation between sensitive and normal programs.
  • Permissions are unforgeable tokens, and revoking one takes effect instantly everywhere.
  • There is no all-powerful root account to steal.
  • Risky work such as file parsing and networking runs outside the kernel.

What you gain: A much smaller attack surface to defend and to audit.

Zero-trust designInstant revokeNo root account

Why DurgX

Failures stay small. Your system stays up.

Most operating systems trust a lot of code with full power, so one bug can take everything down. DurgX trusts almost none of it.

Keeps running when parts fail

A crashed driver is caught, restarted and reconnected while everything else carries on.

Small attack surface

Only six small jobs run with full privilege. Less trusted code means less to attack and less to audit.

Predictable timing

Real-time tasks are scheduled first, on a steady 100 Hz tick, so deadlines are met every time.

Tiny and easy to try

The whole system is a 4.2 MB image. Boot it in a virtual machine or from a USB stick in minutes.

DurgX compared with a traditional OS

A traditional OS here means a monolithic kernel such as Linux.

  • When a driver crashes

    The whole machine can crash or freeze.

    Only that driver restarts. Everything else keeps running.

  • How much code runs with full power

    Drivers, file systems and networking all run with full privilege.

    Only six small core jobs do. Everything else is sandboxed.

  • Who can do what

    A root account can do almost anything.

    No root account. Each program holds only the permissions it was given.

  • Taking permissions away

    Different mechanism in every subsystem.

    One step, and it applies instantly to every copy.

  • Moving data between programs

    Data is usually copied several times.

    Shared memory rings. The data itself is never copied.

  • Time-critical work

    Needs extra real-time patches.

    Built in. Real-time tasks run first and cannot be pushed aside.

  • Running Linux programs

    Native.

    Planned through a compatibility layer, outside the kernel.

Try it: crash a driver

Break a driver and see what happens on DurgX, then on a traditional OS where drivers run inside the kernel.

Flight controlRunning on time

Flight control

Running

Time-critical, runs first

Restarts: 0

Sensor driver

Running

Reads motion sensors

Restarts: 0

Storage driver

Running

Reads and writes the disk

Restarts: 0

Network driver

Running

Sends and receives data

Restarts: 0

Whole-system crashes

0

Design

Drivers isolated, with a supervisor

> Everything is healthy. Pick a driver and crash it.

Under the hood

What happens when it starts

A short tour of the first moments after power-on. Scroll and watch each core light up.

Cores running

Step 1 of 4

Power on: the first core starts

The bootloader gives DurgX a map of your computer's memory. DurgX sets up its own memory layout, opens the serial console and prints its first message.

Step 2 of 4

The other cores wake up

DurgX reads the hardware tables to find every CPU core, then sends each one a start signal. Watch the extra cores light up on the chip.

Step 3 of 4

Each core starts its own timer

Every core sets a timer that ticks 100 times a second. That steady beat is what makes timing predictable.

Step 4 of 4

Your system takes over

DurgX starts one first program outside the kernel. Drivers, file systems and your own apps start from there, each with only the access it was given.

Quickstart & documentation hub

Boot it in under a minute.

Emulate headlessly, flash to real hardware, or verify your download.

terminal
qemu-system-x86_64 -cdrom durgx.iso -smp 4 -m 512M -nographic

expected serial output

serial0
Limine v11 — bootloader handoff OK
smp: INIT → SIPI → SIPI broadcast
smp: 4 cores online
init: Ring 3 root task spawned (CPL=3)
durgx: boot complete

notes

  • Download durgx.iso into your working directory first.
  • With -nographic the serial console is multiplexed onto your terminal. Quit QEMU with Ctrl-A then X.
  • The spec's reference boot uses 4 cores and 512 MiB of RAM.

Keep going in the docs

Run in a virtual machine

The fastest way to try DurgX on any computer.

Install on your hardware

Create a bootable USB stick and boot a real machine.

Build apps for DurgX

How a program talks to the kernel.

FAQ

Short answers to common questions.

Contact us

Talk to the Galaxyium team.

Have a question about DurgX or want to use it in a product? Send us an email and a person will reply.

Email

[email protected]
Send an email

Write to us about

  • Help evaluating DurgX for your project
  • Early access to the app developer kit
  • Partnerships and custom deployments
  • Bug reports and feedback on the alpha