Eighteen systems, one throughline.

SARC — compliance automation for regulated delivery

Product owner & lead architect Self-hosted

SARC turns "are we compliant?" from a question your team answers with spreadsheets and screenshots into a question the system answers with live evidence — automatically, every time you ship.

Regulated software delivery breaks in three predictable places. Audit prep becomes a fire drill, because the evidence is scattered across five to ten tools and nobody owns the whole story. The change board becomes a bottleneck, because a one-character fix and a schema migration both sit in the same 48-hour queue. And the compliance story itself gets locked to one cloud, so it breaks the moment a workload moves. SARC is the orchestration layer that fixes all three.

Every change gets a 5-axis risk clearance score — artifact, scope, attestation, temporal and code — derived from live attestations and written straight back onto the ServiceNow change request, each axis showing the controls it maps to (NIST 800-30, PCI-DSS 4.0, ISO 27005, DORA). Low-risk changes clear themselves; only the ones that matter land on a human's desk. That single number is what actually shrinks the CAB queue — and no other system in the stack computes it.

Auditors don't get a binder. They get a time-boxed, magic-link session, read-only, into the same dashboard the change board uses, with one-click evidence export for SOC 2, ISO 27001, DORA, PSD2, NIST 800-53, PCI-DSS, SOX and HIPAA. A cost–vulnerability correlation view prices remediation in dollars per month rather than abstract severity labels.

The engineering trick that makes it demo well: the same repository deploys to AWS (EKS), Azure (AKS), GCP (GKE), OpenShift or a local k3d cluster off a single TARGET_CLOUD switch that drives the Terraform, the kubectl auth, the Helm values and the environment naming — each cloud using its own native data services and identity federation rather than a lowest-common-denominator fudge. GitLab CI is the source of truth, with full parity on GitHub Actions and Azure DevOps. Images are built in-house, scanned with Trivy and signed with cosign. Evidence is recorded by Fides, shipped inside SARC — so there is zero SaaS egress: nothing about your delivery pipeline leaves your infrastructure. An in-cluster AI assistant answers questions about compliance state without needing a cloud API key.

Portal, by the numbers: 37 screens, real-time timeline updates over server-sent events, MCP servers so you can ask the compliance state of a commit in plain English, and role-shaped dashboards for directors, engineers, auditors and finance. It's not SaaS — you don't subscribe to SARC, you adopt it. A typical engagement is a 4–8 week MVP install, after which the customer owns and operates it. No per-seat fee, no vendor capture.

→ Walk through the live portal · Read the docs

Fides — a tamper-evident evidence ledger for the SDLC

Creator · open source Go

Named after the Roman goddess of trust and oaths, Fides records and evaluates every state change in the software delivery lifecycle as it happens, and turns the result into an audit-ready single source of truth. It's the evidence layer inside SARC, and it stands alone.

The core is supply-chain provenance: artifacts are traced by cryptographic SHA-256 digest from git commit to running runtime, with cosign signatures, SLSA in-toto attestations and SBOMs verified along the way. Drift and shadow-change detection continuously compares what's running to what was approved, so unauthorised deployments surface instead of hiding until the next audit.

The bits that matter to an auditor are first-class rather than bolted on. Control catalogs for SOC 2, ISO 27001, NIST 800-53, PCI-DSS, DORA, PSD2 and SOX import with one command and report per framework. Segregation of duties distinguishes human sign-off from machine automation — four-eyes needs two distinct humans, and the change gate will not recommend approval without a human review. FDA 21 CFR Part 11 electronic records and ECDSA signature validation are supported. Evidence can sit behind S3 Object Lock (WORM) retention, and Postgres row-level security enforces tenant isolation at the database layer, not just in the app.

The change gate itself emits an evidence-backed approve/hold verdict with a 0–100 risk score, and writes it onto the matching ServiceNow change request. Fides advises; ServiceNow decides. An LLM audit gateway runs against Ollama, llama.cpp or Gemini, so natural-language compliance checks work air-gapped. Go API, PostgreSQL, pluggable vaults (HashiCorp, AWS, GCP, Azure), an MCP server, and a CLI that covers record → verify → gate.

→ github.com/olafkfreund/fides

Hecate — the promotion layer Flux never had

Creator · open source · Apache 2.0 Go · pre-alpha

Flux makes a cluster match what is in git. It has no opinion about what should be in git next — so cross-environment promotion gets hand-rolled in CI, once per organisation, and quietly becomes the least-reviewed code in the delivery path. Argo has Rollouts for within an environment and is well served across them; Flux has Flagger for within, and nothing for across. Hecate fills that slot.

The whole API is four resources. A Beacon watches registries, charts and repos — or reuses Flux Operator's own ResourceSetInputProvider rather than inventing a second opinion about what "newest" means — and emits a Bundle: an immutable, content-addressed set of artifact versions, the unit that moves. A Gate is an environment plus the threshold a Bundle must cross to enter it. A Passage is one attempt to move one Bundle through one Gate, as declarative steps — clone, set image, commit, push, reconcile, and wait for the cluster to actually reach the revision rather than assuming it did.

The details are the regulated-delivery ones. Gates take after: [staging] so production can only admit what already cleared staging, and requireApproval where a human belongs. CI can tell a Beacon to look now instead of waiting for its interval, authenticated by its own OIDC workload token reviewed by Kubernetes — no shared secret, no HMAC, and an identity that can poke a Beacon still cannot read your Gates. Compliance evidence and OpenTelemetry tracing are emitted by the promotion itself, not reconstructed afterwards. Go 1.26, Apache 2.0, at v0.8.2 and honest about being pre-alpha.

→ hecate docs · source

The Factory suite — a governed pipeline for AI software delivery

Creator · open source PFactory · AIFactory · TFactory · CFactory

84% of developers use AI coding tools; only 29% trust the output. The Factory suite is the trust layer for that gap. Four products around one idea — AI can write the code, but someone still has to be accountable for it — built on the PARR pipeline: Prepare · Act · Reflect · Review, with a human gate at every seam rather than one "trust me" big bang.

• PFactory (Prepare) — plans work grounded in live cloud and Backstage context, runs architecture, security, feasibility and best-practice gates with citations, and only emits governed GitHub epics and issues once a human has signed the plan.
• AIFactory (Act) — turns those specs into code and QA in isolated git worktrees, model-agnostic across Claude, Gemini, OpenAI and local Ollama, and can delegate sub-tasks to other coding agents.
• TFactory (Reflect) — autonomously generates and runs tests in ephemeral sandboxes, grades each run on five signals (coverage delta, stability, mutation testing, lint and semantic relevance) and reports back on the pull request.
• CFactory (Review) — the control-tower cockpit: a live, animated dependency graph across plan → code → test, an advise-and-confirm copilot, and per-task and per-worker cost and token tracking.

The spine that makes four products cohere is deliberately boring plumbing: a shared correlation key, a normalized completion-event schema and a canonical port map, so every product emits the same audit trail — HMAC-anchored logs and completion records of exactly the kind the EU AI Act is about to ask for. It's model-agnostic through MCP, and you can watch the whole thing run live.

→ AIFactory · TFactory · PFactory · CFactory · the meta-repo

Agentic SDLC — the playbook, as a repository that runs

Author · open source Reference implementation

Every organisation writing an "AI in the SDLC" policy right now is writing a PDF. This is the same argument as a working build: seven stages, five planes, a portable artifact chain and an autonomy matrix — expressed as code that runs, gates that refuse, and evidence produced as a by-product rather than reconstructed for an auditor later.

Two things make it more than a demo. First, make negative: twelve deliberate violations — a float on a monetary field, a personal field in an error message, an unaudited POST, an edit to a frozen path, a change claiming more autonomy than it earned — each one refused by code, with the control id and the reason. A gate verified only by passing is indistinguishable from a gate that cannot fail. Second, no model sits in the gate. Models diagnose, propose, draft and review; the decision to allow or block is arithmetic over version-controlled policy YAML — the same tables governance signed off.

The Substitution Test is the part that survives procurement. GitHub Copilot is the agent runtime here, deliberately: the playbook's claim is that the operating model must outlive a change of vendor, so the honest way to make it is to use a specific vendor and keep every asset in an open format. Copilot is invoked in exactly one step per stage; make swap switches vendor four ways and re-scores under each. The context, skills, policy, gates and evidence do not move — 12/12 portable, 12/12 gates proven to refuse, 24/24 evals. And because a chain of commits is the audit trail, query_evidence.py --control SEC-API-01 answers "which production changes touched this control, which were agent-authored, at what autonomy tier, and who approved each" in seconds rather than a week.

→ the walkthrough · the screencast · source

Bifrost — Azure DevOps → GitHub Actions, at portfolio scale

Creator · open source · MIT Rust + React

GitHub's own importer gets you maybe 90% of the way from an Azure DevOps pipeline to a GitHub Actions workflow. Bifrost is the other 10% — the review workflow, the semantic validation, the portfolio-level coordination and the audit trail a syntactic converter leaves to you. It's the tooling I wish I'd had walking into a migration with hundreds of pipelines instead of one.

The design rule is review-first: nothing is silently rewritten. The importer runs a dry pass, Bifrost parses the logs into typed gaps, and each gap goes to an LLM grounded in the actual source, the importer's output and the failure — so the model fills a specific hole rather than converting from scratch. Risk scoring stays deterministic and explainable: the numbers come from factors you can read, and the LLM explains them rather than being trusted to invent them. Every decision is a signed, exportable attestation.

It's built to run where regulated shops actually live: air-gap capable against local models (Ollama / llama.cpp) so pipeline definitions and secrets never leave the network, with the same provider trait swapping in Anthropic, Gemini or Copilot when you're allowed to reach out. A React/TypeScript portal sits on a Rust/Axum control plane, with Docker-based ingestion behind a SourceAdapter trait: ADO first, Jenkins, GitLab and Bamboo next.

→ olafkfreund.github.io/bifrost · source

Janus — an MCP gateway for air-gapped enterprises

Creator · open source Go

Every enterprise wants to give its LLMs access to internal APIs. Almost none of them can, because the security review kills it. Janus is the gateway that survives that review: it turns any REST/HTTP API into MCP tools dynamically — declare the endpoint, map the request body to a JSON Schema template, and the gateway generates the MCP tool definition for you.

The security posture is the product. It's fail-closed by construction: secrets under 32 bytes and the process refuses to start, so there is no usable default. An SSRF egress guard blocks private, loopback and link-local addresses at dial time, including DNS rebinds. Tool-definition hash pinning defends against rug-pulls — every tool carries a SHA-256 hash and a version, and in strict mode a call is blocked the moment a definition changes after approval. Opt-in DLP redaction masks emails, Luhn-validated card numbers, JWTs, AWS keys and IBANs in tool arguments and downstream responses before they reach the LLM, and logs the class and count without ever logging the value.

It's also current with where the protocol is going: stateless Streamable HTTP transport that scales across replicas (matching the MCP 2026-07-28 direction), legacy HTTP+SSE for older clients, W3C Trace Context propagated into OpenTelemetry spans, and an opt-in OAuth 2.1 resource server with RFC 9728 metadata and audience-bound tokens — so enterprise-managed authorization works on the same path. RBAC maps straight from IdP group claims, fail-closed: a user in no mapped group gets no tools. Point it at an OpenAPI 3.x spec and it imports the whole surface in one shot.

→ janus.freundcloud.com · source

Myrmex Hive — agent orchestration with zero inbound ports

Creator · open source Go

The usual way to manage a fleet of edge machines is to open a port on each of them. Myrmex Hive inverts it. The agent on each target node opens an outbound SSH tunnel to a central gateway, and JSON-RPC rides that channel — so your edge servers expose nothing, and the entire class of attack that starts with a public scanner finding your management port simply doesn't apply.

Two more decisions do most of the security work. The agent executes binaries directly via OS process forks rather than through a shell, which structurally eliminates shell-injection — there is no shell to inject into — and every argument is validated against operator-defined regular expressions in config. Tunnels use Go's native crypto/ssh with Ed25519 signature validation and ChaCha20-Poly1305 / AES-GCM ciphers. Gateway access is bearer-token authorised, and the orchestrator can front a local Ollama model so the reasoning stays on your hardware too.

It ships the way infrastructure software should: a Nix flake with NixOS modules for declarative agent/gateway roles, a Homebrew cask for macOS, deb and rpm packages, container images, an install.sh that generates keys and boots the systemd unit, and a PowerShell installer for Windows Server. MCP over stdio or SSE, with a CLI and portal on top.

→ myrmex-hive.freundcloud.com · source

ravn-agents — self-healing for Linux fleets that never decides on its own

Creator · open source · MIT Rust

Ravn detects and fixes problems across Linux infrastructure — standalone hosts, Kubernetes, air-gapped networks — without phoning home to anyone's cloud. The whole design is a reaction to "AIOps" that asks you to trust a black box.

Detection is deterministic: rules you can read, not a statistical model you have to trust. Remediation runs from pre-authored, risk-tiered templates that need human or signed-policy approval. Every command is Ed25519-signed, verified and logged to an append-only Postgres trail. The local model only ever explains — it suggests next steps in plain language; it never decides what's wrong or what runs. That line is the entire point.

Three layers: edge agents (ravnd) detect and execute approved fixes, a control plane (ravn-server) handles ingestion and policy, and a web portal owns inventory, approvals and audit. Default-deny throughout — circuit breakers, fleet kill switches, risk tiers — and because inference runs locally on CPU it works fully offline. Rust backend, React front end, shipped as static binaries, NixOS modules, OCI images and Kubernetes manifests.

→ source

DORA Dashboard — delivery intelligence that can't leave the building

Creator · open source Next.js + Postgres

Regulated enterprises — finance, insurance, healthcare, public sector — cannot put delivery data into a multi-tenant SaaS analytics tool, so they compile it by hand across GitHub and Jira every quarter. This is the defensible self-hosted alternative: one portal, behind Entra ID SSO and GitHub OAuth, with no third-party data egress.

It covers the DORA-4 canon — deployment frequency, lead time for changes, change failure rate, MTTR — plus the extended delivery and quality set that teams actually argue about in retros: cycle time, work item age, blocked time, delivery predictability, average velocity, test automation coverage, defect escape rate and defect root cause. Every number traces back to the GitHub or Jira record it came from.

Next.js 16 on TypeScript, PostgreSQL 16 + Prisma, Auth.js with Entra ID OIDC and RBAC, Octokit and the Jira REST API for ingestion. Ships as a hardened Docker image with compose for small installs and a Helm chart for Kubernetes — air-gap friendly, with self-hosted fonts and assets and no runtime CDN dependency. Early days and building in the open.

→ source

SkillAi — open-source AI recruiting, in production

Author & lead architect · GPL v3 Live

A typical open role pulls 50–200 applications. The incumbents nail the workflow, charge tens of thousands a year, store your candidates on someone else's servers, and still leave the hard part — ranking people fairly — to a keyword match. SkillAi answers one question in seconds instead: who are the best candidates, and why?

It parses CVs in every format people actually send (PDF, DOCX, ODT, TXT, RTF), scores candidates across four dimensions — technical skills, experience, cultural fit, communication — and uses vector-embedding search so an old candidate can be re-evaluated against a new role instead of being lost. It generates interview packs with rubrics and follow-up questions, does multi-tenant RBAC, and talks to Google and Microsoft calendars. Every CV, score and note stays on infrastructure the team controls.

It's not a demo: SkillAi runs in production as the backbone of Synechron's recruitment for HSBC's Kraków technology hub. Built on Claude and Gemini, TypeScript, self-hosted, GPL v3.

→ github.com/olafkfreund/SkillAi

Odin — a control room for the homelab

Creator · private React + FastAPI + Nix

Odin is the single pane of glass over my own NixOS fleet — three machines, a k3d cluster, a media pipeline and a pile of local models. Live CPU, memory, storage, core temperature, battery and uptime per host; real-time port health for Plex, Sonarr, Radarr, Bazarr, NZBGet, n8n, Backstage, LiteLLM, Ollama and ArgoCD; a live map of namespaced Kubernetes resources and ArgoCD sync state; GPU VRAM and active Ollama models alongside token and cost analytics for Claude and Gemini; and the media ingestion queues with mount capacity.

A React + Vite frontend on a FastAPI aggregator backend, wrapped in a declarative Nix devenv shell so the whole thing comes up with direnv allow and just dev. The design language — "Prism Dark", glassmorphic panels, neon accents per hardware pool — is hand-rolled vanilla CSS, and the real-time cost charts are pure SVG rather than a charting library. It's the place where "infrastructure you can't rebuild from a clean checkout isn't infrastructure" gets tested against my own estate. Private repo.

Muninn — a GitHub portal that browser-native agents can drive

Creator · open source WebMCP playground

Named after one of Odin's ravens, Muninn travels the GitHub API and brings back memory: repositories, Actions runs, pull requests, issues, security alerts and stars, in one responsive Gruvbox-themed portal with zero backend.

The reason it exists is the last feature: Muninn implements the experimental browser-native WebMCP draft, registering client-side capabilities — list_loaded_repos, list_pull_requests, list_issues, trigger_action_workflow — as tools an AI agent running in your browser tab can call. It's a real, useful app that doubles as a place to find out what WebMCP is actually good for.

Beyond that: universal client-side search across repos, PRs, issues and runs; a real-time notification engine combining Web Notifications with in-app toasts and startup deduplication; Dependabot and code-scanning alerts unified; routine automations like draft-PR labelling and stale-issue cleanup; and a local Ollama chat terminal wired straight into the dashboard. Jekyll and vanilla JavaScript, developed in a devenv shell.

→ muninn.freundcloud.com · source

Huginn — the other raven, pointed at GitLab

Creator · open source Zero backend · WebMCP

Muninn and Huginn are Odin's two ravens, and they do the same job here for the two forges. Huginn is the GitLab half — GitLab.com or self-hosted — in the same Gruvbox light/dark treatment, with the same zero-backend architecture: the personal access token lives in the browser and never reaches a server, because there isn't one.

It runs pipelines and cancels them, reviews and merges MRs, triages and labels issues, surfaces project vulnerabilities and star analytics, and does unified client-side search across all of it. A notification engine combines desktop Web Notifications with in-app toasts for new issues, MR events, finished CI runs and new vulnerability alerts, with deduplication so a page load doesn't spam you. A local Ollama terminal sits in the dashboard for drafting and code analysis, and an optional background daemon watches edits, runs validation and triages project status.

Like Muninn it registers browser-native WebMCP tools — list_loaded_projects, list_merge_requests, list_issues, trigger_pipeline_run — so an agent in the tab can query and act without your token ever leaving the browser context. Jekyll and vanilla JavaScript, reproducible via devenv.

→ source

AWS Dashboard — your own AWS account, as browser-agent tools

Creator · open source WebMCP

The smallest of these, and the clearest illustration of why WebMCP is interesting. A browser page cannot read ~/.aws/credentials, and it shouldn't — so a thin Node proxy holds the AWS SDK and the local profile, serves the static page, and the page publishes what it fetched to the browser's agent through navigator.modelContext.registerTool.

What it surfaces is deliberately the two things you actually check first: every running EC2 instance, and who successfully logged into the console in the last 24 hours, from CloudTrail. The IAM permissions it needs are exactly ec2:DescribeInstances and cloudtrail:LookupEvents — nothing else. An agent in the tab can then answer "what's running and who's been in?" as tool calls, while the credentials stay on the machine. Tailwind, glassmorphic dark mode, one file of backend.

→ source

lxconnect — your Android phone as an MCP tool surface

Creator · open source Kotlin + Nix

lxconnect bridges Android — Waydroid or a real device — to the Linux desktop, and the interesting half is the MCP server it runs on the phone. The Android app stands up a Ktor MCP server on port 8080 and hooks into NotificationListenerService and PackageManager, so an agent on your laptop can treat the phone as a set of tools: read notifications, open native deep links (mailto:, spotify:), launch and control apps, read system status, even drive the camera — all over a standard MCP transport.

That turns "my phone" into something an agent can actually reach: triage notifications onto the desktop, hand a 2FA push to the right app, let a Claude session check or act on the device without you picking it up. A Python daemon reads a server-sent-events stream from the phone and surfaces it through libnotify; a GTK4/PyGObject app gives you a native UI to test and control it. The whole thing is a declarative Nix flake — nix run github:olafkfreund/lxconnect#gui and you're live.

→ source

nixarchy — a whole desktop, vendored onto NixOS

Creator · open source Nix · v4.0.1

Omarchy 4.x is not a dotfiles repo, it's an application: 429 shell commands, a QuickShell desktop shell, 22 themes and Hyprland driven through its Lua API. The usual Nix answer to something like that is to reimplement it, which produces a port that diverges from upstream the day after it lands. nixarchy packages the upstream tree as a derivation and replaces only the parts that assume Arch — so tracking a new release is a source bump, not a re-port.

What that buys: the Install menu writes to your Nix config instead of running pacman, with 56 curated applications selectable that way and every other nixpkgs package and NixOS option one Install ▸ Search away — a single picker over 137k rows. Plugins and themes still install from a git URL at runtime the way upstream intends. Every command that assumed /usr either points at what NixOS actually uses or says plainly why it cannot. There's a bootable ISO that takes seven questions and leaves you with a machine that is a flake you own, offline.

The naming is deliberate: upstream's 431 commands keep upstream's name, because a bug in omarchy theme set is a bug to report there, and renaming it would say otherwise. nixarchy owns what this port adds and execs through for everything else.

→ source

nix-skills — so your coding agent stops guessing at Nix

Creator · open source Nix · agent skills

Ask a coding agent for help with Nix and you get advice that is out of date, written for another distribution, or imperative — nix-env -i, an edit to a generated file, curl | sh. nix-skills fixes that at the source: a collection of portable skills that give Claude Code, Codex, OpenCode and Antigravity current, source-backed knowledge of the ecosystem, so the agent proposes declarative, reversible changes based on the versions you actually run.

Ten skills cover the Nix language, NixOS operations, Home Manager, nix-darwin, devenv, microvm.nix, Nixpkgs development, the NixOS wiki and running coding agents on NixOS. Most are generated from the upstream manuals at pinned revisions and refreshed on a schedule, so they stay current without anyone rewriting them. It installs skills, not agents.

Three ways in: a Home Manager module that installs only the skills, a flake template that sets up your own machine for agentic coding, or — to try it without touching your system — a disposable NixOS VM with agents and skills ready:

nix run github:olafkfreund/nix-skills?dir=demo

→ docs · source