Home | Core


Getting Started




Command Line Interface (CLI)




How-To Guides

Upgrade Guides

Release Guides

V3 Testing


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.js, delegates.json and peers.json files of the respective network you are using.

Service Configuration

Services are the building blocks that make up all of the internals of Core that make it possible for it to do what it does. Think of things like logging, caching, events and task scheduling; all of those are necessary for Core to function but they aren’t plugins so how do we configure them?

module.exports = {
    services: {
        log: {
            levels: {
                console: process.env.CORE_LOG_LEVEL || "emergency",
                file: process.env.CORE_LOG_LEVEL_FILE || "emergency",
            fileRotator: {
                interval: "1d",

As you can see the configuration format is quite simple. We have a services key that serves as a namespace for all of our service specific configuration. Then we can see the log key, internally the log service will look for this key and use its value to configure things like log rotations and what severity messages go to which output stream.

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

module.exports = {
    plugins: [{
        package: "@arkecosystem/core-state"
        package: "@arkecosystem/core-database"
        package: "@arkecosystem/core-transaction-pool"
        package: "@arkecosystem/core-p2p",
        options: {
            minimumNetworkReach: 5,
        package: "@arkecosystem/core-blockchain"

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

The package key will be used by Core to decide what package should be loaded, this can be either an npm package name or path to a local package. The options key will be used to configure the services that are provided by the plugin.

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.






Those are just a few of the possible environment variables, check the Core repository 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.

2020 © ARK.io | All rights reserved | An ARK.io Product