Use cases · Developers
Dev setups worth stealing
Localhost in your dev browser. Preview deploys in a testing profile. The right cloud account, every time. The routing rules engineers actually run.
The actual rules editor. Pick a rule to see how it's built.
Local & preview
Local and preview, in the right window
Localhost and tunnel URLs land in the browser with your DevTools. Every pull request's preview deploy opens in a clean testing profile, signed into staging.
Localhost and tunnels in your dev browser
FirefoxHot reload, React DevTools, and your test logins, already open. A localhost or ngrok link from Slack or a terminal lands right there.
Local servers and shareable tunnels should open in the browser you actually debug in, not your default one, where an OAuth callback can drop into the wrong profile. One rule keeps every local and tunnel URL in your dev setup.
Firefoxin profileDev EditionwhenPreview deploys in a clean testing profile
Google ChromeVercel, Netlify, and Cloudflare preview URLs open in a profile with the right extensions and a staging login, never your production session.
Every push spins up a preview deployment. Routing those URLs to a dedicated testing profile gives you a controlled set of extensions, persistent DevTools, and a staging account that never touches your main work profile.
Google Chromein profileTestingwhen
Accounts & consoles
The right account, every single time
GitHub opens as the identity that can actually merge. Cloud consoles open in the account you meant, not whichever one happened to be active.
Work and personal GitHub, never crossed
Google ChromeRepo and review links open in your work GitHub profile, already in the org. Personal projects stay in their own profile.
GitHub's account switcher still keeps only one identity active at a time, so most developers run separate profiles. Routing github.com and gitlab.com to the work profile means you never approve or push from the wrong account.
Google Chromein profileWork (alex@acme.example)whenOne profile per cloud account
Google ChromeProduction GCP, Azure, and AWS consoles open in your prod profile. Sandbox links stay in the dev one. No more 'which account is this?'
You still can't stay signed into two cloud accounts in one browser, so a profile per account is the standard workaround. Routing console links to the matching profile keeps your production and sandbox sessions from ever crossing.
Google Chromein profileCloud (prod)when
Agency & on-call
Clients sandboxed, alerts where they belong
Each client lives in their own profile, with their SSO already in place. On-call alert links open straight into the right org's dashboard.
Client work, fully sandboxed
Google ChromeEverything for Acme opens in the Acme profile: their repos, their Drive, their SSO. Other clients never bleed in.
Contractors and agencies juggle several sets of logins. Matching a client's domains to a dedicated profile keeps their SSO, cookies, and tabs isolated, and keeps other clients off the screen during a share.
Google Chromein profileAcme CorpwhenOn-call alerts open in the right dashboard
Microsoft EdgeA Datadog, Sentry, or Grafana link from PagerDuty opens already signed into that org, so you start debugging instead of logging in.
On-call spans multiple orgs and tenants, and these tools want a valid session per org. Routing each dashboard to the profile that's already a member means an alert link is one click from the graph, not a login screen.
Microsoft Edgein profileOn-callwhen
Wire up your workflow
Copy a setup or build your own. BrowserFairy routes the next localhost link before your terminal finishes the build.
Download FreeFree forever for your first 3 rules. No trial, no expiry.