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 the guests, workloads and GitOps state of my lab, read-only. It had no Workflows page, because the Homie workflow list was one shared list. Every visitor sees what any one visitor picks. A demo that shows strangers the repositories of other strangers 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 the picks of each visitor in their Homie session only. It reads the runs with the visitor’s own GitHub token, never with the app token. 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 one-hour demo session. Four things broke on the way. Every demo session shared one user name. The GitHub “authorize during installation” option drops the CSRF state. Sign-in never offers to install the app. And the picker did not reopen after an installation.

The Situation

  • Homie v0.7.0, MIT, on GitHub, homepage.
  • The demo: homie-demo.franzramadhan.dev, a separate instance where every login has the read-only demo role (RFC 0016).
  • Workflows so far (RFC 0014, RFC 0015): one shared watch list, read with the installation token of the app, saved in a ConfigMap. That is right for my own instance and wrong for strangers.

The Design

RFC 0017 adds one store and changes which 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 or a ConfigMap. Logout or the end of the one-hour demo session removes them. Nothing is written.
  • The token of the visitor reads the runs. A GitHub App user token has three limits at once. It is limited to the permissions of the app (Actions read-only), to repositories the visitor can access, and to repositories where they installed the app. So GitHub enforces the isolation between visitors. It does not depend only on the bookkeeping in Homie.
  • 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 can sign in and pick, because it only touches the visitor’s own data. I prove that rule in the Bend post.
  • An OAuth App does not work here. To read Actions on private repositories, it needs the repo scope: read and write on every private repository of the visitor. To ask strangers for that is a liability.

Issue 1: Every Demo Session Was the Same User

Symptom

None in production. It came up while I designed RFC 0017. If two visitors sign in to GitHub at the same time, each one will overwrite the token of the other.

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. It checks that one never sees the picks of the other, 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 the Homie callback. Homie answers with an error.

Cause

That redirect carries a code but no state. Homie only accepts a callback with a state that it issued to the same session. That check 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”. The only way forward was to go and find the app on GitHub.

Cause

The GitHub sign-in only authorizes. It never offers to install the app. 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. The visitor installs, picks a repository and comes back through the Setup URL.

Issue 4: Back From Installing, Nothing Happened

Symptom

After the installation, the page showed Connect GitHub and pick workflows again. After a pick, 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. The button reads Change workflows when the session watches something.

Verifying It

In a fresh incognito window, I tried the demo, opened Workflows, connected, installed on one repository and picked two workflows. Their runs appeared. I logged out and tried the demo again, and the list was empty. The end-to-end script now checks three things. The GitHub routes of the demo ask for a sign-in (428) instead of a refusal (403). The sign-in redirects to GitHub. 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. When Homie reads with the visitor’s own token, GitHub enforces 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