[PR #772] Add osModa to Configuration Management #5883

New Issue

GiteaMirror · 2026-05-02T17:16:57-05:00

GiteaMirror commented

2026-05-02 17:16:57 -05:00

📋 Pull Request Information

Original PR: https://github.com/awesome-foss/awesome-sysadmin/pull/772
Author: @bolivian-peru
Created: 4/23/2026
Status: 🔄 Open

Base: master ← Head: add-osmoda-config-mgmt

📝 Commits (1)

1f47150 Add osModa to Configuration Management

📊 Changes

1 file changed (+1 additions, -0 deletions)

View changed files

📝 README.md (+1 -0)

📄 Description

Thank you for taking the time to work on a PR for Awesome-Sysadmin!

To ensure your PR is dealt with swiftly please check the following:

Your additions are Free software — Apache-2.0
Software you are submitting is not your own, unless you have a healthy ecosystem with a few contributors — disclosure: I am the primary author. Project has 80★, 20 forks, 14 issue labels, multiple contributors via PRs. Submitting because the Configuration Management category has no entry that combines NixOS-style atomic config with an AI-managed control plane, and Awesome-Sysadmin readers are exactly the audience that benefits from knowing this category exists.
Submit one item per pull request
Format follows the convention: - [Name](url) - Description, sentence case under 80 chars. ([Source Code](url)) `License` `Language`
Additions are inserted preserving alphabetical order — placed between OpenVox and Rudder (case-insensitive: openv < osmoda < rudder)
Not already listed at awesome-selfhosted — confirmed
Language tag is the main server-side requirement — Rust/TypeScript (10 Rust daemons + TypeScript gateway)
Searched repo for existing relevant issues/PRs — none found
No new category created
Actively maintained — last commit today; tagged GitHub Releases v1.1.0 and v1.2.0
Title is informative

Why is it awesome?

osModa is a NixOS distribution where every system change is a transaction with atomic rollback (NixOS generations) and every action is logged to a SHA-256 hash-chained tamper-evident audit ledger (agentctl verify-ledger). The agent layer adds 91 typed tools across 9 Rust daemons (system bridge, deploys, watchers, mesh, voice, MCP, learning, egress, wallets) — the AI agent uses structured tool calls instead of raw shell, making AI-driven sysadmin meaningfully safer than running an LLM with shell access on traditional Linux.

The Configuration Management category currently has Ansible, CFEngine, CINC, cloud-init, OpenVox, Rudder, Salt — all imperative or declarative tools that humans drive. osModa fits adjacent: declarative NixOS config that an AI can autonomously evolve through a SafeSwitch-gated deploy loop with auto-rollback on health-check failure.

Have you used it? For how long?

I built it. Running ~2.5 months on a fleet of small Hetzner VMs and on the spawn server hosting spawn.os.moda since February 2026. Production-shaped workloads include the spawn-app itself, ProxySmart marketplace, and several internal automation services.

Is this in a personal or professional setup?

Both. Personal: home-server experiments, AI bots. Professional: spawn.os.moda is a hosted-provisioning product running on it.

How many devices/users/services/... do you manage with it?

5 production servers (CX22 to Pro tier) + the spawn server itself. Combined ~12 systemd services per VM, ~60 services across the fleet. 10 daemons per host, ~50 daemons total across the fleet.

Biggest pros/cons compared to other solutions?

Pros vs Ansible/Salt: every change is a NixOS generation — nixos-rebuild --rollback switch is one command, not a "playbook to undo." The audit ledger is tamper-evident, not just append-only logs. The AI is constrained to typed tool calls instead of arbitrary shell.

Cons vs Ansible/Salt: NixOS-only — does not target Ubuntu/RHEL/Debian without converting them first (the installer does this on cloud VMs but it's destructive). Younger project, smaller ecosystem. Configuration management surface is the NixOS module + 91 MCP tools, not 1000s of pre-built modules.

Any other comments?

Submitting on the back of multiple recent ecosystem listings (in punkpeye/awesome-mcp-servers, nix-community/awesome-nix, rust-unofficial/awesome-rust). Happy to make any format adjustments.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/awesome-foss/awesome-sysadmin/pull/772 **Author:** [@bolivian-peru](https://github.com/bolivian-peru) **Created:** 4/23/2026 **Status:** 🔄 Open **Base:** `master` ← **Head:** `add-osmoda-config-mgmt` --- ### 📝 Commits (1) - [`1f47150`](https://github.com/awesome-foss/awesome-sysadmin/commit/1f47150f697dfb2ab97e256c11e8a1c42aa19b24) Add osModa to Configuration Management ### 📊 Changes **1 file changed** (+1 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+1 -0) </details> ### 📄 Description   Thank you for taking the time to work on a PR for Awesome-Sysadmin! To ensure your PR is dealt with swiftly please check the following: - [x] Your additions are [Free software](https://en.wikipedia.org/wiki/Free_software) — Apache-2.0 - [x] Software you are submitting is not your own, unless you have a healthy ecosystem with a few contributors — **disclosure: I am the primary author. Project has 80★, 20 forks, 14 issue labels, multiple contributors via PRs**. Submitting because the Configuration Management category has no entry that combines NixOS-style atomic config with an AI-managed control plane, and Awesome-Sysadmin readers are exactly the audience that benefits from knowing this category exists. - [x] Submit one item per pull request - [x] Format follows the convention: ``- [Name](url) - Description, sentence case under 80 chars. ([Source Code](url)) `License` `Language` `` - [x] Additions are inserted preserving alphabetical order — placed between `OpenVox` and `Rudder` (case-insensitive: openv < osmoda < rudder) - [x] Not already listed at [awesome-selfhosted](https://awesome-selfhosted.net) — confirmed - [x] `Language` tag is the main server-side requirement — `Rust/TypeScript` (10 Rust daemons + TypeScript gateway) - [x] Searched repo for existing relevant issues/PRs — none found - [x] No new category created - [x] Actively maintained — last commit today; tagged GitHub Releases [v1.1.0](https://github.com/bolivian-peru/os-moda/releases/tag/v1.1.0) and [v1.2.0](https://github.com/bolivian-peru/os-moda/releases/tag/v1.2.0) - [x] Title is informative -------------- - **Why is it awesome?** osModa is a NixOS distribution where every system change is a transaction with atomic rollback (NixOS generations) and every action is logged to a SHA-256 hash-chained tamper-evident audit ledger (`agentctl verify-ledger`). The agent layer adds 91 typed tools across 9 Rust daemons (system bridge, deploys, watchers, mesh, voice, MCP, learning, egress, wallets) — the AI agent uses structured tool calls instead of raw shell, making AI-driven sysadmin meaningfully safer than running an LLM with shell access on traditional Linux. The Configuration Management category currently has Ansible, CFEngine, CINC, cloud-init, OpenVox, Rudder, Salt — all imperative or declarative tools that humans drive. osModa fits adjacent: declarative NixOS config that an AI can autonomously evolve through a SafeSwitch-gated deploy loop with auto-rollback on health-check failure. - **Have you used it? For how long?** I built it. Running ~2.5 months on a fleet of small Hetzner VMs and on the spawn server hosting [spawn.os.moda](https://spawn.os.moda) since February 2026. Production-shaped workloads include the spawn-app itself, ProxySmart marketplace, and several internal automation services. - **Is this in a personal or professional setup?** Both. Personal: home-server experiments, AI bots. Professional: spawn.os.moda is a hosted-provisioning product running on it. - **How many devices/users/services/... do you manage with it?** 5 production servers (CX22 to Pro tier) + the spawn server itself. Combined ~12 systemd services per VM, ~60 services across the fleet. 10 daemons per host, ~50 daemons total across the fleet. - **Biggest pros/cons compared to other solutions?** Pros vs Ansible/Salt: every change is a NixOS generation — `nixos-rebuild --rollback switch` is one command, not a "playbook to undo." The audit ledger is tamper-evident, not just append-only logs. The AI is constrained to typed tool calls instead of arbitrary shell. Cons vs Ansible/Salt: NixOS-only — does not target Ubuntu/RHEL/Debian without converting them first (the installer does this on cloud VMs but it's destructive). Younger project, smaller ecosystem. Configuration management surface is the NixOS module + 91 MCP tools, not 1000s of pre-built modules. - **Any other comments?** Submitting on the back of multiple recent ecosystem listings (in [punkpeye/awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers/pull/5168), [nix-community/awesome-nix](https://github.com/nix-community/awesome-nix/pull/332), [rust-unofficial/awesome-rust](https://github.com/rust-unofficial/awesome-rust/pull/2416)). Happy to make any format adjustments. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-05-02 17:16:57 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/awesome-sysadmin#5883