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 browser events and beacons, accepted only from your site’s domains and rate-limited. It writes and never reads. routingcat.config.json, and the head partial every page includes 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 server and other backends, or a PostHog destination 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, for the build of a Worker in front of your own server too; 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_… The middleware’s or the Worker’s code: routing data and records, and server-side events and identity links, for one environment The code of your middleware or Worker, which npx routingcat build writes to .routingcat/, 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 npx routingcat 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.

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. Anyone who can open your PostHog project’s destinations can read a key that a destination holds. 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 the code of your middleware or Worker, which the build writes to .routingcat/, 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