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 |
|
--rpc-methods | Safe/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 |
--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. | 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) |