installation

There are three ways to install Bantu Core: you can use a Docker image, use pre-built packages, or build from source. Using a Docker image is the quickest and easiest method, so it's a good choice for a lot of developers, but if you're running Bantu Core in production you may need to use packages or, if you want to sacrficie convenience for maximum control, build from source. Whichever method you use, you should make sure to install the latest release since releases are cumulative and backwards compatible.

Docker-based installation

The SDF maintains a quickstart image that bundles Bantu Core with Horizon and postgreSQL databases. It's a quick way to set up a default, non-validating, ephemeral configuration that should work for most developers.

The SDF also maintains a Bantu-Core-only standalone image that starts a 3 node local bantu-core network, all on the same docker host

In addition to the SDF images, SatoshiPay maintains Docker separate images for Bantu Core and Horizon. The SatoshiPay Bantu Core Docker image comes in a few flavors, including one with the AWS CLI installed and one with the Google Cloud SDK installed. The Horizon image supports all Horizon environment varilables.

Package-based Installation

If you are using Ubuntu 16.04 LTS, we provide the latest stable releases of bantu-core and bantu-horizon in Debian binary package format.

You may choose to install these packages individually, which offers the greatest flexibility but requires manual creation of the relevant configuration files and configuration of a PostgreSQL database.

Most people, however, choose to install the bantu-quickstart package which configures a Testnet bantu-core and bantu-horizon both backed by a local PostgreSQL database. Once installed you can easily modify either the Bantu Core configuration if you want to connect to the public network.

Installing from source

See the install from source for build instructions.

Release version

In general you should install the latest release bulds builds are backward compatible and are cumulative.

The version number scheme that we follow is protocol_version.release_number.patch_number where:

protocol_version is the maximum protocol version supported by that release (all versions are 100% backward compatible), release_number is bumped when a set of new features or bug fixes not impacting the protocol are included in the release, patch_number is used when a critical fix has to be deployed.