Loading...
Supporting developers, startups, and full-fledged companies building on Stellar and Soroban
© 2025 Stellar Development Foundation
Subscribe to the Newsletter
By Forge
Streamlining Horizon API and Soroban RPC node deployment and management.
Forge is a Horizon-as-a-service and RPC-node-as-a-service platform.
Stellar's native Horizon service is a good service right now, but we envision that with the growth of the ecosystem it might become overcrowded and communities may want to have their own Horizon-as-a-service node. When it comes to RPC nodes, based on our research, the majority of the current RPC providers are bigger companies not necessarily targeting startups/SMBs with their pricing - https://developers.stellar.org/network/soroban-rpc/rpc-providers.
We believe that by building Forge natively for Soroban we will be able to better coordinate and suit our product offerings/price to the growing ecosystem of new startups. When it comes to the challenges of scalability and managing huge data that is being kicked out by the network, we will be using the following approach:
Horizon-as-a-service - We will be using the Enterprise n-Tier approach, where data will be ingested using redundant captive core instances. At the same time we will have several API servers running as those do not require much processing and storage themselves - data is stored in DB cluster - 1 API role instance for each client, also maybe transaction submission role if requested. Our plan is to have 1 database cluster and up to 5 API instances in the beginning. As we will be monitoring the system we may increase the number of API instances based on different metrics. In the future we plan to make a copy of the whole cluster not to have DB as the single point of failure - follow the Redundant Hot Backup schema - https://developers.stellar.org/network/horizon/admin-guide/scaling#redundant-hot-backup. That way we'll make the system more fail-safe and scalable.
Soroban RPC as a service - if a user wants to spin up Soroban RPC we can provide that service as well - we will create the same architecture - single scalable database and several Soroban RPC services to save storage and network resources.
For now the plan is to store 30 day history and then increase the history window gradually as more and more users use the service. We will be using a Load Balancer for serving user requests. We will be running a single (or maybe two, for redundancy measures) node as a public gateway of our infra and propagating data inside the infra for the Ingestion.
Copy-on-write and database sharding are interesting areas for us to explore. While this is not part of the submission, we will explore these technologies to see how difficult/efficient it will be to implement them. When it comes to infrastructure, after receiving a request to create a node for a new customer, our automation and orchestration tool (AOT) will connect to Cloud Provider API and request to create a dedicated virtual machine with predefined configuration (CPU, RAM, Storage). We can configure our AOT to interact and deploy nodes with different Cloud Providers including big ones like AWS/Azure/GoogleCloud and any small ones like Hetzner/Linode/Vultr, also it could interact with on-premise virtualization like VMware/Proxmox/Nutanix. We also can deploy nodes directly on different managed Kubernetes clusters in cloud or on-premise. For now, we choose to use dedicated and individual nodes for customers to have predefined and guaranteed performance, for start we think to provide nodes with 4 CPU / 8GB RAM.
We are also exploring an option to deploy our own bare metal infra in North America and Georgia (Eastern Europe) to optimize our cost base and offer a lower price to our clients.
Our target audience are startups. We believe that all the activation and community awards grantees are a perfect audience for us to outreach. Since the ecosystem is so early, it's so much easier to develop strong partnership bonds.
$39.6K
Giorgi Tepnadze
No other submissions.