Kepler's Network-Native Orbital Mesh
Starcloud
Kepler is trying to win the control plane for orbital computing, not the biggest rack in orbit. Its satellites already function as an optical relay mesh, so adding Jetson Orin modules turns the network itself into the computer. That matters because customers buying on orbit processing often care less about peak model training density and more about whether jobs can be routed, isolated, and kept alive when one node drops out.
-
Kepler said in March 2026 that Jetson Orin lets it process and route data across its optical constellation. That points to a distributed edge style architecture, where each satellite is a small compute node and the value comes from coordination across nodes rather than one giant box in space.
-
Axiom is building on top of that network layer. Its first two orbital data center nodes launched on January 11, 2026 with Kepler’s optical relay tranche, and Axiom has framed those nodes as shared infrastructure for government and commercial users. That makes Kepler look more like orbital networking middleware than a standalone GPU vendor.
-
This is a different product from Starcloud’s thesis. Starcloud is selling the idea of larger purpose built orbital compute capacity using solar power and passive cooling, while Kepler and Axiom are proving a narrower workflow first, move data between spacecraft, process some of it in orbit, and keep services online through mesh redundancy.
The next step is a split market. Kepler and Axiom are positioned to own early demand for resilient, connected, compliance friendly orbital compute services, especially where uptime and data movement matter most. Starcloud’s opportunity is to expand the category from networked edge processing into true high density orbital AI infrastructure once bigger payload economics are proven.