Skip to content
RoutingCatRoutingCatRoutingCat Docs

Access and keys

Who can act on your site, and the keys your site, your builds and your backends use: what each allows, where it lives, how to replace it, and what a leak would allow.

Add and remove people

A site has one owner, the person whose sign-in created it with npx routingcat init, and the members the owner adds.

  • Add a member by email: under People in the site’s settings on the dashboard, or with npx routingcat members add ana@lumen.so. This sends that address an invitation, unless it already has a RoutingCat account, and access starts at that person’s next sign-in with that verified address.
  • Remove one under People too, or with npx routingcat members remove ana@lumen.so. Access ends at once.
  • Members can do everything but manage people, keys, domains and the plan the site is on, which stay the owner’s alone, so no member can open the site to others or change what it pays. The plan is the owner’s, for every site they own: a member sees it, and the site’s own visitors, never the owner’s other sites. The owner can’t be removed.
$ routingcat members
pantry · members
  theo@pantry.app  owner   active   since 2026-07-08
  ana@pantry.app   member  active   since 2026-07-08
  sam@pantry.app   member  pending  added 2026-10-10, until their first sign-in

RoutingCat’s support joins your site only when you add it as a member. RoutingCat’s operators act on a site they don’t belong to only to contain an incident, by turning routing off, blocking ingestion or revoking a credential, or to archive the site when its owner asks. Each such act is recorded, and npx routingcat status --since <date> lists it.

Keep each key where it belongs

Key Allows Lives in Replace it with
Public key, pk_… Naming the site, and sending beacons, accepted only from your site’s domains and rate-limited. It writes and never reads. routingcat.config.ts, and every page’s browser code Nothing: it is public, one per site
Server events key, sk_… Writing events and identity links for one environment, and nothing else The secrets of your other backends npx routingcat keys server --rotate
Deploy key, dk_… What a build does: registering its declarations, which a production build makes live, reading routing data and writing records On Cloudflare, Cloudflare’s build variables or your CI’s secrets, as ROUTINGCAT_DEPLOY_KEY; on Vercel, only a build that runs without Vercel’s token, such as a prebuilt deploy npx routingcat keys deploy --rotate --branch <production branch>, or --env preview --rotate; --revoke stops it at once
Runtime credential, rk_… Your deployment’s server code: routing data, records, and server-side events and identity links, for one environment Each deployment’s server code, the middleware’s or the Worker’s included, written by its build, never in browser code A new deploy mints a new one; ask RoutingCat to revoke one
Your sign-in What your role allows on your sites, and, on Cloudflare, registering production from a build on your machine run with ROUTINGCAT_ENV=production, once you confirm its plan Your machine’s keychain npx routingcat logout revokes it
  • No secret goes on Vercel. Builds there prove themselves with Vercel’s own signed build token, which needs Vercel’s OIDC federation: Settings → Security → Secure backend access with OIDC federation. Without it, and without a deploy key, a build there registers nothing.
  • On Cloudflare, every build in Cloudflare’s builds or your CI carries the deploy key, since those builds have no token of their own for RoutingCat: see Give Cloudflare’s builds the deploy key. Without it, a build there registers nothing. A build on your machine proves itself with your sign-in instead, once you ask it for production and confirm its plan: see Deploy from your machine.
  • One server key per environment. --env preview gives the preview key, whose events stay out of results, which count production only. doctor flags the preview key used in production.
  • The deploy key shows once. npx routingcat keys server shows the server key whenever the owner asks, but the deploy key shows only when it is minted or rotated, so store it then.
  • The production deploy key is bound to your production branch, given as --branch: it proves production only where your CI reports that branch, so another branch’s runs never register production with it, even with the key in their variables.
  • A rotated key keeps working for 24 hours, time to put its replacement in place.
  • The runtime credential never expires, so an older deployment you roll back to still records.
$ routingcat keys
pantry · keys
public key  pk_pantry_H7tTayds  public, write-only; it names the site in routingcat.config.ts
server      production: exists since 2026-07-09 · preview: not minted
deploy      production: not minted · preview: not minted
Show or mint one: routingcat keys server|deploy [--env preview] [--rotate]; the production deploy key takes --branch <production branch>

Know what a leaked key allows

None of these keys reads your results, members or keys: only a person does, as their role allows.

  • The public key: nothing beyond what any visitor’s browser can do. What a browser sends is a report anyone can forge, which is why an objective worth defending comes from a server.
  • The server events key: false conversions and identity links in its environment, and no reads. Rotate it.
  • The deploy key: registering declarations in your site’s name, which could change which of your deployed variants are live, and writing false records. Revoke the environment’s deploy keys at once, the one its last rotation replaced included, with npx routingcat keys deploy --env <env> --revoke, then mint another.
  • The runtime credential: it lives only in your deployment’s server code, which each build writes, out of your repository. If it leaks, ask RoutingCat to revoke it, then redeploy, which mints a fresh one.

Decide which domains send browser events

RoutingCat accepts browser calls only from your site’s domains, checked against each call’s Origin, else its Referer:

  • your production domain and its subdomains, from your production deploys;
  • on Vercel, your Vercel team’s vercel.app hosts, and your deployments’ own addresses;
  • on Cloudflare, the workers.dev and pages.dev hosts your deployments register from, with their previews;
  • the domains the owner adds, for your pages on another registrable domain: npx routingcat domains add lumen.app.
$ routingcat domains
pantry · domains
  -pantry.vercel.app  hosts ending with it  from the Vercel team           since 2026-07-08
  pantry.app          with its subdomains   from the production origin     since 2026-07-08
  pantry.cooking      with its subdomains   added with routingcat domains  since 2026-08-01

Sign in on a machine

  1. Run npx routingcat login, or let init do it. It prints a link and tries to open your browser.
  2. Sign in on that page, then allow the command on this machine.
  3. The command waits 50 seconds. If you approve later, it exits with code 3: run the same command again, and it continues.

The credential is kept in the machine’s keychain, else in a file only your user can read, and it renews itself, so a new agent conversation needs no new sign-in. The command acts as you, with your role on each site. npx routingcat logout revokes the credential and deletes it.

A coding agent’s sandbox may be unable to keep the command’s credential, or to reach RoutingCat: Troubleshooting gives the fix for each.

Next