Skip to main content

Prerequisites

You can install Stellar Core a number of different ways, and once you do, you can configure it to participate in the network on a several different levels: it can be either a Basic Validator or a Full Validator. No matter how you install Stellar Core or what kind of node you run, however, you need to set up and connect to the peer-to-peer network and store the state of the ledger in a SQL database.

Hardware Requirements​

info

CPU, RAM, Disk and network depends on network activity. If you decide to collocate certain workloads, you will need to take this into account.

At the time of writing (April 2024), Stellar Core with PostgreSQL running on the same machine worked well on a c5d.2xlarge instance in AWS (8x Intel Xeon vCPUs at 3.4 GHz; 16 GB RAM; 100 GB NVMe SSD (10,000 iops)).

Stellar Core is designed to run on relatively modest hardware so that a whole range of individuals and organizations can participate in the network, and basic nodes should be able to function pretty well without tremendous overhead. That said, the more you ask of your node, the greater the requirements.

Node TypeCPURAMDiskAWS SKUGoogle Cloud SKU
Core Validator Node8x Intel Xeon @ 3.4 GHz16 GB100 GB NVMe SSDc5d.2xlargen4-highcpu-8

* Assuming a 30-day retention window for data storage.

Network Access​

Stellar Core interacts with the peer-to-peer network to keep a distributed ledger in sync, which means that your node needs to make certain TCP ports available for inbound and outbound communication.

Inbound​

A Stellar Core node needs to allow all IPs to connect to its PEER_PORT over TCP. You can specify a port when you configure Stellar Core, but most people use the default, which is 11625.

Outbound​

A Stellar Core node needs to connect to other nodes on the internet via their PEER_PORT over TCP. You can find information about other nodes' PEER_PORTs on a network explorer like Stellarbeat, but most use the default port for this as well, which is (again) 11625.

Internal System Access​

Stellar Core also needs to connect to certain internal systems, though exactly how this is accomplished can vary based on your setup.

Inbound​

  • Stellar Core exposes an unauthenticated HTTP endpoint on its HTTP_PORT. You can specify a port when you configure Stellar Core, but most people use the default, which is 11626.
  • The HTTP_PORT is used by other systems (such as Horizon) to submit transactions, so this port may have to be exposed to the rest of your internal IP addresses.
  • It's also used to query Stellar Core info and provide metrics.
  • And to perform administrative commands such as scheduling upgrades and changing log levels
  • For more on that, see commands
Note on exposing the HTTP endpoint

If you need to expose this endpoint to other hosts in your local network, we strongly recommended you use an intermediate reverse proxy server to implement authentication. Don't expose the HTTP endpoint to the raw and cruel open internet.

Outbound​

  • Stellar Core requires access to a database (PostgreSQL, for example). If that database resides on a different machine on your network, you'll need to allow that connection. You'll specify the database when you configure Stellar Core.
  • You can safely block all other connections.

Storage​

Most storage needs come from stellar-core's database backend, which needs to store the entire ledger state. For the most part, the contents of both the database and related directories (such as buckets) can be ignored, since they are completely managed by Stellar Core. In terms of storage space, 100 GB is enough (as of April 2024).

Database​

The database is consulted during consensus, and modified atomically when a transaction set is applied to the ledger. It's random access, fine-grained, and fast.

As of August 2024, Stellar Core officially switched to BucketListDB as its primary database backend. Note that BucketListDB still requires SQL database, either SQLite or Postgres (recommended).

If you're using PostgreSQL, we recommend you configure your local database to be accessed over a Unix domain socket, as well as updating the below PostgreSQL configuration parameters:

# !!! DB connection should be over a Unix domain socket !!!
# shared_buffers = 25% of available system ram
# effective_cache_size = 50% of available system ram
# max_wal_size = 5GB
# max_connections = 150

Buckets​

Stellar-core stores ledger state in the form of flat XDR files called "buckets." The bucket files are used for hashing and transmission of ledger differences to history archives. If BucketListDB is used, the buckets directory is also used as a primary database backend. If SQL is used, the buckets directory is only used for hashing and history archives, and simply represents a copy of the ledger state stored in SQL.

Buckets should be stored on a fast, local disk with sufficient space to store several times the size of the current ledger. Current ledger size is approximately 10 GB (as of April 2024), so please plan accordingly.