Anwendungsfälle · Entwickler
Dev-Setups zum Nachmachen
Localhost im Dev-Browser. Preview-Deploys im Testprofil. Das richtige Cloud-Konto, jedes Mal. Die Routing-Regeln, die Entwickler wirklich nutzen.
Der echte Regel-Editor. Wähle eine Regel, um zu sehen, wie sie aufgebaut ist.
Lokal & Vorschau
Lokal und Vorschau, im richtigen Fenster
Localhost- und Tunnel-URLs landen im Browser mit deinen DevTools. Jeder Preview-Deploy öffnet sich in einem sauberen Testprofil, angemeldet in der Staging-Umgebung.
Localhost und Tunnel in deinem Dev-Browser
FirefoxHot Reload, React DevTools und deine Test-Logins, schon geöffnet. Ein localhost- oder ngrok-Link aus Slack oder dem Terminal landet direkt dort.
Lokale Server und Tunnel sollten in dem Browser öffnen, in dem du debuggst, nicht im Standardbrowser, wo ein OAuth-Callback im falschen Profil landen kann. Eine Regel hält alle lokalen und Tunnel-URLs in deinem Dev-Setup.
Firefoxin profileDev EditionwhenPreview-Deployments in einem sauberen Testprofil
Google ChromeVorschau-URLs von Vercel, Netlify und Cloudflare öffnen sich in einem Profil mit den richtigen Erweiterungen und Staging-Login, nie in deiner Produktivsitzung.
Jeder Push startet ein Preview-Deployment. Wenn du diese URLs an ein eigenes Testprofil leitest, bekommst du einen kontrollierten Satz an Erweiterungen, dauerhaft geöffnete DevTools und ein Staging-Konto, das nie dein Hauptarbeitsprofil berührt.
Google Chromein profileTestingwhen
Konten & Konsolen
Jedes Mal das richtige Konto
GitHub öffnet sich mit der Identität, die tatsächlich mergen kann. Cloud-Konsolen öffnen sich im richtigen Konto, nicht im zuletzt aktiven.
Berufliches und privates GitHub, sauber getrennt
Google ChromeRepo- und Review-Links öffnen sich in deinem GitHub-Arbeitsprofil, direkt in der Organisation. Persönliche Projekte bleiben in ihrem eigenen Profil.
GitHubs Account-Wechsler hält immer nur eine Identität aktiv, weshalb die meisten Entwickler separate Profile nutzen. Wenn du github.com und gitlab.com ins Arbeitsprofil leitest, pushst oder genehmigst du nie vom falschen Account.
Google Chromein profileWork (alex@acme.example)whenEin Profil pro Cloud-Konto
Google ChromeGCP-, Azure- und AWS-Konsolen öffnen sich in deinem Prod-Profil. Sandbox-Links bleiben im Dev-Profil. Schluss mit „Welches Konto ist das?“
In einem Browser kannst du nicht gleichzeitig bei zwei Cloud-Konten angemeldet sein, daher ist ein Profil pro Konto die gängige Lösung. Konsolen-Links ans passende Profil weiterzuleiten verhindert, dass sich Produktions- und Sandbox-Sitzungen jemals vermischen.
Google Chromein profileCloud (prod)when
Agentur & Bereitschaft
Clients isoliert, Benachrichtigungen am richtigen Ort
Jeder Kunde hat sein eigenes Profil mit bereits eingerichtetem SSO. On-Call-Benachrichtigungen öffnen sich direkt im Dashboard der richtigen Organisation.
Kundenarbeit, vollständig isoliert
Google ChromeAlles für Acme öffnet sich im Acme-Profil: Repos, Drive, SSO. Andere Kunden bleiben komplett getrennt.
Freiberufler und Agenturen jonglieren mit vielen Zugangsdaten. Die Domains eines Kunden einem eigenen Profil zuzuordnen hält SSO, Cookies und Tabs isoliert, und andere Kunden bleiben beim Screensharing außen vor.
Google Chromein profileAcme CorpwhenOn-Call-Alarme öffnen sich im richtigen Dashboard
Microsoft EdgeEin Datadog-, Sentry- oder Grafana-Link aus PagerDuty öffnet sich direkt in der richtigen Org angemeldet, sodass du sofort debuggen kannst, statt dich erst anzumelden.
Bereitschaft umfasst mehrere Organisationen und Tenants, und diese Tools brauchen eine gültige Sitzung pro Organisation. Wenn jedes Dashboard zum passenden Profil geleitet wird, führt ein Alarm-Link mit einem Klick zum Graph, nicht zum Login.
Microsoft Edgein profileOn-callwhen
Richte deinen Workflow ein
Kopiere ein Setup oder erstelle dein eigenes. BrowserFairy leitet den nächsten localhost-Link weiter, bevor dein Terminal den Build beendet hat.
Kostenlos ladenFür deine ersten 3 Regeln dauerhaft kostenlos. Keine Testphase, kein Ablauf.