Frequently asked questions

Does this deploy my code for me?

No. StagingReservation never deploys. It listens to your GitHub activity and mirrors what's where. The actual deploy is done by your CI (GitHub Actions, Argo, your in-house scripts, etc).

When you click "Create branch" in the app, we write the branch to GitHub. Your CI may react to that push and deploy. The slot's status flips to Deploying when the push arrives, then to Live (or whatever ends your status workflow) when your CI sends a deployment_status event back to GitHub.

This split is the whole point: we don't want production credentials, and you keep one deploy pipeline instead of fighting two.

Does it work with monorepos?

Yes. A workspace can connect any number of repos, and each slot binds to exactly one of them. A common monorepo pattern:

• One workspace per deployable (web, api, worker).
• Each workspace connects only the monorepo, but slots track branches that affect that deployable's directory in your CI.

Or, if you have a monorepo with directory-scoped deployment pipelines:

• One workspace covering everything.
• Multiple env types (Web-Staging, API-Staging, Web-Prod, API-Prod).
• Each slot tracks the same branch but is bound to logically different deploys via your CI rules.

How do reservations work?

Any member can claim a slot for a bounded duration (30m / 1h / 4h / 1d presets, 7-day max). The slot card shows who holds it and how long is left; other members see a soft warning before changing status. Admins can force-release. Claims auto-expire at reservedUntil with no cron — stale rows are filtered at read time. Full reference: Reservations.

Complementary signals:

• Slot note for ad-hoc context the team can edit anytime.
• Slot tags for soft categorisation (perf-test, demo, broken).
• Slot owner for persistent responsibility (separate from "last updated by").

Can two workspaces watch the same repo?

Yes. A repo can be connected to multiple workspaces — each is a separate slot graph. Useful when one repo serves multiple teams or products with different staging needs.

What happens when I disconnect a repo?

The repo row is removed from the workspace. Slots bound to it are unbound (repoId set to null) — they stop receiving webhook updates but their history (last ref, last status, audit events) is kept. You can rebind to a different repo or re-add the same one.

The GitHub App installation is not touched — you can reconnect the same repo any time without going back to GitHub.

Why are main and develop protected?

The app's "Create branch" and "Delete branch" controls refuse to write to either. This is a hard-coded guard so a bad click can't nuke your default branch. Granting the App Contents: write doesn't override it. To work on those branches, do it on GitHub directly.

What's the difference between "Slot URL" and "Current URL"?

• Slot URL — the canonical / permanent URL of the env (e.g. https://staging-1.acme.test). You set it manually; it doesn't change.
• Current URL — the URL of the current deploy, set by deployment_status webhooks from GitHub. Changes every deploy.

If both are set, the slot card shows the canonical URL ("Open ↗"). The current URL is used internally for things like deployment context.

Who can do what?

| Role | Can do | |------|--------| | Owner | Everything — rename, delete workspace, billing later, all writes. | | Admin | Connect/disconnect repos, manage members, edit envs/slots, write branches/tags. | | Member | Read the board, change slot status, write own slot notes. |

Roles are set per-workspace. A user can be owner of one workspace and member of another.

Is there a CLI / API?

Not yet — it's on the roadmap. The plan is bearer-token auth + /api/v1/workspaces/.../slots endpoints + outbound webhooks for "slot changed" events. Ping us when you need it.

Self-hosting?

The app is open-ish — you can run it on your own infrastructure. You need MySQL 8, a GitHub App you create yourself, an SMTP or Postal mail transport, and Node 20+. Detailed self-host docs are coming.