> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thornode.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Locations

> Select, configure, and fail over between the ThorNode locations enabled for your access.

Use this page when you need to choose a ThorNode location, move a workload, or prepare regional failover. Keep each target paired with the credential shown for the same access and location, then test it from the application runtime.

<Note>
  The dashboard lists the locations available for the selected pass or rental,
  product, and network.
</Note>

## Choose and verify a location

<Steps>
  <Step title="Select the exact access">
    In the dashboard, choose the pass or rental, product, and network that the
    application will use.
  </Step>

  <Step title="Choose an enabled location">
    Start with the available location nearest your application infrastructure.
    Test from the application host and compare latency before making the final
    choice.
  </Step>

  <Step title="Copy the matching configuration">
    Copy the target and credential from the same dashboard location. Do not
    assemble a target manually or combine values from different locations.
  </Step>

  <Step title="Test from the application runtime">
    Run one low-impact request, connection, or subscription from the network
    that will carry production traffic. Confirm authentication succeeds and
    measure the latency and stability relevant to your workload.
  </Step>
</Steps>

Use the public hostname exactly as displayed. Do not replace it with a resolved IP address: TLS certificates, routing, and service addresses can change independently of DNS. Never use an internal URL or raw infrastructure address found in logs or source code.

## Apply location scope correctly

| Configuration              | Location behavior                                                                                                                                                                                                      |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ThorEdge RPC and WebSocket | The target and token are location-bound and must be copied together.                                                                                                                                                   |
| Yellowstone gRPC           | The dial target and `x-token` credential must belong to the same location.                                                                                                                                             |
| Pulse Decoded Shreds       | The QUIC target and control-message token must belong to the same location.                                                                                                                                            |
| Bifrost Transaction Routes | The dashboard reuses one Private TX key for the selected access across its enabled Bifrost location URLs. Copy each provider route URL from the intended location; ThorNode manages the upstream provider credentials. |
| Raw Shred Stream           | The registration selects the ThorNode location that sends UDP to your receiver.                                                                                                                                        |
| Replay                     | Replay has a per-access key; each job supplies its own UDP receiver target.                                                                                                                                            |

See [Security](/reference/security#credential-scope-and-placement) for where each credential belongs and how to store it.

## Account for network direction

An RPC IP restriction matches the client's **public egress IPv4 address** after NAT, a cloud gateway, VPN, or proxy. Verify the address from the production runtime before saving a restriction.

Raw Shred Stream and Replay send UDP in the other direction, from ThorNode to a public receiver you operate. The configured address and port must be reachable through the receiver's firewall, security group, and NAT rules. Raw Shred Stream registration requires a public IPv4 address; [prepare and test the receiver](/products/raw-shred-stream/quickstart) before registering it.

## Move a workload to another location

1. Confirm the destination is enabled for the same access, product, and network.
2. Prepare the destination according to its scope:
   * For ThorEdge, Yellowstone, or Pulse, copy the destination target and location token together.
   * For Bifrost, select the destination in **Private TX** and copy the provider route URL shown there. The access key remains the same, but the location URL changes.
   * For Raw Shred Stream, create the receiver registration for the destination location; packets do not use a customer credential.
   * Replay uses its per-access key and job flow rather than a location-token pair.
3. Add the destination as separate configuration or registration. Do not edit only a hostname in an existing target.
4. Test a low-impact operation and observe the new path before moving production traffic.
5. Keep the old path through the rollback window, then remove stale registrations and revoke credentials that are no longer needed.

Regenerating or revoking one ThorEdge location token does not affect other locations. For a credential exposure, follow the [rotation procedure](/reference/security#rotate-or-revoke-a-credential) instead of treating a regional move as sufficient remediation.

## Prepare regional failover

* For location-bound products, keep each target paired with its own location credential. Keep Raw Shred registrations and Replay job configuration separate from those credentials.
* Confirm the backup location is currently enabled for the access and product.
* Test authentication and one representative operation before an incident.
* Use bounded retries with backoff and jitter to prevent reconnect storms.
* Decide how streaming consumers will detect and reconcile gaps after reconnecting.
* Load the location catalog from configuration instead of compiling it into application code.

If a location disappears or a copied target stops working, refresh the dashboard first, then use the [symptom-based checks](/reference/troubleshooting#connection-dns-or-tls-fails).

## Next steps

* [Check the products and limits granted to an access](/reference/plans-and-limits)
* [Store and rotate credentials safely](/reference/security)
* [Diagnose connection and authentication failures](/reference/troubleshooting)