> ## Documentation Index
> Fetch the complete documentation index at: https://developers.stellar.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Running

> Starting Your Node

## Starting Your Node

Once you've [set up your environment](https://developers.stellar.org/docs/validators/admin-guide/prerequisites.md), [configured your node](https://developers.stellar.org/docs/validators/admin-guide/configuring.md), set up your [quorum set](https://developers.stellar.org/docs/validators/admin-guide/configuring.md#choosing-your-quorum-set), and selected archives to `get` [history from](https://developers.stellar.org/docs/validators/admin-guide/environment-preparation.md#history-archives), you're ready to start Stellar Core.

Use a command equivalent to:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
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](https://developers.stellar.org/docs/validators/admin-guide/logging.md) 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

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
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](https://developers.stellar.org/docs/validators/admin-guide/prerequisites.md#internal-system-access). 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](https://github.com/stellar/stellar-core/blob/master/docs/software/commands.md#http-commands). Additionally, [the commands page](https://developers.stellar.org/docs/validators/admin-guide/commands.md) 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](https://developers.stellar.org/docs/validators/admin-guide/monitoring.md#general-node-information) :

### Establish Connection to Other Peers.

You should see `authenticated_count` increase.

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
"peers" : {
  "authenticated_count" : 3,
  "pending_count" : 4
},
```

### Observing Consensus

Until the node sees a quorum, it will say:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
"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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
"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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
"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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
"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](https://developers.stellar.org/docs/validators/admin-guide/prerequisites.md#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`](./publishing-history-archives#mirroring-an-archive) tool to backfill historical data into the published archive as a separate offline operation. See the [complete example configuration] for more details.

> [!NOTE]
>
> 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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
"state" : "Synced!"
```

[complete example configuration]: https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg