Skip to main content
Each Goldsky project has one Boost configuration and one Boost API key. For each enabled network, the configuration identifies the active upstream, provider credentials, allowed browser origins, and forwarding timeout.

​
Choose a setup path

​
Connect a provider account

Supply a management credential once and let Boost prepare upstreams for the networks you select. The exact action depends on the provider. For QuickNode, Alchemy, and Chainstack, Boost only modifies resources that it created. Disconnecting deletes those resources without changing your pre-existing endpoints, apps, projects, or nodes. Disconnecting dRPC only forgets the dashboard token and removes the upstreams assembled from it; nothing in your dRPC account changes.
A dRPC key restricted by IP, browser origin, JWT, network, or method cannot serve Boost’s forwarding path. Create or select an active, unrestricted key before connecting the account. Some dRPC networks require a paid plan.

​
Supply an RPC URL

You can use any endpoint reachable over public HTTPS, including a node you operate or a Goldsky Edge RPC endpoint. For each network, configure:
  • An upstream RPC URL
  • Any custom authentication headers required by the provider
  • Optional standby upstreams
  • An optional forwarding timeout
Only one upstream is active for a network at a time. Switching to a standby is an explicit configuration change, not automatic failover.
A network with no active upstream cannot serve traffic. Boost returns a JSON-RPC error instead of accepting a request it cannot forward.

​
Credentials

Provider URLs and configured headers are encrypted at rest. You can replace or remove them in the dashboard. If a URL contains user information such as https://user:pass@example.com, Boost converts it to an Authorization: Basic header before forwarding. The configured URL and headers are not written to logs, errors, or metrics. For provider credentials that do not change per request, prefer configured headers. Your callers then need only the Goldsky key.

​
Request and response forwarding

Boost preserves the JSON-RPC request body for calls sent upstream. As an HTTP proxy, it normalizes connection and transport headers on both sides of the request.

​
Headers sent to your provider

Your upstream receives caller-supplied headers plus the custom headers configured on the Boost endpoint. Configured headers are applied last and win when the same name appears in both places. Boost manages or removes these headers: Other headers pass through, including traceparent, tracestate, b3, baggage, User-Agent, and custom x-* headers.

​
Provider authentication headers

Put the Goldsky key in the query string:
With the Goldsky key in the URL, request headers such as Authorization and X-API-Key can be forwarded to your provider.
Always include ?key= when sending provider credentials as request headers. Without it, Boost cannot distinguish your provider credential from Goldsky authentication.

​
Caller IP

Boost relays the complete X-Forwarded-For chain. The final entry is the address observed by the Goldsky load balancer. Earlier entries are caller-supplied and should be treated as untrusted. X-Real-IP, Forwarded, CF-Connecting-IP, and True-Client-IP are relayed when the caller sends them. Boost does not set them itself. If your provider must not receive the caller address, contact support. Goldsky can disable X-Forwarded-For for an endpoint.

​
Headers returned to your client

Provider response headers such as Cache-Control, Retry-After, ETag, and custom x-* headers return to the client. Boost replaces or removes these response headers:

​
Browser access and CORS

Use the endpoint’s Allowed domains list to control browser access. Boost answers preflight requests and reflects an allowed origin. Provider CORS headers are not merged because they describe the provider’s origin rather than edge.goldsky.com. Credentialed browser requests using cookies or HTTP authentication are not allowed. Response headers are exposed to browser JavaScript, so applications can read x-cache and the other Boost headers through fetch or XMLHttpRequest.

​
Provider allowlists

Boost forwards from AWS Fargate tasks in us-east-1, us-west-2, and eu-central-1. Tasks use addresses from each region’s public AWS pool and can receive new addresses after deploys, scaling, or restarts. There is no fixed egress IP list. Authenticate Boost with a provider credential instead of an IP allowlist. If your provider supports only IP allowlisting, contact support before relying on it.