You can install Bantu Core a number of different ways, and once you do, you can configure it to participate in the network on several different levels: it can be a Watcher, a Basic Validator, or a Full Validator. No matter how you install Bantu Core or what kind of node you run, however, you need to set up to connect to the peer-to-peer network, store the state of the ledger in a SQL database, and most likely connect to expansion, the Bantu API.
Bantu Core with PostgreSQL running on the same machine worked well on a m5.large in AWS (dual-core 2.5 GHz Intel Xeon, 8 GB RAM). Storage-wise, 20 GB was enough for now, but the ledger will grow over time.
Bantu Core is designed to run on relatively modest hardware so that a whole range of individuals and organizations can participate in the network, and basic nodes should be able to function pretty well without tremendous overhead. That said, the more you ask of your node, the greater the requirements.
- Outbound: a Bantu Core needs to connect to other nodes via thier
PEER_PORTs TCP. But most use the default port, which is, again, 11625.
Bantu Core also needs to connect to certain internal systems, though exactly how varies based on your setup.
- Bantu Core requires access to a postgreSQL database. If that databse resides on a different machine on your network, you'll need to allow that connection. You specify the databse when you configure Bantu Core.
- You can block all other connections.
- Inbound: Bantu Core exposes an unauthenticated HTTP endpoint on its
HTTP_PORT. You can specify a port when you configure bantu Core, but most people use the default, which is 11626.
Note: if you need to expose your HTTP endpoint to other hosts in your local network,we recommended using an intermediate reverse proxy server to implement authentication. Don't expose the HTTP endpoint to the raw and cruel open internet.