Configuration Service

The Configuration Service receives the deployment’s configuration — chain parameters, feature flags, and branding — validates it, and distributes it to the indexing engine, backend, and frontend. A misconfigured chain ID or RPC endpoint is the most common cause of a broken deployment, so this service validates aggressively at startup.


Overview

Configuration is defined in environment files and a deployment config file, then loaded in a strict order:

  1. Defaults — shipped with the release.
  2. Deployment config — chain ID, RPC endpoints, native coin symbol, network name.
  3. Branding config — display name, logo, colors, custom domain (see Branding & Configuration).
  4. Secrets — database credentials and API keys, injected via the environment.

Invalid or missing required values fail startup with a clear error rather than running in a broken state.

Configuration Flow

config files + env ──► Configuration Service ──► validation
┌───────────────────┼───────────────────┐
▼ ▼ ▼
Indexing Engine Backend/API Frontend

Each service reads its slice of configuration at boot. Services refuse to start on schema mismatches, which surfaces configuration errors immediately during deployment.

Reloading Configuration

  • Chain parameters and branding — require a service restart; restart order is frontend → backend → indexer.
  • Rate limits and feature flags — applied on restart of the backend only.
  • Always restart during a maintenance window and verify afterwards (see Explorer Verification).

Environment Variables

Keep secrets out of version control. Typical .env layout:

Terminal window
# Chain
CHAIN_ID=50
ETHEREUM_JSONRPC_HTTP_URL=http://chain-node:8545
ETHEREUM_JSONRPC_TRACE_URL=http://chain-node:8545
# Database (secret)
DATABASE_URL=postgresql://explorer:****@postgres:5432/explorer_db
# Branding
NEXT_PUBLIC_NETWORK_NAME="Your Chain"
NEXT_PUBLIC_NETWORK_COIN=XYZ

Multi-Chain Deployments

Hosting explorers for several chains means one configuration set per chain, each with its own database and services. Keep per-chain config in separate directories and manage them independently — one chain’s upgrade should never touch another’s.