# Deploy Bootnode and Server

### Set up backbone peers

These **bootstrap/bootnode peers** can be used as `--initial_peers`, to connect new servers to the existing ones. They can also [serve as libp2p relays](https://docs.libp2p.io/concepts/circuit-relay/) for servers that lack open ports (e.g., because they are behind NAT and/or firewalls).

**To start a bootstrap peer, run this line in a tmux/screen shell:**

{% hint style="info" %}
**Note:** This runs without a connection to the blockchain with `--no_blockchain_rpc`.
{% endhint %}

{% code overflow="wrap" %}

```bash
subnet-dht-api \
--host_maddrs /ip4/0.0.0.0/tcp/31330 /ip4/0.0.0.0/udp/31330/quic \
--announce_maddrs /ip4/{your_ip}/tcp/31330 /ip4/{your_ip}/udp/31330/quic \
--identity_path bootnode.id \
--no_blockchain_rpc
```

{% endcode %}

**Once you run it, look at the outputs and find the following line:**

{% code overflow="wrap" %}

```
Mon 00 01:23:45.678 [INFO] Running a DHT instance. To connect other peers to this one, use --initial_peers /ip4/YOUR_ADDRESS_HERE/tcp/31337/p2p/QmTPAIfThisIsMyAddressGoFindYoursnCfj
```

{% endcode %}

The suggested method is to update the `.env` variable `PUBLIC_INITIAL_PEERS` list with the address from the bootnode. You can also provide this address as `--initial_peers` to servers or other backbone peers. If there is a risk that this peer goes down, you can launch additional hivemind-dht instances and provide multiple addresses. New peers will be able to join the swarm as long as at least one of their initial peers is alive.

#### Here are a few tips to help you set up:

* The `--host_maddrs` contains **libp2p multi-addresses** specifying a network protocol, IP address, and port. Learn more about them [here](https://docs.libp2p.io/concepts/addressing/).
  * If you want your swarm to be accessible outside of your local network, ensure that you have a **public IP address** or set up **port forwarding** correctly, so that your peer is reachable from the outside.
  * If you run your swarm in a local network only, it's fine not to have a public IP and ports as long as you use the local network's IP addresses everywhere.
  * You can specify `0.0.0.0` as the IP address, so that the script will listen to the IP addresses of your existing network interfaces.
* The `--identity_path` contains a peer's private key and defines the "/p2p/..." part of your peer's address (essentially, its public key).
  * Set `--identity_path` option to a file to ensure that your peer has the same identity each time you restart it. If the file doesn't exist, the script will generate a new private key and save it to the specified file.
  * Make sure each peer's identity is **unique**.
  * If you omit this option, the subnet template will generate a new identity each time a process is started.
    * In production, this is **not recommended** as other peers will not be able to verify your identity, and you will not pass the proof-of-stake mechanism.

### Start Server

Once the bootnode is running and the bootnode address is in the `.env` file, you can start your first server with:

{% hint style="warning" %}
When running a P2P network locally, where each peer uses the same IP address, **each peer MUST use separate ports**. i.e., the bootnode uses 31330, and the server uses 31331.

**In addition**, when starting a server, use different `--subnet_node_id`'s. There is a local mock SQLite database that mimics the blockchain when using `--no_blockchain_rpc` and will expect different node IDs.     
{% endhint %}

```bash
subnet-server-mock \
--host_maddrs /ip4/0.0.0.0/tcp/31331 /ip4/0.0.0.0/udp/31331/quic \
--announce_maddrs /ip4/{your_ip}/tcp/31331 /ip4/{your_ip}/udp/31331/quic \
--identity_path alith.id \
--subnet_id 1 --subnet_node_id 1 \
--no_blockchain_rpc
```

You can also use the argument `--initial_peers` instead of using the `.env` file.