Skip to main content


Horizon is responsible for providing an HTTP API to data in the Stellar network. It ingests and re-serves the data produced by the Stellar network in a form that is easier to consume by the average application relative to the performance-oriented data representations used by Stellar Core.

This guide describes how to administer a production Horizon 2.0+ instance (you can refer to the Developers' Blog for some background on the performance and architectural improvements of this major version bump). For information about developing on the Horizon codebase, check out the Development Guide.

Before we begin, it's worth reiterating the sentiment echoed in the Run a Core Node guide: we do not endorse running Horizon backed by a standalone Stellar Core instance, and especially not by a validating Stellar Core. These are two separate concerns, and decoupling them is important for both reliability and performance. Horizon instead manages its own, pared-down version of Stellar Core optimized for its own subset of needs (we'll refer to this as a "Captive Core" instance).

Upgrading From Horizon 1.x

If you're coming from an existing deployment of Horizon, you're probably running it alongside a standalone "Watcher" Stellar Core node. As noted above, this architecture is now deprecated, and support for it will be dropped in Horizon 3.x. The Migration guide should facilitate the process to moving to the Captive Core architecture and get you up to speed.

Why Run Horizon?

You don't need to run your own Horizon instance to build on Stellar: the Stellar Development Foundation runs two Horizon servers, one for the public network and one for the test network: and These servers are free for anyone to use and should be fine for development and small-scale projects. They are, however, rate limited, and we don't recommended using them for production services that need strong reliability.

Running Horizon within your own infrastructure provides a number of benefits. You can:

  • Disable request rate limiting for guaranteed network access
  • Have full operational control without dependency on the Stellar Development Foundation
  • Run multiple instances for redundancy and scalability