#Configuring Core

ARK Core 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 ARK Core repository and dive in. All of this configuration can be found in the app.json, delegates.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 Core 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    "core": {
 3        "plugins": [
 4            {
 5                "package": "@arkecosystem/core-logger-pino"
 6            },
 7            {
 8                "package": "@arkecosystem/core-state"
 9            },
10            {
11                "package": "@arkecosystem/core-database"
12            },
13            {
14                "package": "@arkecosystem/core-transactions"
15            },
16            {
17                "package": "@arkecosystem/core-magistrate-transactions"
18            },
19            {
20                "package": "@arkecosystem/core-transaction-pool"
21            },
22            {
23                "package": "@arkecosystem/core-p2p"
24            },
25            {
26                "package": "@arkecosystem/core-blockchain"
27            },
28            {
29                "package": "@arkecosystem/core-api"
30            },
31            {
32                "package": "@arkecosystem/core-magistrate-api"
33            },
34            {
35                "package": "@arkecosystem/core-webhooks"
36            },
37            {
38                "package": "@arkecosystem/core-forger"
39            }
40        ]
41    },
42    "relay": {
43        "plugins": [
44            {
45                "package": "@arkecosystem/core-logger-pino"
46            },
47            {
48                "package": "@arkecosystem/core-state"
49            },
50            {
51                "package": "@arkecosystem/core-database"
52            },
53            {
54                "package": "@arkecosystem/core-transactions"
55            },
56            {
57                "package": "@arkecosystem/core-magistrate-transactions"
58            },
59            {
60                "package": "@arkecosystem/core-transaction-pool"
61            },
62            {
63                "package": "@arkecosystem/core-p2p"
64            },
65            {
66                "package": "@arkecosystem/core-blockchain"
67            },
68            {
69                "package": "@arkecosystem/core-api"
70            },
71            {
72                "package": "@arkecosystem/core-magistrate-api"
73            },
74            {
75                "package": "@arkecosystem/core-webhooks"
76            }
77        ]
78    },
79    "forger": {
80        "plugins": [
81            {
82                "package": "@arkecosystem/core-logger-pino"
83            },
84            {
85                "package": "@arkecosystem/core-forger"
86            }
87        ]
88    }
89}

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 Core 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": "@arkecosystem/core-logger-pino",
3    "options": {
4        "fileRotator": {
5            "interval": "2d"
6        }
7    }
8},

#Delegate Configuration

The delegate 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.

#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.

#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.

 1LOG_LEVEL=debug
 2LOG_LEVEL_FILE=debug
 3 
 4DB_HOST=localhost
 5DB_PORT=5432
 6DB_DATABASE=ark_mainnet
 7DB_USERNAME=ark
 8DB_PASSWORD=password
 9 
10P2P_HOST=0.0.0.0
11P2P_PORT=4000
12 
13WEBHOOKS_HOST=0.0.0.0
14WEBHOOKS_PORT=4004
15 
16API_HOST=0.0.0.0
17API_PORT=4003

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.