TigerGate is deployed as a set of independent regional silos. Each region has its own dashboard, API, ingest endpoint, and databases, and no customer data crosses a region boundary. Your organization lives in exactly one region, chosen when it was created.

​
Which region am I in?

Three ways to answer it, in the order they take effort:
  • The host in your browser’s address bar when you’re signed in — match it against the Dashboard column above.
  • Settings → Organization → Organization Details names it under Data region.
  • From a terminal or a firewall rule, ask the API host itself. The endpoint needs no credentials, so it works before you have a key and when one is being rejected:
curl -s https://api.tigergate.dev/api/meta/region

{ "code": "us1", "name": "US1 - East", "location": "N. Virginia, USA",
  "api": "https://api.tigergate.dev", "dashboard": "https://app.tigergate.dev",
  "sensor": "sensor.tigergate.dev:443", "mcp": "https://mcp.tigergate.dev/mcp" }
Everything else follows from that row. The API host is the one you paste into third-party systems — your identity provider, CI runners, firewall allow-lists, and GitLab and Azure DevOps webhooks. The Ingest host is where in-cluster agents ship runtime events. GitHub and Bitbucket are the exception: their webhooks go to a shared receiver that forwards to your region, because neither URL can be chosen per region — see Connect a code provider.
API keys are region-scoped. A tg_…, tgci_…, or tgide_… key issued in one region is rejected everywhere else. The authentication error names the region and endpoint that were tried, so a wrong-region key is easy to spot.

​
Signing in

Each region has its own sign-in page and its own accounts, so the sign-in, sign-up and password-reset pages carry a Region selector. Choosing a region takes you to that region’s page — there is nothing to configure, because each one is a separate site with its own database. Two consequences worth knowing:
  • Accounts are not shared. The same email address can hold a separate account in each region, with separate passwords, sessions and API keys. There is no global directory, which is why app.tigergate.dev cannot tell you that your account is in another region — you tell it.
  • You are never redirected automatically. Your browser remembers the last region you used and offers it as a link, but an invitation, a password-reset link or a bookmark for one region keeps working in a browser that last signed in to another.
If a sign-in fails with valid credentials, check the region before checking anything else: the wrong region’s page looks identical and reports the same “invalid credentials” as a wrong password.

​
Point a tool at your region

Everything TigerGate ships that runs outside our infrastructure takes a region. Omit it and you get us1 — the behaviour every install had before regions existed, so nothing changes for us1 customers.
ToolHow to set the region
CLI--region <code>, the TIGERGATE_REGION env var, or region: in .tigergate.yml. Run tigergate regions to list them.
CI/CD integrationsThe region input (GitHub Action, Azure Pipelines task), the TIGERGATE_REGION variable (GitLab CI, Bitbucket Pipelines), or the REGION parameter (Jenkins).
KSPM + runtime sensor (Helm)--set region=<code>
Runtime sensor on a Linux host--region <code> on the installer, or TIGERGATE_REGION in the service environment.
Self-hosted pentest workerTIGERGATE_REGION
MCP serverYour region’s MCP URL. Setup Guide → AI Assistant (MCP) in the dashboard emits the client config already pointed at it.

​
How a region is resolved

Every TigerGate binary resolves its endpoints the same way. First match wins:
1

An explicit URL

--api-url / --backend-url / --collector-url, or the matching TIGERGATE_API_URL / TIGERGATE_BACKEND_URL environment variable. This is the self-hosted, staging, and air-gapped path, and it always wins — pass a URL and a region together and the URL is used, with one warning that the region was ignored.
2

--region

The flag, on the command itself.
3

TIGERGATE_REGION

The environment variable, so a CI runner or a systemd unit can set it once for everything on the host.
4

region: in .tigergate.yml

CLI only, and deliberately below the environment variable so a pipeline can override a value committed to the repository. There is no api_url counterpart in that file: a checked-in setting must not be able to redirect a build’s uploads to an arbitrary host.
5

us1

The default. Supply nothing and us1 resolves silently.
An unknown region code is fatal. The tool prints the valid codes and exits rather than falling back, so a typo can never ship one region’s data to another.

​
What stays in your region

Everything TigerGate scans, stores and serves about your environment stays in the region you chose:
Stays in region
Scan resultsCode, cloud, container, Kubernetes and pentest findings
Runtime telemetryAgent events, admission decisions, posture reports
Your credentialsGit, cloud and registry credentials, encrypted with a key unique to the region
Accounts and auditUsers, organizations, sessions, API keys, audit logs
Each region has its own databases, message bus and object storage. Nothing is replicated between regions, and a credential encrypted in one region cannot be read in another.

​
What does leave your region

A small number of flows are handled centrally. None of them carries your scan results or telemetry, but you should know what they are:
FlowWhat crossesWhy
GitHub and Bitbucket webhooksThe delivery body — repository, branch and commit metadata, including commit messages and author names and emails — in transit onlyNeither URL can be chosen per region: a GitHub App has one webhook URL for every installation, and Bitbucket’s hook is installed through a single OAuth consumer. A delivery therefore arrives with no region attached, and something has to route it
GitHub and Bitbucket OAuth callbacksThe provider’s short-lived authorization code, on the redirect backOne redirect URI per App / consumer, for the same reason
BillingCompany name, billing email, plan and invoice amountsOne payment processor serves all regions
Transactional emailRecipient address and message body for invitations, password resets and verificationSingle email provider
Service monitoringError traces and performance metrics from TigerGate’s own servicesShared observability
AI-assisted featuresOnly the specific code or finding you submit, when you use AI fix suggestions, AI PR review or AI pentestModel providers are not yet region-local
The receiver at hooks.tigergate.dev holds no database and writes nothing to disk. It reads which region owns the delivery, forwards it, and returns that region’s response unchanged — so your provider’s retries behave exactly as if it had posted to your region directly. Its logs record delivery id, event name, region, status and latency; never a payload body.Your repository contents never pass through it. Cloning happens inside your region, directly from your Git provider, using a credential that only exists there.
GitLab and Azure DevOps do not use it. Those webhooks are registered by us, per project or per organization, so the URL is chosen at that moment and points straight at your region — a merge request body, with its commit messages and author names, crosses no other host. If your organization cannot accept the transit for GitHub or Bitbucket either, the alternative is a dedicated provider application per region — one GitHub App, one OAuth consumer — which removes the shared hop entirely. Contact support before connecting integrations.
AI-assisted features are opt-in per organization. If your residency requirements do not permit sending code to a model provider, leave them disabled — every other product works without them.

​
What is shared by design

These carry no customer data and are the same whichever region you use:
DocumentationThis site
Helm chartsoci://registry.tigergate.dev/charts
CLI imagetigergate/tigergate-cli on Docker Hub
Container imagesghcr.io/tigergate

​
Changing region

An organization’s region is fixed when the organization is created, and the same email address can own a separate account in each region. There’s no self-service move — if you’re in the wrong region, contact support before you connect integrations, while there’s little to carry across.