Self-hosted gateway
Run the gateway in your own data center. Routing, scoring, circuit breaking, and metering work exactly as they do on the public gateway. Point it at your own nodes only, or at yours first with public fallback. Either way it scales out automatically during peaks and incidents.
ChainBridge never asks for your private key or seed phrase. In a self-hosted deployment, your node credentials stay in your own secrets manager.
Why self-host
When regulation requires data to stay inside your network, or node costs need fine-grained allocation, a public gateway is no longer enough.
Data never leaves your network
Requests and responses stay on your network; ChainBridge never sees your payloads and receives only optional aggregate metrics.
Costs can be allocated
Report usage and cost by internal business line, chain, and method for chargeback and capacity planning.
The same observability
Health scoring, routing decision logs, circuit-breaker records, and alert definitions match the public gateway — no new runbooks to learn.
Versioning and rollback
Routing policies carry version numbers and validity windows; config changes are audited and past versions remain queryable. Rollback still requires deploying a specific version by hand — the console has no one-click rollback button yet, and we don't present it as an existing feature.
Offline degradation
If it loses its connection to the platform, the gateway follows predefined rules to reject requests or degrade to a limited mode; it never treats stale config as current.
Audit logging
Key operations are always audited. Two-person approval currently covers incident publishing and auto-revoke rules; approval gating for routing, rate limiting, and key changes is still being integrated, so add a manual approval step in your own risk process before deployment.
How a request flows through the gateway
Config and metering are never lost, and the gateway scales horizontally.
① Ingress and authentication
Validates API key digests, IP allowlists, and quotas, then rate-limits per key; only the SHA-256 digest and prefix are stored, never the plaintext.
② Routing and selection
Picks candidate nodes by chain and method, scores them on live health, block height, and latency, and logs why each node was chosen.
③ Execution and validation
Forwards the request, handles batch arrays, and cross-validates sources when needed; on failure it switches to the next node while the samerequestId stays unchanged.
④ Metering and reporting
Metering events go into a local persistent queue before being reported to the platform; failed reports are retried automatically and never lost.
⑤ Observability and alerting
Exposes Prometheus metrics and structured logs, removes unhealthy nodes automatically, and raises alerts.
⑥ Configuration sync
Config syncs as snapshots with version numbers and validity windows; rollback does not require restarting every replica.
Platform component status
This is platform-side status and does not mean your local deployment has passed its checks.
Deployment modes and dependencies
- Deployment mode
- Single-node container (PoC) / Kubernetes (production) / bare metal (low latency)
- Runtime
- Single Go binary with no external runtime dependencies; the image can be imported offline
- Config storage
- Local config file + platform config snapshots (versioned, with rollback)
- Persistence
- Metering data needs a local persistent volume; SSD recommended with a 7-day buffer
- Observability
- Prometheus metrics endpoint, structured logs, liveness and readiness probes
- Network requirements
- Outbound access to upstream nodes and the platform; inbound only needs the gateway port exposed
- Secret management
- Upstream credentials are injected via environment variables and never stored in the gateway; Vault / KMS integration is deployment-time work
Launch process
Once a platform disconnect exceeds the agreed window, the gateway defaults to serving only already-authorized keys and refusing new quota instead of continuing at full volume. Confirm the exact rules with your team before deployment and write them into the config.
Enterprise deployment questions
Core capabilities are the same: routing, health scoring, circuit breaking, rate limiting, metering, and observability all come from the same source. Two differences: you configure the node list yourself, and features that depend on ChainBridge public data — such as automatic scaling from public providers — must be enabled explicitly.
It keeps serving from the last valid config and caches metering events locally; when the network comes back, they are reported and deduplicated automatically, so nothing is billed twice.
Any EVM node that speaks standard JSON-RPC works, along with Solana RPC and gRPC endpoints. ChainBridge public networks can serve as a fallback source.
SLAs and support windows are agreed per contract and depend on the deployment mode and upstream sources. If ChainBridge public networks are used as fallback, that part follows the public status page's metrics.
Not by default. The gateway reports only aggregate metrics (request counts, CU, latency percentiles, error rates) for billing and support; request and response bodies never leave your network unless you explicitly enable debug reporting.
Need a private deployment?
Tell us your network scope, compliance requirements, and peak volume, and we will recommend a deployment mode and SLA.