How we handle your data
StagingReservation is a small, focused tool. The list of things we do — and don't do — with your data is short on purpose. This page is the honest version.
Your source code never leaves your repo
StagingReservation does not fetch the contents of any file in your repository — no source, no READMEs, no configuration files, no git history beyond the SHA pointed to by each ref. The GitHub API endpoints we call are listed below, and each one returns only names or events. If you grep our server code (src/server/github.ts) you will not find a single call to /repos/.../contents or any equivalent.
And you don't have to take it on trust. The honest caveat first: GitHub bundles ref access and file-content access under a single Contents permission — there is no narrower scope that lets us list your branches without also permitting file reads — so the App technically couldread files. What stops it isn't a written promise, it's things you can check or enforce yourself: our server code is open and contains no file-contents call (grep src/server/github.ts); you can install the App on a single repo; and you can grant Contents: Readwith no write access so it can't change anything either. The same holds for private repos — the guarantee is about the calls we make, not repo visibility. We will never fetch your file contents.
What we actually fetch from GitHub
- GET /installation/repositories — public-ish metadata (name, default branch, one-line description) for repos in the install.
- GET /repos/{owner}/{repo}/branches and /tags — ref names only.
- GET /repos/.../git/ref/heads/... — the SHA at a branch tip, only when creating a new branch/tag from the board.
- POST / DELETE /repos/.../git/refs/... — branch and tag CRUD when a workspace owner/admin explicitly clicks the create / delete button on the board. main and develop are hard-protected (see src/lib/protected-branches.ts).
And we receive (not fetch) GitHub webhook events:
- push — branch + SHA, no diff.
- create — new tag / branch name.
- deployment_status — state transitions like pending → success.
From your OAuth login we get: GitHub login, public name, public email, avatar — the standard OAuth scope, nothing more.
What we don't see
- Source files, READMEs, config, vendored binaries.
- Issue or PR bodies / comments / reviews.
- Workflow / Actions logs.
- Your CI's secrets, environment variables, or kubeconfig.
- Anything on a repo we are not installed on.
GitHub App permission scopes are documented in detail on the integrations / github docs page.
Where it lives
- Encryption in transit: HTTPS everywhere via Cloudflare, with HSTS (12-month) and an enforced Content-Security-Policy — framing, plugins, and cross-origin connections are all disabled by default.
- Encryption at rest: MySQL on disk-encrypted VPS storage.
- Access: workspace data is scoped at the page and server-module level; cross-workspace queries are gated by the membership check (see src/lib/auth-helpers.ts).
- Webhook integrity: every GitHub webhook is HMAC-SHA256 verified against the app secret; duplicate deliveries are deduped by X-GitHub-Delivery.
- Rate limiting: per-IP on the webhook endpoint, per-user on workspace POST routes.
What we don't do
- Deploy your code. We mirror state from your CI. We never run kubectl, ssh, or call Vercel / workflow_dispatch on your behalf.
- Sell or share your data. No third-party ad networks, no analytics resale.
- Persist secrets you give GitHub. The GitHub App authenticates as itself; we never see your CI tokens.
Reporting a vulnerability
Please disclose responsibly. Email [email protected] with "security" in the subject line. We respond within one business day and prioritise fixes that affect confidentiality or integrity of customer data.
We don't run a paid bounty yet. Good-faith reports get a public acknowledgment (with your permission) and our genuine thanks.
Compliance posture
We're an honest beta — we have not pursued a SOC 2 / ISO 27001 / HIPAA / FedRAMP audit. The technical controls listed above are the substrate any of those certifications would be built on, so this isn't a long road if a customer asks. Talk to us early if you need a signed DPA or a security questionnaire response.