Skip to main content
Treat every ThorNode token, route credential, replay key, and credential-bearing endpoint URL as a secret. Keep each secret on a trusted server, place it only where that product expects it, and track every consumer so you can rotate it safely. Wallet private keys and seed phrases are never ThorNode support credentials. Never share them with ThorNode or anyone claiming to troubleshoot your access.

​
Credential scope and placement

Do not move a credential into a URL, header, query parameter, or control message unless the product row requires it. Copy location-bound targets and credentials together; see Locations when moving a workload.

​
Store secrets outside code

Inject production values through a secret manager or deployment environment. A committed .env.example should contain placeholders only:
Exclude real .env files, secret-manager exports, wallet files, and generated production configuration from version control.
Removing a committed secret in a later commit does not remove it from Git history. Rotate the exposed credential first, then use your repository provider’s history-remediation procedure.

​
Keep complete URLs private

ThorEdge supplies complete URLs containing authentication material. A copied Bifrost route URL also contains the Private TX key. Use these values exactly as provided, but redact the entire URL anywhere an untrusted party could see it, including:
  • Browser and mobile application bundles
  • Repositories, issues, CI output, and build artifacts
  • Logs, traces, analytics, and crash reports
  • Screenshots, recordings, and support messages
  • Shared shell history, process listings, and command output
  • Browser navigation that could emit a referrer header
For diagnostics, keep only the product, location, time, status code, and hostname when the hostname itself contains no credential. Redact credential paths as well as query parameters.

​
Verify transport and network controls

  • Prefer the https:// and wss:// targets supplied by the dashboard.
  • Yellowstone currently uses plaintext gRPC. Keep the token in x-token metadata and carry the connection through a trusted private network, VPN, or encrypted tunnel.
  • Official Pulse clients validate the certificate chain and target hostname by default. Keep verification enabled, use the dashboard hostname, and add a private CA explicitly when your environment requires one.
  • Bifrost route URLs must use https:// and reject requests with a missing or invalid Private TX key. ThorNode manages the upstream provider credential; do not add or expose a provider API key.
  • Keep public hostnames intact; substituting a resolved IP can break TLS validation and routing.
  • Restrict a ThorEdge location token to a stable public egress IPv4 address when the dashboard offers that control.
  • Restrict inbound Raw Shred Stream and Replay UDP traffic with host firewalls, cloud security groups, and trusted source ranges.
An IP restriction reduces where a token can be used; it does not make a leaked token safe. Continue to store and redact it as a secret.

​
Rotate or revoke a credential

Regenerate a credential when the application still needs access but the current value may be exposed or its owner changes. Revoke it when the consumer no longer needs access. A ThorEdge regeneration or revocation invalidates the old token for that location; other location tokens are unaffected. Plan for an immediate cutover. Old and new values may not overlap, and a previously authenticated streaming connection can remain open until it disconnects or the service closes it.
1

Inventory consumers

Identify the access, product, network, location, services, jobs, and secret stores that use the credential. Include long-lived streaming clients.
2

Prepare the replacement

Stage the configuration update and a minimal verification operation without placing the value in source code, logs, or a command transcript.
3

Regenerate or revoke

Use the credential-specific dashboard control. For Bifrost, revoke the Private TX key and generate a replacement, then verify the old URL is rejected before treating rotation as complete. For Replay, use its dedicated key control. Contact support when the applicable safe control is not available.
4

Deploy and verify

Update the secret store, restart or reload every consumer, and verify one authenticated operation. Restart long-lived streams so they cannot continue on an earlier authentication state.
5

Remove residual copies

Purge the old value from local files, CI variables, caches, logs, tickets, and artifacts where possible.

​
Respond to suspected exposure

  1. Regenerate or revoke the affected credential immediately.
  2. Stop public logs, builds, pages, or artifacts from distributing it.
  3. Review dashboard usage and available access logs for unexpected traffic.
  4. Replace the value in every legitimate consumer and restart long-lived sessions.
  5. Remove cached copies and remediate repository history where necessary.
  6. Contact ThorNode support with the access identifier, product, location, and exposure window—never the secret.
Use the safe support checklist when reporting an incident.

​
Next steps