# Configuring Bootnodes in a Production Network

A network must have at least one operating bootnode. To allow for continuity in the event of failure, configure more than one bootnode.

We do not recommend putting bootnodes behind a load balancer. We recommend putting more bootnodes on the network itself.

The enode of a bootnode is tied to the node public key and IP address. To simplify recovering from complete bootnode failure:

1. Create the node key pair (that is, the private and public key) before starting the bootnode.
2. When creating bootnodes in the cloud (for example, AWS, Azure), attempt to assign a static IP to them. If your network is:

• Publicly accessible, assign an elastic IP.

• Internal only, specify a private IP address when you create the instance and record this IP address.

We recommend bootnode configuration is stored under source control.

## Specifying Bootnodes

To allow for failure, specify all bootnodes on the command line (even to the bootnodes themselves).

Example

If your network has 2 bootnodes, pass the following parameter to all nodes including the bootnodes.

--bootnodes=enode://<publicKeyBootnode1>@10.0.0.100:30303, <publicKeyBootnode2>@10.0.1.101:30303

Adding new bootnodes is a similar process to creating bootnodes. Once the bootnodes have been created and added to the network, update the --bootnodes command line option for each node to include the new bootnodes.
When bootnodes are added, running nodes don’t need to be restarted. Updating the --bootnodes option means the next time they are restarted (for example, when upgrading), the node connects to the new bootnodes.