Pricing

Scoped to What You're Protecting

Self-hosted deployment means pricing is driven by protected systems and support tier, not per-seat licensing on top of tools you already pay for.

Self-hosted

Team

For a first rollout covering one or two systems while you get comfortable with observe-only mode.

Customscoped to protected systems
  • Up to 2 protected systems
  • Works with Bitbucket, SonarQube, Artifactory, Bamboo, and GitHub out of the box
  • Try it in observe-only mode before enforcing anything
  • One dashboard for rules, systems, and the audit trail
  • Email support
Talk to Sales

Business

Most common

For organizations covering most of their internal tools, including access over git/SSH.

Customscoped to protected systems
  • No limit on protected systems
  • Covers command-line git access, not just the web UI
  • Combines multiple signals to confirm where someone's really located
  • Priority support during rollout
  • Export your audit history anytime
Talk to Sales

Enterprise

For regulated organizations that need custom coverage and dedicated support.

Customannual contract
  • Coverage for your own internal or homegrown systems
  • Extra-strict controls for your most sensitive projects
  • Dedicated support for deployment and rollout
  • Single sign-on and custom support agreements
Talk to Sales

FAQ

Frequently Asked Questions

The questions security and platform teams usually ask before rolling this out.

No. Each protected system has an identity adapter that reads the session or token the backend already trusts, like a Bitbucket session cookie or a token issued by your existing identity provider (Okta, Microsoft Entra ID, Ping Identity, JumpCloud, Cisco Duo, and others) for federated systems, and resolves identity from it directly. There's no separate login or MFA prompt.
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, like Bitbucket, SonarQube, Artifactory, or Bamboo, you register it yourself from the admin console: pick the type, add your connection details, and it's live in minutes. 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.
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. The most specific match wins, so a tightly-scoped rule on one repo can be stricter than your org-wide baseline even though the baseline is default-allow.
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. It runs self-hosted, inside your own infrastructure. You're not depending on a third-party cloud vendor to enforce your own compliance obligations.
cta-image

Ready to See It in Action?

Tell us which systems you need to protect and we'll show you exactly how it would work for your team.

Contact Sales