
Inari: Claude Code, Codex and Pi, self-hosted under your own name
Update, 28 October 2026. This page describes the first Inari, a repainted copy of Cloudroom's interface, which is now retired. Inari is its own core, interface and Android client, MIT-licensed: read the announcement for what changed and why, and get the new Inari.
Cloudroom runs Claude Code, Codex and Pi on your own machine or in the cloud, on your own subscriptions — and its core is Apache-2.0, self-hostable, with no account needed. Inari is what we put on top: the app's own colours, its kitsune signature, its own product name, and a password gate on the tailnet. Cloudroom itself is never forked; every upstream release is built as published, then a small tool patches the identity in place.
What you get. The full Cloudroom app, reachable from a browser or a dedicated client, bound to the self-hosted core on a machine of your own — no cloudroom.dev account, no hosted SaaS layer. Every model your own LiteLLM gateway serves shows up automatically. MIT licence on the identity tool, Apache-2.0 on the engine it patches.
1. The core, self-hosted
# on the machine that stays up
curl -fsSL https://raw.githubusercontent.com/davidondrej/cloudroom-core/main/docs/setup.md
# one script, tested on Ubuntu 24.04 — no database needed
Reach it from your other machines with Tailscale (see the backbone tutorial): the core only needs to be reachable, never exposed.
2. Your own identity, patched in place
git clone https://git.freedzhost.cloud/bengua/inari.git
cd inari && uv sync
uv run inari brand cloudroom-gui/gui # logo, icons, product name
uv run inari rebrand cloudroom-gui/gui # every visible mention, your own links
uv run inari theme ~/.local/share/your-app
Each edit is anchored on the exact upstream string. Run it twice: nothing changes the second time. Upstream moved the anchor it targets: the run stops and names it, instead of shipping half-renamed.
3. Keep it running
Two small daemons close the gaps a self-hosted setup opens that a hosted account would not:
- a sign-out drops the saved core connection; a timer-watched script re-binds it from the core's own token file, never typed, never logged;
- a second timer mirrors your LiteLLM gateway's model list into the app every 15 minutes, so a new model shows up without hand-editing anything.
Traps
The app probes harnesses (Claude Code, Codex, Pi) through the login shell: put their install directories on PATH in ~/.profile, or they report "not available" even when installed.
If the server pins a core and is killed by the out-of-memory killer every few hours, check the periodic catalogue sweep: with an empty catalogue address it used to re-arm at a delay of 0 (fixed in the brand patch set). The full diagnosis is in A service burns a core and gets killed.
Apache-2.0 requires the original NOTICE to travel with anything you distribute (source, docs, or a credits screen) — not a trademark problem, since Inari never uses Cloudroom's own name or logo, but a real obligation if you ship a built package, not just the source.
Source: git.freedzhost.cloud/bengua/inari (MIT). The engine it patches: cloudroom-gui and cloudroom-core (Apache-2.0).
Found this useful? Tell us what to measure next.