# Elodin is one Rust monorepo for the flight stack and the simulation that tests it > The elodin monorepo holds Elodin's flight software, its telemetry database, a Python SDK and a 3D editor in a single Rust workspace, with Nix providing the build environment. It suits a team building drone and spacecraft software that wants the simulator and the flight code in one place, and it asks you to install Nix and accept a workspace with dozens of members. **elodin-sys/elodin** — Elodin simulation and flight software monorepo. - Repository: https://github.com/elodin-sys/elodin - Website: https://docs.elodin.systems - Stars: 550 · Forks: 45 - Language: Rust - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/elodin-sys-elodin ## One repository covering the aircraft and the simulator The repository description is one line: Elodin simulation and flight software monorepo. The README expands that into a list of the pieces, and the list is the clearest statement of what the project is. Under flight software there is aleph-os, described as Aleph NixOS modules for composing a Linux flight software stack that runs on the Orin, along with elodin-db, a time-series database that acts as a central telemetry store and message bus, a serial-bridge that reads sensor data streamed over the serial port and writes it to elodin-db, a mekf implementation of a Multiplicative Extended Kalman Filter that fuses sensor data to estimate vehicle attitude, and sensor-fw, expansion board firmware that streams IMU, mag and baro data to the Orin over USB or UART. Under simulation software there is nox-py, a Python SDK that includes ECS and JAX integration, and the Elodin editor, a 3D viewer and graphing tool for visualising both simulation and flight data. So the defining choice is that the code that flies and the code that simulates live in the same repository. That is unusual for flight software, where certification practice tends to separate the two, and it is the reason to look at Elodin before looking at the individual pieces. ## The Rust workspace is the architecture The Cargo.toml at the repository root is a workspace with resolver 2 and a long member list. Read that list and the shape of the project becomes clear without any further documentation. The simulation side appears as libraries: libs/nox, libs/nox-frames, libs/nox-py for the Python bindings, libs/hamann-chen-line, libs/stellarator and a libs/stellarator/buf crate, plus libs/wmm, libs/bbqueue, libs/s10 and libs/impeller with its own sub-crates for bevy, bbq, frame, wkt, kdl and stellar. There are also libs/elodin-editor, libs/elodin-macros, libs/db with its cli, eql, macros and examples/rust_client sub-crates, libs/postcard-c/codegen, libs/monte-carlo, libs/bevy_ai_skybox, libs/bevy_world_mesh and libs/cranelift-mlir. The flight side appears as fsw/ crates: fsw/roci with an adcs sub-crate, fsw/mekf, fsw/lqr, fsw/serial-bridge, fsw/aleph-status, fsw/aleph-setup, fsw/blackbox, fsw/tegrastats-bridge, fsw/video-streamer, fsw/rtsp-streamer, fsw/gstreamer and fsw/msp-osd. The top-level entries add the surrounding scaffolding: apps/elodin for the editor, apps/inscriber, an aleph/ directory for the NixOS modules, a nix/ directory, a justfile, flake.nix and flake.lock, a Cargo.lock, .buildkite/ for CI, ci/ and scripts/, an examples/ directory, and agent configuration files including AGENTS.md, CLAUDE.md, .agents/ and .cursor/. That last group is worth noting. The repository carries instructions for coding agents at its root, which tells you the team expects automated tooling to work in this tree and expects the tree to stay navigable for it. ## The editor and the telemetry database are the two pieces you touch first If you are evaluating Elodin without building a flight stack, the two components with their own documentation are the sensible entry points: the Elodin App documentation in apps/elodin/README.md and the Python SDK documentation in libs/nox-py/README.md. The editor is described as a 3D viewer and graphing tool for visualizing both simulation and flight data. The wording matters: the same tool serves both halves of the system. A simulation run and a live flight produce the same stream of messages, and the editor is what lets an engineer compare them in one place. The examples directory supports that reading, with dedicated examples for the rocket, the drone, the Falcon 9, the cube-sat in two forms, apollo-lander, and a betaflight-sitl controller alongside ones for log streaming, covariance ellipsoids and geo-frames. elodin-db is the other half. It is a time-series database functioning as a central telemetry store and message bus, and the README describes it as an FSW application, which tells you it runs on the flight computer rather than only on a workstation. The example folder includes a db-client, and the crate tree has libs/db/cli and libs/db/examples/rust_client, so there is a command line and a Rust client for whatever else needs to read the bus. A design where the database is both a store and a bus is what lets the editor subscribe to the same stream the flight code publishes. It also means the database is on the critical path of the vehicle, which is a real consideration before you adopt it. ## Getting it running: Nix, then just install The README is emphatic about the development environment. The repository uses Nix to provide a consistent, reproducible development environment across all platforms, and the project says this is the same environment the team uses daily. The prerequisites are Determinate Systems Nix, Just, and git-lfs, with git lfs install run globally. There is a warning that an Arm-based macOS is strongly preferred, since nix works on x86 and Ubuntu but at much slower build speeds and worse developer experience. The first step installs Determinate Systems Nix. ```bash curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install ``` Then you clone and enter the development shell. ```bash git clone https://github.com/elodin-sys/elodin.git cd elodin ``` ```bash nix develop ``` The first build takes a while, and the shell follows your current one, bash or zsh, with a venv on the PATH and no source needed. You can override it with ELODIN_SHELL=bash or ELODIN_SHELL=zsh. Next, build and install the editor and the database onto your PATH. ```bash just install elodin --version python examples/rocket/main.py run ``` You should see the version string from elodin, and the rocket example should start and publish messages. Then, in a second nix develop shell, you start the editor and connect it to the local server. ```bash elodin editor ``` One implementation detail in the justfile explains a lot about how the team works: just install writes elodin, elodin-db and a Python venv into that shell's target/shells/$ELODIN_SHELL_ID/ directory, so parallel worktrees and agent shells cannot overwrite each other. ELODIN_SHELL_ID defaults to the shell's process id and can be set to a name you manage yourself, with no automatic cleanup. ## Running the Python SDK needs a second shell and a wheel build The SDK is not installed by the first just install in the same way. The README has a separate section for Python SDK development, and it asks you to enter another Nix development shell, then build the SDK wheel. ```bash # In a new terminal nix develop # build the SDK python wheel just install py python examples/rocket/main.py run ``` The distinction between `just install` and `just install py` is worth noting for anyone scripting the setup, because the SDK is a Python wheel built with maturin and installed into a venv rather than a Rust binary dropped on the PATH. The repository also notes where the local setup instructions were validated: Arm M2 macOS and Intel x86 Ubuntu 24.04, on 2025-10-12. That date is a useful calibration on the instructions, since the environment and its scripts have moved since. For the flight side, aleph-os packages the stack as Aleph NixOS modules, so the same Nix machinery that gives you a reproducible dev shell is what produces the image that runs on the Orin. That consistency is the strongest argument for the approach: the same declarative description of the software exists for the workstation and for the vehicle. ## The Ubuntu path exists, and the README says why you should not use it There is an alternative setup, and it comes with a warning. If you cannot use Nix, you can manually install dependencies on Ubuntu or Linux, and the README calls this setup more complex and says it may lead to inconsistent environments across developers, with a strong recommendation to use Nix instead. The dependency list for that path is the cost of leaving Nix out. ```bash # Install required tools via apt sudo apt install just git-lfs pkg-config libasound2-dev libudev-dev cmake gfortran patchelf python3-dev ``` ```bash # Initialize git-lfs git lfs install ``` Read that apt line as a summary of what the Nix flake is hiding: audio and udev development headers for the desktop side, cmake and gfortran for the native and numerical build steps, patchelf for rewriting linked libraries in the built artifacts, and python3-dev for the bindings. The point is not that this path is impossible. It is that the build depends on a particular mix of system libraries and toolchain versions, and nothing in the repository pins them. On a fleet of developer machines or a continuous integration runner, that is where the environments drift apart, which is exactly what the warning is telling you. ## Releases, tags and the shape of the maintenance load The release history shows a project shipping steadily. Version v0.20.0 was released on 2026-10-05, v0.19.2 on 2026-09-14 and v0.19.1 on 2026-09-05, and the last push to the repository was on 2026-10-22. The repository is not archived. The justfile shows how that cadence is driven. A tag command refuses to tag if the latest tag already matches, and it refuses to tag from a branch other than main unless a commit is given explicitly. A wait-for-release recipe polls the GitHub release list every five minutes and gives up after 45 minutes with a timed out error. A promote recipe checks for UV_PUBLISH_TOKEN and fails with a clear message if it is unset, then creates a release and publishes with uv. So the release path runs through just recipes that enforce a single branch of truth and a token check, rather than through manual commands. That is a sensible arrangement for a monorepo where several components have to be versioned together. The licence is Apache-2.0, with the LICENSE file at the repository root. For a project that combines open flight software with a proprietary-friendly licence, the practical implication is that you can vendor and modify the code in a commercial product while keeping the notice, and you must preserve notices on redistribution. The licence says nothing about the airworthiness of any of it, which is a separate question that the repository does not address. The upgrade cost for a consumer is therefore a version bump plus a rebuild inside Nix, which is cheap if your environment is already Nix-based and expensive to untangle if it is not. ## Where Elodin is the wrong choice There are situations where adopting Elodin would cost you more than it saves. The first is when you need a small dependency footprint. The workspace includes Bevy-based rendering crates, video and streaming components such as fsw/rtsp-streamer, fsw/gstreamer and libs/video-toolbox, a cranelift-mlir crate and a stellarator layer. If all you want is a simulator library or a telemetry database, you are inheriting a dependency graph built for a much larger product, and the build times that come with it, which is the reason the README warns about slower build speeds on non-Arm machines. The second is flight certification. Elodin puts flight software and simulation in one repository and one workspace, and that is excellent for iteration and for testing the real code against the simulator. It is a poor fit for an organisation with strict segregation-of-duties or configuration-management rules for airborne software, because the same commit builds the thing that flies and the thing that tests it. The mekf, lqr and roci crates are algorithm implementations, and they are not qualified by being in this repository. The third is the environment dependency. Nix plus Just plus git-lfs plus a preference for Arm macOS is a real setup cost, and the alternative apt path is explicitly described as leading to inconsistent environments. The realistic alternative for many teams is a conventional flight stack: a separate simulator with its own repository, a flight computer image built by a separate system, and a separate plotting tool. The trade is real: you lose the ability to diff a live flight against a simulation in one viewer with one schema, and you gain independent release cycles and simpler compliance boundaries. ## Conclusion Elodin fits a small team that develops flight software and the simulator alongside it, and that wants one editor, one telemetry store and one Python SDK rather than three separate toolsets. It does not fit a team without appetite for Nix, or one that needs a small dependency footprint, because the workspace lists dozens of crates including Bevy-based rendering and video tooling. Verify first that the `just install` target works on your machine and that the rocket example runs, since the README states the setup was last validated on Arm M2 macOS and Intel x86 Ubuntu 24.04 on 2025-10-12. ## FAQ ### What is in the Elodin monorepo? Flight software including aleph-os NixOS modules for the Orin, elodin-db as a telemetry store and message bus, serial-bridge, mekf and sensor-fw, plus nox-py as a Python SDK with ECS and JAX integration, and the Elodin 3D editor and graphing tool. ### How do I set up the Elodin development environment? Install Determinate Systems Nix, Just and git-lfs, clone the repository, run `nix develop`, then `just install` to build and install the editor and the database. The README recommends an Arm-based macOS, since Nix works on x86 and Ubuntu but at slower build speeds. ### How do I install the Elodin Python SDK? Enter a second `nix develop` shell and run `just install py`, which builds the SDK Python wheel, then start an example with `python examples/rocket/main.py run` and open the editor with `elodin editor` in another shell. ### What licence is Elodin released under? Apache-2.0, with the LICENSE file at the repository root. The project is not archived, the last push was on 2026-10-22, and the latest listed release is v0.20.0 from 2026-10-05. ## Sources - [elodin-sys/elodin on GitHub](https://github.com/elodin-sys/elodin) - [License: Apache-2.0](https://github.com/elodin-sys/elodin/blob/main/LICENSE) - [Project website](https://docs.elodin.systems) - [README](https://github.com/elodin-sys/elodin/blob/main/README.md) - [Releases](https://github.com/elodin-sys/elodin/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/elodin-sys-elodin