Multitenancy & Regionalization¶

Polyguard is available as both a managed SaaS platform and self-hosted software. This page explains the deployment models, their tradeoffs, and how Polyguard handles regional infrastructure.

Deployment Models¶

SaaS (Managed by Polyguard)¶

The default deployment model. Your integration points to the Polyguard global endpoint at api-global.polyguard.ai, and Polyguard operates all infrastructure -- API servers, databases, PKI, and regional routing.

Self-Hosted (Operated by the Platform Operator)¶

For Platform Operators with strict data sovereignty or compliance requirements, Polyguard can be deployed as self-hosted software at a well-known endpoint controlled by the operator.

SDK Compatibility¶

The Mobile and Web SDKs operate against any Polyguard System endpoint that is both authorized and active. The same SDK code works against both SaaS and self-hosted deployments -- you configure the endpoint at initialization time.

// SaaS
const polyguard = new Polyguard({
  appId: "your-app-id",
  environment: "production",
});

// Self-hosted
const polyguard = new Polyguard({
  appId: "your-app-id",
  endpoint: "https://polyguard.yourcompany.com",
});

PKI Constraints¶

Regardless of deployment model, all Polyguard PKI infrastructure is single-tenant SaaS only. This means:

• All PolyUser public keys are published within the Polyguard domain, even if trust checks are executed against a self-hosted endpoint.
• Any Relying Party can verify JWT signatures by fetching public keys from the Polyguard well-known URI, regardless of which Polyguard System processed the trust check.
• A PolyUser's identity is atomic and singular -- it is the same identity across all Polyguard applications, whether the trust check ran on SaaS or a self-hosted instance.

Self-Hosted Privacy Guarantees¶

Trust checks on self-hosted endpoints are completely private from Polyguard Inc. The transaction data -- event logs, affidavits, proof contents -- never leaves your infrastructure. The only interaction with Polyguard's SaaS infrastructure is the publication and retrieval of PolyUser public keys, which contain no transaction-specific data.

Regional Sharding¶

All Polyguard infrastructure runs globally. To minimize latency and comply with data residency requirements, certain APIs require connections to regional endpoints.

How Regional Routing Works¶

APIs that are region-sensitive will perform an HTTP 301 redirect to the appropriate regional endpoint before beginning any transaction. Your application should follow these redirects automatically.

The most important case is WebSocket connections: during a trust check, both the Web SDK and the Mobile SDK must connect to the same regional endpoint. The Polyguard System handles this coordination automatically -- the Link Session contains the regional endpoint information, and both SDKs read it from the session.

Client Request                   Polyguard Response
──────────────                   ──────────────────

GET /api/v1/session/connect  →   301 Redirect
                                 Location: https://us-west.polyguard.ai/api/v1/session/connect

GET (follow redirect)        →   101 Switching Protocols (WebSocket upgrade)

What This Means for Your Integration¶

• Web SDK and Mobile SDK: Regional routing is handled automatically. No action required.
• REST API calls: Ensure your HTTP client follows 301 redirects. Most libraries do this by default.
• Self-hosted deployments: If you operate in multiple regions, you are responsible for configuring your own regional routing and ensuring that WebSocket pairs connect to the same endpoint.

Summary¶