Skip to main content

Regions

PolarGrid runs GPU infrastructure at edge locations to minimize latency.

Available Regions

Endpoint URLs

Examples:
  • https://api.yto-01.edge.polargrid.ai
  • https://api.yul-01.edge.polargrid.ai
  • https://api.yvr-02.edge.polargrid.ai
  • https://api.nyc-01.edge.polargrid.ai
  • https://api.dfw-01.edge.polargrid.ai
  • https://api.sfo-01.edge.polargrid.ai
  • https://api.lax-01.edge.polargrid.ai
  • https://api.sea-01.edge.polargrid.ai
  • https://api.chi-01.edge.polargrid.ai
  • https://api.phx-01.edge.polargrid.ai
  • https://api.was-01.edge.polargrid.ai
  • https://api.mia-01.edge.polargrid.ai
  • https://api.sfo-03.edge.polargrid.ai

Auto-Routing

The SDKs can automatically select the fastest region:

Explicit Region Selection

You can specify a region by ID or alias:

Region Aliases

For convenience, these aliases are supported: The -02 variants (e.g. yul-02, nyc-02, dfw-02) and lax-01, sea-01, chi-01, phx-01, was-01, mia-01, sfo-03 are reachable only by explicit region ID — they have no alias.

Checking Latency

CLI

SDK

Auto-routing logs latency when debug is enabled:

Default Region

If you don’t specify a region and don’t use auto-routing, the SDKs default to Toronto (yto-01). For CLI, you can set a default:

Health Checks and Fallback

Checking Region Health

Each edge node exposes a /health endpoint:
A healthy response includes the node ID, runtime info, and loaded models. Use this to verify a region is operational before pinning traffic to it.

Autorouter Discovery

The autorouter returns the single best edge for the caller. It detects the caller’s country (from request geo) and returns the nearest edge in that country — a US caller is routed to the nearest US edge, a Canadian caller to the nearest Canadian edge — even when an edge across the border is physically closer. If no healthy edge exists in the caller’s country, it falls back to the globally nearest edge.
The endpoint field is the base URL you POST inference to. The ttl (seconds) is a hint for how long the SDK should cache the choice before re-asking.

Fallback Strategy

If you’re pinning to a specific region (not using auto-routing), we recommend this fallback pattern:
  1. Primary: Your chosen region (e.g., yto-01)
  2. Fallback: Try the next-closest region if the primary returns 5xx or times out
  3. Auto-route: Fall back to PolarGrid.create() which calls the autorouter
For most use cases, PolarGrid.create() is the best option — it handles region selection and failover automatically. Only pin to a specific region if you need deterministic routing for compliance or latency guarantees.

Direct API Access

For raw HTTP requests, use the full endpoint: