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

# Configure Boost upstreams

> Connect a provider account or custom RPC URL, manage credentials and fallback upstreams, and understand Boost's forwarding behavior.

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.

| Vendor     | Credential                                                                                                                           | What Boost does                                                                                                                |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |
| QuickNode  | An API key with **Admin API** access from Dashboard → API Keys. Paid plans only                                                      | Creates one dedicated endpoint per network in your account                                                                     |
| Alchemy    | An **access key** with read-and-write **App Management** permission from Dashboard → Settings → Security. This is not an app API key | Creates one dedicated app and enables every selected network on it                                                             |
| Chainstack | A Platform API key from Console → Settings → API keys. Available on every plan; your plan's node limit still applies                 | Creates one project with a Global Node for each selected network                                                               |
| dRPC       | A **NodeCloud Keys API** token from Settings → API Tokens. Do not use a Statistics API or NodeCore token                             | Reads your key list and points every selected network at an existing unrestricted key; it creates nothing in your dRPC account |

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.

<Note>
  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.
</Note>

### 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.

<Note>
  A network with no active upstream cannot serve traffic. Boost returns a JSON-RPC error instead of accepting a request it cannot forward.
</Note>

## 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:

| Header                          | Behavior                                                         |
| ------------------------------- | ---------------------------------------------------------------- |
| `X-ERPC-Secret-Token`           | Reserved by the edge and never forwarded                         |
| `Host`                          | Set from the upstream URL                                        |
| `Content-Type`, `Accept`        | Set to `application/json`                                        |
| `Content-Length`                | Recomputed for the forwarded request                             |
| `Accept-Encoding`               | Set to request gzip from the provider                            |
| `Content-Encoding`              | Removed because Boost sends an uncompressed request body         |
| `Cookie`, `Proxy-Authorization` | Removed instead of relaying session credentials to a third party |
| Hop-by-hop headers              | Removed because they apply to one connection only                |

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:

```text theme={"dark"}
https://edge.goldsky.com/boost/{chain}?key={your-goldsky-key}
```

With the Goldsky key in the URL, request headers such as `Authorization` and `X-API-Key` can be forwarded to your provider.

<Warning>
  Always include `?key=` when sending provider credentials as request headers. Without it, Boost cannot distinguish your provider credential from Goldsky authentication.
</Warning>

### 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](/getting-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:

| Header                           | Behavior                                                                                        |
| -------------------------------- | ----------------------------------------------------------------------------------------------- |
| `Content-Encoding`               | Removed after Boost inflates the provider response and negotiates client compression separately |
| `Content-Type`, `Content-Length` | Set for the response Boost sends                                                                |
| `Set-Cookie`                     | Removed so a provider cannot set a cookie on `edge.goldsky.com`                                 |
| `x-cache`, `x-edge-*`            | Replaced with Boost's own routing and timing headers                                            |
| `x-goldsky-*`                    | Removed because these are internal accounting headers                                           |
| `Access-Control-*`               | Replaced by CORS handling at the edge                                                           |
| Hop-by-hop headers               | Removed because they apply to one connection only                                               |

## 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](/getting-support) before relying on it.


## Related topics

- [Set up Boost](/boost/quickstart.md)
- [Cut RPC costs with Boost](/boost.md)
- [Troubleshoot Boost](/boost/troubleshooting.md)
- [Boost reference](/boost/reference.md)
- [How Boost routes requests](/boost/how-it-works.md)