Back to Home
post-thumb

Homie Demo: Watch Your Own CI Runs, Nothing Stored

Technology Homelab Rust
| October 23, 2026 | 5 min to read

Intro

The public demo of Homie showed my lab’s guests, workloads and GitOps state, read-only. It had no Workflows page, because Homie’s workflow list was one shared list: whatever one visitor picked, every visitor would see. A demo that shows strangers each other’s repositories is worse than no demo.

Since v0.7.0, a visitor signs in with GitHub, picks workflows from their own repositories and watches their runs. Nobody else sees them, and nothing is written anywhere.

TL;DR: a new watch store, store = "session", keeps each visitor’s picks in their Homie session only, and reads the runs with the visitor’s own GitHub token, never the app’s. A public GitHub App with Actions read-only permission is the doorway; it needs no private key at all. Picks are gone at logout or after the demo’s one hour. Four things broke on the way: every demo session shared one user name, GitHub’s “authorize during installation” option drops the CSRF state, signing in never offers to install the app, and the picker did not reopen after installing.

The Situation

The Design

RFC 0017 adds one store and changes whose token reads the runs:

flowchart LR
  V[Visitor] --> D[Homie demo]
  D -- "Connect GitHub" --> GH[GitHub sign-in]
  GH -- "user token" --> S[(Session memory)]
  V -- "picks workflows" --> S
  S -- "visitor's token" --> API[GitHub API]
  • Picks live in the session. Not in a file, not in a ConfigMap. Logout or the one-hour demo session ends them; nothing is written.
  • The visitor’s token reads the runs. A GitHub App user token is limited three ways at once: to the app’s permissions (Actions read-only), to repositories the visitor can access, and to repositories where they installed the app. So isolation between visitors is GitHub’s, not only Homie’s bookkeeping.
  • No private key. Homie never reads as the app in this mode, so the app only needs its client ID and secret, in OpenBao.
  • Roles get the picker only here. RFC 0016 refuses every GitHub route to a role. With store = "session" and the workflows page, a role may sign in and pick, because it only ever touches the visitor’s own data. Whether that rule really holds is proven, not hoped for: see the Bend post.
  • An OAuth App would not do. To read Actions on private repositories it needs the repo scope: read and write on every private repository of the visitor. Asking strangers for that is not a demo, it is a liability.

Issue 1: Every Demo Session Was the Same User

Symptom

None in production: it surfaced while designing RFC 0017. Two visitors signing in to GitHub at the same time would have overwritten each other’s token.

Cause

Homie kept the GitHub sign-in token keyed by the Homie user, and every demo session has the same user name, demo.

Fix

Tokens and picks are now keyed by the session ID, in every mode. A test logs in two demo sessions with the same user name and checks that one never sees the other’s picks, and that logout drops both the token and the picks.

Issue 2: Installing Sent Visitors to an Error

Symptom

With “Request user authorization (OAuth) during installation” on, GitHub sends the visitor from the installation straight to Homie’s callback, and Homie answers with an error.

Cause

That redirect carries a code but no state. Homie only accepts a callback whose state it issued to the same session: that check is what stops a forged sign-in.

Fix

The option stays off, and a Setup URL (/workflows) brings visitors back after installing. The check stays.

Issue 3: Signed In, No Repositories

Symptom

A first-time visitor signed in and saw “no repositories yet”, with no way forward but to go find the app on GitHub.

Cause

GitHub’s sign-in only authorizes. It never offers to install the app, and a user token reaches only repositories where the app is installed.

Fix

A new key, [github] install_url, shows an Install the GitHub App button exactly there. Install, pick a repository, come back through the Setup URL.

Issue 4: Back From Installing, Nothing Happened

Symptom

After installing, the page showed Connect GitHub and pick workflows again, and once picked, the button still said so.

Cause

The page only opened the picker after a sign-in (?picker), not after an installation (?setup_action=install). And the button text did not depend on whether anything was watched.

Fix

Both parameters open the picker, and the button reads Change workflows once the session watches something.

Verifying It

In a fresh incognito window: try the demo, Workflows, connect, install on one repository, pick two workflows, and their runs appear. Log out and try the demo again: the list is empty. The end-to-end script now checks that the demo’s GitHub routes ask for a sign-in (428) instead of refusing (403), that the sign-in redirects to GitHub, and that the list starts empty.

Lessons

  1. A shared identity hides in “the same user”. A role that many people share is one user name, so anything keyed by user name is shared too.
  2. Isolation is best borrowed. Reading with the visitor’s own token makes GitHub enforce what they can see; Homie only has to keep tokens apart.
  3. Convenience options can drop security checks. “Authorize during installation” saves one click and skips the CSRF state.
  4. Test the flow as a stranger. Every UX gap here showed up only in an incognito window, from the start.

References