docs: document seed env vars

docs/environment-variables.md

@@ -106,6 +106,19 @@ A comma-separated list of [multiaddresses](https://docs.libp2p.io/concepts/funda
 
 Default: not set (no peering)
 
+### `RAINBOW_SEED`
+
+Base58 seed to derive PeerID from. Can be generated with `rainbow gen-seed`.
+If set, requires `RAINBOW_SEED_INDEX` to be set as well.
+
+Default: not set
+
+### `RAINBOW_SEED_INDEX`
+
+Index to derivate the PeerID identity from `RAINBOW_SEED`.
+
+Default: not set
+
 ### `RAINBOW_SEED_PEERING`
 
 Automated version of `RAINBOW_PEERING` which does not require providing multiaddrs.
@@ -120,21 +133,24 @@ Default: `false` (disabled)
 ### `RAINBOW_SEED_PEERING_MAX_INDEX`
 
 Informs the largest index to derive for `RAINBOW_SEED_PEERING`.
+If you have more instances than the default, increase it here.
 
 Default: 100
 
 ### `RAINBOW_PEERING_SHARED_CACHE`
 
-Enable sharing of local cache to peers safe-listed with `RAINBOW_PEERING`.
+Enable sharing of local cache to peers safe-listed with `RAINBOW_PEERING`
+or `RAINBOW_SEED_PEERING`.
 
 Once enabled, Rainbow will respond to [Bitswap](https://docs.ipfs.tech/concepts/bitswap/)
 queries from these safelisted peers, serving locally cached blocks if requested.
 
-The main use case for this feature is scaling and load balancing across a
-fleet of rainbow, or other bitswap-capable IPFS services. Cache sharing allows
-clustered services to check if any of the other instances has a requested CID.
-This saves resources as data cached on other instance can be fetched internally
-(e.g. LAN) rather than externally (WAN, p2p).
+> [!TIP]
+> The main use case for this feature is scaling and load balancing across a
+> fleet of rainbow, or other bitswap-capable IPFS services. Cache sharing allows
+> clustered services to check if any of the other instances has a requested CID.
+> This saves resources as data cached on other instance can be fetched internally
+> (e.g. LAN) rather than externally (WAN, p2p).
 
 Default: `false` (no cache sharing)