The Problem Appears Early
Once the first version of Pod was implemented, a new requirement emerged almost immediately: the protocol needed to be tested across multiple machines distributed globally. Local execution was no longer sufficient. Evaluating Pod under realistic conditions—latency, geographic variance, and heterogeneous network environments—required running nodes across continents in a repeatable and reliable way.
Why Existing Solutions Fell Short
The most obvious option was Kubernetes. It is widely adopted as the standard platform for deploying software at scale, and it is well understood across the industry. However, Kubernetes is fundamentally designed to address a different class of problems than the one Pod faced.
Kubernetes is built around orchestration: scheduling many workloads onto shared clusters, managing replicas, and coordinating services within a region or data center. Pod’s testing requirements were narrower. The primary need was to provision machines, deploy mostly single-node processes, and monitor their behavior once running.
While Kubernetes can support this workflow, it does so by introducing the full operational surface area of cluster management, networking layers, and multi-region coordination. For the specific goal of deploying one node per machine across the world, this overhead becomes disproportionate to the problem being solved.
Introducing Interstellar
Interstellar is Pod Network’s solution for deploying and managing globally distributed test networks. It was developed to make protocol testing reliable, reproducible, and aligned with real-world deployment conditions. Rather than relying on heavyweight orchestration frameworks, Interstellar focuses on the core workflow Pod requires: provisioning infrastructure across regions, deploying single-node processes, and observing network behavior once live.
From the beginning, Interstellar was designed as a centralized command system that enables engineers to spin up private devnets quickly and consistently. Through a hosted interface and tight integration with existing infrastructure and monitoring stack, Interstellar makes it possible to test new protocol versions globally without turning deployment and operations into a parallel engineering effort.
How Interstellar Works Under the Hood
Interstellar follows a predictable and automated deployment workflow. Continuous integration builds Docker images on every merge by default, and on pull requests when triggered. When an engineer wants to test a specific branch, they configure a devnet by selecting the branch, choosing the number of nodes, and specifying the geographic regions in which those nodes should run.
Once deployment is initiated, Interstellar generates a Terraform configuration from a template describing the required infrastructure. This configuration is committed to the Terraform repository, where terraform apply provisions the machines. As instances come online, Interstellar monitors readiness and waits until they are available for SSH access.
In parallel, Interstellar renders Docker Compose files from templates and commits them to a GitHub repository. That commit triggers CI, which calls back into Interstellar via a webhook. Interstellar then connects to each machine, writes the Compose files to disk, and runs docker compose up. Once containers are built and running, the devnet becomes operational and ready for testing.
From the moment the network comes online, Interstellar collects operating system metrics, network-specific metrics, logs, and traces. These signals are surfaced through the integrated observability stack, allowing engineers to inspect network behavior directly without additional tooling or manual setup.
An Easy-to-Use Hosted Service, Global by Default
Interstellar is implemented as a hosted, UI-based web application that integrates with GitHub, major cloud providers, and a modern observability stack for metrics, logs, and tracing. Engineers authenticate using their GitHub accounts and are presented with a simple interface for launching private devnets with only a few configuration steps.
Centralizing Interstellar as a hosted service solves several operational challenges. If each engineer ran the system locally, authentication and credential management would need to be repeated across integrations, and updates would require constant manual maintenance. With a hosted system, engineers can log in and immediately access the latest functionality without additional setup.
Because Interstellar is designed to work directly with cloud infrastructure, it also supports deployment across the regions offered by major providers, including Google Cloud and AWS. This enables geographically distributed devnets to be launched across dozens of locations worldwide, while preserving flexibility as additional providers are added over time.
What Comes Next
The next major step for Interstellar is the introduction of a dedicated YAML specification. This configuration will describe an entire devnet in a single, standardized format, including topology, regions, protocol versions, Docker or non-Docker setups, and debug or release builds. The goal is to make devnet definitions explicit, reproducible, and easy to share across teams.
Interstellar began as an internal necessity. It has since become a core component of how Pod Network tests and evolves a globally distributed protocol. Interstellar will be made public soon—follow Pod Network to be among the first to hear about the release.
