Running - Stellar Developer Docs

Starting Your Node

Once you’ve set up your environment, configured your node, set up your quorum set, and selected archives to get history from, you’re ready to start Stellar Core. Use a command equivalent to:

sudo systemctl start stellar-core

At this point, you’re ready to observe your core node’s activity as it joins the network. You may want to skip ahead and review the Logging page to familiarize yourself with Stellar Core’s output.

Interacting With Your Instance

When your node is running, you can interact with Stellar Core via an administrative HTTP endpoint. Commands can be issued using command-line HTTP tools such as curl, or by running a CLI command such as

sudo -u stellar stellar-core --conf /etc/stellar/stellar-core.cfg http-command <http-command>

The HTTP endpoint is not intended to be exposed to the public internet. It’s typically accessed by administrators, or by a mid-tier application to submit transactions to the Stellar network. Details of available HTTP endpoint commands can be found in the stellar-core-GitHub repo. Additionally, the commands page contains an overview of some of the most useful CLI commands (non-HTTP commands) for managing a running core node.

Joining the Network

Your node will go through the following phases as it joins the network, and you can query for the output below by using the info endpoint mentioned here :

Establish Connection to Other Peers.

You should see authenticated_count increase.

"peers" : {
  "authenticated_count" : 3,
  "pending_count" : 4
},

Observing Consensus

Until the node sees a quorum, it will say:

"state" : "Joining SCP"

After observing consensus, a new field quorum will display information about network decisions. At this point the node will switch to a “Catching up” state:

"quorum" : {
  "qset" : {
    "ledger" : 22267866,
    "cost" : 20883268,
    "agree" : 5,
    "delayed" : 0,
    "disagree" : 0,
    "fail_at" : 3,
    "hash" : "980a24",
    "lag_ms" : 430,
    "missing" : 0,
    "phase" : "EXTERNALIZE"
  },
  "transitive" : {
    "intersection" : true,
    "last_check_ledger" : 22267866,
    "node_count" : 21
  }
},
"state" : "Catching up",

Catching up

This is a phase where the node downloads data from any configured archives. This phase begins with something like:

"state" : "Catching up",
"status" : [ "Catching up: Awaiting checkpoint (ETA: 35 seconds)" ]

And will then move through the various phases of downloading and applying state, such as:

"state" : "Catching up",
"status" : [ "Catching up: downloading ledger files 20094/119803 (16%)" ]

For the fastest sync — including for new Full Validators and Tier 1 candidates — leave CATCHUP_RECENT at its default and do not set CATCHUP_COMPLETE=true. Your node will sync against current network state in minutes to hours rather than weeks. CATCHUP_COMPLETE=true makes the node replay the entire history of the network on startup, which takes weeks and is almost never the right choice for a validator — see Why local disk stays bounded. The standard pattern for new validators that want to publish a complete history archive is to sync against current state first, publish forward from that point, and use the stellar-archivist mirror tool to backfill historical data into the published archive as a separate offline operation. See the complete example configuration for more details.

The CATCHUP_COMPLETE and CATCHUP_RECENT config fields are mutually exclusive. If the CATCHUP_COMPLETE field is set to true, the CATCHUP_RECENT field will be ignored.

Synced

When the node is done catching up, its state will change to:

"state" : "Synced!"

​Starting Your Node

​Interacting With Your Instance

​Joining the Network

​Establish Connection to Other Peers.

​Observing Consensus

​Catching up

​Synced

Starting Your Node

Interacting With Your Instance

Joining the Network

Establish Connection to Other Peers.

Observing Consensus

Catching up

Synced