#Configuring Mainsail

Mainsail provides a wide variety of ways to configure how it behaves, what plugins are used, who is forging and more. Each option is documented, so head over to the Mainsail repository and Mainsail Network Config repository . All of this configuration can be found in the app.json, crypto.json, validators.json and peers.json files of the respective network you are using.

#Plugins Configuration

Plugins are packages that expose services which expand or alter what Mainsail node is capable of doing, by default there are a few required plugins like the a database driver, transaction pool, peer communication and consensus.

 1{
 2    "plugins": [
 3        {
 4            "package": "@mainsail/validation"
 5        },
 6        {
 7            "package": "@mainsail/crypto-config"
 8        },
 9        {
10            "package": "@mainsail/crypto-validation"
11        },
12        {
13            "package": "@mainsail/crypto-hash-bcrypto"
14        },
15        {
16            "package": "@mainsail/crypto-signature-schnorr-secp256k1"
17        },
18        {
19            "package": "@mainsail/crypto-key-pair-ecdsa"
20        },
21        {
22            "package": "@mainsail/crypto-consensus-bls12-381"
23        },
24        {
25            "package": "@mainsail/crypto-address-base58"
26        },
27        {
28            "package": "@mainsail/crypto-wif"
29        },
30        {
31            "package": "@mainsail/serializer"
32        },
33        {
34            "package": "@mainsail/p2p"
35        },
36        {
37            "package": "@mainsail/api-transaction-pool"
38        },
39        {
40            "package": "@mainsail/processor"
41        },
42        {
43            "package": "@mainsail/validator-set-static"
44        },
45        {
46            "package": "@mainsail/validator"
47        },
48        {
49            "package": "@mainsail/proposer"
50        },
51        {
52            "package": "@mainsail/consensus"
53        },
54        {
55            "package": "@mainsail/webhooks"
56        },
57        {
58            "package": "@mainsail/bootstrap"
59        }
60    ]
61}

Again the configuration is quite simple. We have a plugins key that serves as a namespace for all of our plugin specific configuration, for each process type. Then we see a list of objects that all contain package key and an optional options key.

The package key is used by Mainsail to decide what package should be loaded, this can be either an npm package name or path to a local package.

#Plugin options

The options key is used to configure the services that are provided by the plugin. Provided options are merged with default package configuration that is loaded from “default.ts” file inside the package.

Keys that are type of object will be merged with default configuration. String, number, boolean and array keys, will replace default configuration key.

1{
2    "package": "@mainsail/logger-pino",
3    "options": {
4        "fileRotator": {
5            "interval": "2d"
6        }
7    }
8},

#Validator Configuration

The validator configuration is responsible for providing the information that is necessary to know who should be forging on a server. This can either be a list of plaintext bip39 passphrases or a bip38 encrypted passphrase that is protected with a password. Configuration is stored inside validators.json file.

1{
2    "secrets": [
3        "validator mnemonic"
4    ]
5}

#Peer Configuration

The peer configuration is responsible for providing the information that is necessary to know who the seeds are so that we can retrieve a list of peers from them and start communicating with the network. By default it ships with a list of seeds and an additional list of sources on GitHub which is loaded when Core starts. Configuration is stored in peers.json file.

#Environment Configuration

Sometimes it can be beneficial or even necessary to have different configuration values per environment you are working with. An example would be where you are testing a new feature to improve database query or caching performance, in those cases you don’t want to be bound to the settings of the production network but run with your own values and modifications.

 1CORE_LOG_LEVEL=info
 2CORE_LOG_LEVEL_FILE=debug
 3 
 4CORE_P2P_HOST=0.0.0.0
 5CORE_P2P_PORT=4000
 6 
 7CORE_API_HOST=0.0.0.0
 8CORE_API_PORT=4003
 9 
10CORE_WEBHOOKS_HOST=0.0.0.0
11CORE_WEBHOOKS_PORT=4004

Those are just a few of the possible environment variables, check the Environment Variables to get a full list of available environment variables and make sure to check out dotenv and sindresorhus/env-paths to get a better understanding of what is happening under the hood.

Your changes to the .env file should not be committed to your git repository, since each server could require a different environment configuration.