Storage Backends

Rubric writes three kinds of content to your configured storage backend: generated interviews, in-progress and finished sessions, and rendered reports. Three backends are supported. Pick the one that matches how you and your team work.

Local filesystem

The simplest backend. Rubric writes files into a directory you choose, on the same machine.

When to use:

• You’re the only interviewer using your installation.
• You don’t need to share content with teammates.
• You want the lowest possible setup cost.

Setup: in Settings → Storage, pick Local filesystem and choose a directory. Rubric creates this layout under it:

<your-storage-dir>/
├── interviews/
│   └── <category>/
│       └── <slug>/
│           ├── candidate-board.excalidraw
│           ├── interviewer-guide.md
│           └── interview.yaml
├── sessions/
│   └── <session-id>.json
└── reports/
    └── <session-id>.md

Trade-offs: no history, no sharing. Lose the directory and you lose the content.

Git repository

Rubric points at a checked-out local git repository and writes files inside it. Optionally, it auto-commits each generated interview or finished report.

When to use:

• You want full history of every change to every interview.
• You’re already comfortable with git.
• You and a teammate want to share content via the git remote (push/pull).

Setup: clone (or git init) a repo somewhere local. In Settings → Storage, pick Git repository and point at the working tree’s path. Configure the optional remote name (defaults to origin) if you want auto-push.

The layout inside the repo matches the local filesystem layout above. Each generated interview lands as a new commit, message format add interview: <category>/<slug>. Each finished report lands as a commit, message format add report: <session-id>.

Sharing across a team: the same repo can be cloned by multiple machines. Pull before generating to avoid conflicts on the same slug. Conflicts are rare in practice — interview slugs are unique by category, and reports are keyed on session IDs.

Trade-offs: the git workflow is yours to manage. Rubric won’t resolve merge conflicts for you. If two interviewers generate the same slug at the same time, the second push will fail and you’ll need to rebase or rename.

AWS S3

Rubric writes content directly to a configured S3 bucket using AWS credentials.

When to use:

• You want a single shared library across many machines without a git repo.
• You already use S3 for shared infra at your company.
• You want object-level versioning (enable bucket versioning on AWS’s side).

Setup: in Settings → Storage, pick AWS S3 and enter:

• Bucket name — the bucket you’ve created.
• Region — e.g., us-east-1.
• Path prefix — optional; useful for sharing a bucket across multiple Rubric installations.
• Remote name — a label for the connection. Cosmetic.

AWS credentials are read from the standard credential chain (~/.aws/credentials, environment variables, instance metadata). Rubric doesn’t ask you to paste them into Settings.

The layout in the bucket mirrors the local filesystem layout, prefixed by your configured path prefix.

Trade-offs: S3 isn’t a versioned filesystem unless you turn on bucket versioning. Without versioning, edits overwrite. With it, you get object-level history at a small extra cost. There’s no auto-merge — if two machines write the same key concurrently, the last write wins.

Choosing a backend

You want…	Pick
To get going in 30 seconds, solo	Local filesystem
Full version history, comfortable with git	Git repository
Shared library across a small team that already uses git	Git repository
Shared library across machines without git	AWS S3
Strong isolation per interviewer	Local filesystem

You can also start with one backend and migrate later — past sessions and reports stay where they were written. The new backend just applies to new content.

How storage works alongside the bundled library

The bundled starter catalog ships with the app and is read-only — those interviews always work, even offline, on every install. Generated interviews live in your configured storage backend on top of that catalog. The library screen shows both, so for the user it’s a single combined list.

This split keeps the app cold-start fast and the bundled set robust against partial writes from a sync that’s still in flight, while still letting you grow your own catalog without limits.