Installation

There are three ways to install Stellar 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 Stellar 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.

The SDF maintains a quickstart image that bundles Stellar 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 Stellar-Core-only standalone image that starts a 3 node local stellar-core network, all on the same docker host

In addition to the SDF images, Satoshipay maintains Docker separate images for Stellar Core and Horizon. The Satoshipay Stellar 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.

If you are using Ubuntu 16.04 LTS, we provide the latest stable releases of stellar-core and stellar-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 stellar-quickstart package which configures a Testnet stellar-core and stellar-horizon both backed by a local PostgreSQL database. Once installed you can easily modify either the Stellar Core configuration if you want to connect to the public network.

See the install from source for build instructions.

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.