No. Because identity comes from the session someone already has, switching a system from audit-only to enforcing doesn't log anyone out or interrupt anything in progress. The next request from a restricted location is simply the one that gets denied.

By default, the proxy fails open: the request is still allowed, and a location_lookup_failed event is written to the audit log so the outage is visible and distinguishable from a normal allow. The same applies to GeoIP provider errors. For your most sensitive resources, you can configure a fail-closed override instead, so access is blocked rather than allowed during an outage.

The Location Service reads the most recent location record for that user across every source that's submitted one, whether that's the proxy's own IP geolocation on each request or another signal you wire in, like an HR feed, a travel desk, or a badge system. Recency wins, regardless of source.

If it's a system type we already support, you register it yourself from the admin console: pick the type and add your connection details, with no code involved and nothing needed from us. It starts in audit-only mode. Traffic starts reaching it once your DNS for that hostname points at the proxy and its certificate covers the name — steps you handle in your own deployment, not something you set in our console. The integration page is the full list. If it's a system we don't support yet, our team builds that connector for you as part of onboarding, so you're never the one writing integration code.

Not in the traffic. Every system we proxy over HTTP is one you host yourself, which is what lets the proxy sit in the request path in front of it. github.com runs on GitHub's infrastructure: we don't control its DNS, its certificates, or its routing, so there's no point in the network where the proxy could go. Gating github.com out of band instead, by controlling who's granted access rather than inspecting each request, is a different shape of product.

Yes. Every new system starts in audit-only mode: identity and location are resolved and logged, but nothing is blocked. You review real traffic and country distributions, then flip that specific system to enforcing when you're confident.

Rules support exact resource matches and wildcards. Every rule that matches applies, and their denied countries combine into one set, so a tightly-scoped rule on one repo can be stricter than your org-wide baseline even though the baseline is default-allow. There's no precedence between rules, so a narrow rule can add denials on top of the baseline, but it can't carve an exception out of one.

Today that's a single admin role, covering rule management and the audit log together. Per-team scoping for larger organizations isn't available yet. Admins sign in through a built-in identity provider that can also connect to an existing identity provider (like Okta, Microsoft Entra ID, Ping Identity, JumpCloud, or Cisco Duo), so you don't need to stand up a separate account system.

API tokens and other connection details are encrypted and held in a dedicated secrets service, never as plain text. Rotating a credential automatically re-runs the connectivity check for that system.

Just enough to enforce policy: an identity resolved from the session or token your system already issued, a location record with its source and timestamp, and the resulting access decision. No passwords, and nothing beyond what's needed to make and log that decision.

No. You run it yourself, in your own private cloud. That can be a data center you operate or an account you hold with a public cloud provider; either way, the software runs on infrastructure you control, and no third party sits between your users and your systems. You're not depending on a cloud vendor to enforce your own compliance obligations.

A Kubernetes cluster. Any distribution works: a managed service like EKS, AKS, or GKE, a platform like OpenShift or Rancher, or a cluster you built yourself on-prem. The proxy and its services ship as containers, so it fits whatever cluster your platform team already operates and doesn't ask for a new one. It stores its state in PostgreSQL, and you can point it at a database you already run, on-prem or a managed service like RDS or Cloud SQL, instead of the one it can deploy for itself.

No. You run a deployment in each cloud or data center you operate in, and they work from one policy set rather than each carrying its own. A rule you write applies everywhere it's relevant, and decisions from every deployment land in the same audit log, so an investigation covers all of your environments at once instead of one at a time.

No. The entire service runs self-hosted inside your own infrastructure and makes no outbound calls carrying your data. GeoIP lookups are resolved in-process against a local database file rather than an external provider. That file ships the same way the rest of the software does, as a container image, and a scheduled restart picks up a newer build the way any other component update does. Your deployment never calls a GeoIP vendor: the only fetch involved is an ordinary container image pull. If you already run a geolocation service of your own, the proxy can take location from that instead of, or alongside, its local lookup, and that call stays inside your network too. Your session data, location records, and audit logs never leave your environment.