# Configure, Run, and Set Up a Service
You have prepared your machine to be part of the upcoming network. Now it is time to:
- Configure the rest of the software.
- Start the software and have it establish a peer-to-peer (P2P) network with others.
Start by putting
/usr/local/bin, or into whichever path you put your executables. Confirm it works with:
In the previous section, you configured some parameters of your node when it comes to CometBFT, in
config/app.toml, you will find other parameters to configure. Take special note of
halt-height which assists you in gracefully stopping the node, such as when applying a migration.
As for the database(s), classic considerations apply. With the
db_dir flag, consider storing its files in a dedicated and redundant volume. On Linux, you could mount the
data folder to that separate drive.
Events are also stored in a database, and here too you can choose to store them separately. Note that events are purely a node concern, not a consensus or network one.
# Run user
Another standard security concern is that you want to avoid running your application as
root. So, create a new user and prepare it:
With this done, move the configuration folder to the home folder of the new user:
To finally launch your software, you could simply run:
The larger your genesis file, the longer this step takes. Do not worry if it seems like nothing is happening.
# As a service
Instead of relaunching your software every time, it is a good idea to set it up as a service. You can use your preferred method, but if you are on Linux it may be with
systemd. Here is an example of a service file, modeled on Gaia's (opens new window), to save in
Check the section on migrations to see how you may add parameters to this file if you want to use Cosmovisor.
Enable it once:
Now, if you do not want to try a computer restart, you can start the process immediately with:
# When to start
You have launched your blockchain software, and the other validators have done the same, so when is the first block minted? This happens when validators representing at least two-thirds (opens new window) (67%) of the total staked amount are online.
This means that, although you should coordinate with your peers for a convenient date and time to start, you need not narrow it down to the second. You can collectively agree to all start on Tuesday and it will therefore start safely at some point on Tuesday.
However, this is another reason why, when adding staking transactions in the genesis, you need to be sure about the reliability of the other validators, otherwise your start could be delayed.
# Further concerns
Now that you have a running network, you may consider coming back to it and try to:
- Make your life easier with shell command completion (opens new window).
- Add a node that checks invariants (opens new window).
- Add telemetry (opens new window) so as to keep an eye on your node(s).
- See what other projects (opens new window) can benefit you.
This is just an extract of the different customizations that are available to you. For more ideas, peruse this documentation (opens new window).
When your network has been running sufficiently to be considered "established", your next steps are to advertise it and facilitate its eventual integration within the ecosystem. A good way to achieve this is to open a pull request on the chain registry repository (opens new window) with
assetlist.json files that describe your chain in a systematic way. Make sure that your JSON files follow the given schemas, for instance by checking with this online validator (opens new window).
To summarize, this section has explored:
- How to configure other software necessary to be part of a network.
- How to start the software and establish a P2P network with other nodes.
- The importance of avoiding running your application as a user (rather than as
root) for security reasons.
- How to set up your software as a service, to avoid the need to repeatedly relaunch it.
- How to coordinate with your peers regarding when to start your network to ensure timely behaviour.