The API that became part of the OS

Over three years and 936 commits, I helped take the Unraid API from a Connect-plugin sidecar to a first-party, open-source platform — a NestJS GraphQL API that now ships inside Unraid OS itself, running on hundreds of thousands of servers in homes, labs, and small businesses.

Three milestones stand out: we open-sourced the API in March 2025, integrated it into the OS for Unraid 7.2 in August 2025, and shipped SSO and OIDC sign-in so an Unraid server can authenticate against Unraid.net — or any identity provider a user chooses. Each one changed the product’s relationship with its community: from “trust our plugin” to “read the code, extend it, build on it.”

A typed API for a very untyped machine

An Unraid server is a deeply stateful, deeply physical thing — disks that spin down, Docker containers, VMs, UPS units, flash boot devices. The API’s job is to make all of that queryable and controllable through one typed GraphQL contract.

• Code-first NestJS GraphQL schema covering the array, disks, Docker, VMs, CPU, UPS monitoring, and notifications — including subscriptions for live data like CPU utilization and disk spin state.
• Runs on the user’s server, not our cloud. I did the unglamorous packaging work to make that true: bundling Node.js for legacy OS versions, building a native Slackware package, and replacing the PM2 daemon layer — because an API you ship into someone’s home has to install, upgrade, and uninstall cleanly.
• Scoped API keys with granular permissions and OAuth-style key flows, so third-party tools get exactly the access a user grants and nothing more.

Identity: SSO and OIDC

I built Unraid’s single sign-on end to end — the token exchange between a server’s login page and the Unraid.net account system — and then generalized it into full OIDC provider management, so users can wire their server’s login to their own identity provider. For a user base that includes both weekend homelabbers and security-conscious professionals, “bring your own IdP” was a trust statement, not just a feature.

Wiring into the WebGUI without breaking it

The WebGUI is a 20-year-old PHP codebase that the entire community knows intimately. My work there (128 commits in the OS repo, plus the whole UI layer in the API repo) was about modernizing carefully:

• A diff-based file patcher that lets the API safely modify stock WebGUI pages — with verification before applying and automatic rollback — instead of blindly overwriting files a user may have customized.
• Vue 3 components mounted directly into the PHP pages — notifications center, onboarding wizard, TPM licensing surfaces, theme system — after I moved us off web components and made mounting 10x faster.
• Dashboard performance work in the OS itself: rewriting chart updates to stop unnecessary DOM churn, plus SSO on the login page and deprecated-filesystem warnings that nudge users off risky XFS v4 setups.
• A PR-plugin CI system I built so any WebGUI pull request packages itself into an installable test plugin — reviewers and community testers can try a change on real hardware in minutes.

Open-sourcing the repo

Making the repo public was a product decision with engineering work behind it: I converted the codebase to a pnpm monorepo, set up release-please automation, Apollo schema publishing, CodeQL scanning, and moved community translations to Crowdin. The repo had to be something outside contributors could actually navigate — open source as an operating standard, not a press release.

Why it matters

Platform work usually asks users to trade control for convenience. This project tried to avoid that trade: the API runs on hardware the user owns, authenticates the way the user chooses, is packaged to respect the system it lives in, and is open for anyone to inspect. Control stays with the user at every layer.