Skip to main content
Skip table of contents

Dedicated Node Launch Arguments

Launch Arguments allow you to customise your dedicated node’s options and commands to your needs

Configuring Launch Arguments

When setting or editing a node’s launch arguments the panel on the left includes arguments which can be modified. The preview panel on the right shows all arguments as they will appear on the node; changes made to the customisable arguments will immediately be reflected in the preview pane.

Depending on the argument’s type it can be customised and will be included in the customisation panel. Arguments will display as a different colour in the preview pane depending on their type:

Configuration

Description

Customisable

Arguments shown in blue in the preview pane can be customised.

Boolean arguments can be removed by switching off the corresponding toggle on the left

When only the value is blue the value can be edited but the argument cannot be removed.

Network Controlled

Arguments shown in white in the preview pane have been locked by the network and cannot be customised.

System Generated

System Generated Arguments will display in grey in the preview pane.

A system generated argument while deploying a dedicated node

The same argument after the node has been deployed

Some system generated arguments, such as node key, can be optionally overridden when deploying the node. They cannot be updated once created.

Argument Groupings

Arguments are grouped together as follows, with the groups separated by a “--” line in the preview pane.

Launch Arguments

  • When running a standalone chain’s node, such as a relay chain validator, all launch arguments will be under a single grouping

Parachain Arguments

  • When running a Parachain node, such as a collator, the Parachain’s arguments will be grouped together here…

Relay chain Arguments

  • …while the Relay chain’s arguments will be here

Environment Rules

  • If the node requires certain values to be set on the environment you can enter them here

Outdated Arguments

If the network’s launch arguments have been updated the following alert will be shown on the Launch Configuration tab

Pressing edit will open the argument editor and a blue icon will highlight the change that has been made by the network. In this case, the argument --rpc-methods has been locked to Safe.

Press Save Changes to accept the changes after reviewing.

Your node will always be restarted after updating the launch arguments

Common Launch Arguments

Launch arguments are specific to the network that you are running a node for, so if you are unsure about a specific argument we recommend reviewing the network’s documentation.

Here are some common Substrate launch arguments.

When entering arguments in the Extra Args field, use the format Argument=Value

e.g. --rpc-cors=all

Argument

Value

Description

--rpc-cors

all/specific host

all will allow rpc requests from any host, secured by the OnFinality API key.

Set to a specific host to whitelist access.

--rpc-methods

Safe/Unsafe

Safe restricts access to only certain rpc methods.
Unsafe allows access to all RPC methods.

Refer to network specific documentation for a list of which methods are safe and unsafe.

--ws-external

boolean flag

Exposes web sockets, secured by the OnFinality node API key.

--rpc-external

boolean flag

Exposes RPC ports, secured by the OnFinality node API key.

--pruning

archive

When pruning mode is set to archive the node maintains the full block history, for example to run an archive node.

--prometheus-external

boolean flag

Exposes the metrics endpoint, found under API Endpoints and protected by the node’s OnFinality API Key. For parachains it can be added separately to the Parachain Arguments and Relay chain Arguments to expose both APIs.

--sync

warp

Quickly downloads the current chain state before back-filling the complete block history.

Especially useful when syncing a Polkadot or Kusama Parachain from 0 by setting the Relay Chain to use warp sync.

Not recommended for use in Validators or Collators

Common Environment Rules

The following arguments can help fine tune your node when experiencing issues such as restarts during setup and warp syncing

When entering arguments in the Extra Args field, use the format Argument=Value

e.g. BYPASS_HEALTHCHECKS="true"

Argument

Value

Description

BYPASS_HEALTHCHECKS

“true”

OnFinality constantly monitors nodes for signs of poor performance, such as a failure to produce new blocks during 5 minutes. It will then restart the node to try to remedy the issue.

In some cases, such as the initial sync, this behaviour can be problematic so we suggest bypassing health-checks if your node is restarting regularly during the initial sync.

Don’t forget to enable health-checks again when syncing has completed!

STARTUP_TIMEOUT

Milliseconds in quotes, e.g.

“1800000”

By default, nodes will be forcefully restarted if they are unable to load within 15 minutes.

If your node is failing during its initial sync or warp sync try setting the timeout to 30 minutes (1800000 milliseconds)

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.