Satlyt has raised an $8 million seed round to build software for computers aboard satellites. Its immediate case is narrower—and more measurable—than a giant data center in space: analyze telemetry, logs and images near their source, then send more useful information through scarce downlink capacity.
The larger ambition is to make computing portable across spacecraft from different manufacturers. Satlyt has flight experience and customer experiments, but it has not yet demonstrated a distributed cloud spanning different satellites. Keeping those milestones separate is essential to understanding both the funding and the risk.
A rejected internal pitch becomes a funded software company
Founder Rama Afullo worked in Google's cloud organization before joining SpaceX's Starlink business in 2024. He told TechCrunch that both employers rejected his internal proposals for orbital computing. He subsequently co-founded Satlyt, operating from Sunnyvale, California, and Nairobi, Kenya.
Houston-based Non Sibi Ventures led the seed round. Its partners include former NASA astronaut Bernard Harris. Satlyt says its software has flown on two demonstration missions; its latest reported deployment uses satellite computing hardware from India's TakeMe2Space.
That mission carries three distinct workloads. NASA is paying to test cloud-computing protocols in space. Orbital-surveillance company Stellerian plans image-processing evaluation, while TakeMe2Space wants to demonstrate hosting outside software. These are customer experiments with different purposes, not proof of a mature shared orbital service.
Afullo wants to reach 20% of satellites by the decade's end. Satlyt also says software was prepared for as many as 50 spacecraft deployments in 2026. Neither ambition nor prepared capacity equals active installations, paid renewals or independent market share evidence.
The clearest early result is a smaller diagnostic message
Satlyt has deployed a quantized one-billion-parameter Gemma 3 model on a Momentus-operated satellite using llama.cpp. Quantization lowers numerical precision to reduce memory and compute requirements. The Gemma account describes local analysis of telemetry, application logs and software errors.
In two fault-injection scenarios, diagnostic payloads fell from 1,319 to 469 bytes and from 1,318 to 464 bytes—reductions of 64.4% and 64.8%. The model produced short diagnoses and recommended actions. Reported generation speeds exceeded 22 tokens per second in those scenarios.
Broader company tests examined approximately 11 watts of processor power during inference and a temperature rise of three to five degrees Celsius. These are company-provided measurements under constrained conditions, not an independently established fleet-wide operating profile. Payload reduction also does not establish diagnostic correctness in every fault.
The practical mechanism is straightforward: summarize a fault before a communication window rather than downlink every raw log. Ground teams may receive a smaller, more useful report. Image processing can similarly reject cloud-obscured frames or prioritize possible surveillance targets before transmission.
Those are edge-computing applications, not prerequisites for enormous orbital AI clusters. Financial value depends on the mission's bandwidth contract, staffing and response needs. Useful evidence would connect bytes saved with quicker anomaly resolution, more valuable imagery or less ground work, while also measuring accuracy, energy and memory.
Portability and vertical integration solve different problems
Afullo's analogy casts SpaceX as an orbital iPhone and Satlyt as Android. The distinction is software across varied hardware versus a tightly coordinated stack. It is not a claim that the two companies have comparable scale or that Satlyt's platform is already an open industry standard.
SpaceX controls launch, satellite manufacturing, connectivity and much of the operating environment. Integration can simplify interfaces and coordinate power, links and processors. Customers may accept dependence on one roadmap, launch schedule or pricing structure in exchange for easier deployment and support.
Satlyt does not plan to manufacture satellites. It compares its abstraction layer with VMware and Snowflake: applications should depend less on specific physical machines. More compatible manufacturers could attract developers, and more applications could attract manufacturers. At present, the startup must solve the cold start of both sides needing the other.
Google's Project Suncatcher begins with its own TPU hardware and interconnected, solar-powered satellites. Its prototype, built with Planet, tests launch, radiation and thermal effects. Google said the prototype reached orbit on SpaceX's Transporter-18 on October 1, 2026, established contact and began testing.
Sharing launch access does not make the approaches identical. Google is testing specialized hardware in space; Satlyt is testing whether outside customers can use software across computers it does not own. They are not necessarily direct competitors today and could eventually be complementary.
Spacecraft safety sets the limit on a shared layer
Terrestrial servers benefit from standard interfaces, reliable networks and physical maintenance. Satellites face radiation, thermal cycles, intermittent links, orbital motion and strict power budgets. Processors, operating systems and mission priorities vary; many spacecraft lack links intended for exchanging large workloads.
Google describes prospective laser-link targeting as akin to hitting a coin-sized moving target from miles away. Launch components can experience 50–100 times gravity, radiation can change stored data, and vacuum rules out ordinary airflow cooling. Software can schedule around physical limits only if it receives reliable telemetry and sufficient operational access.
A third-party workload must not consume memory, energy or communications required for navigation or the primary payload. Isolation, signed updates, access controls, audit records and emergency-stop authority become acceptance requirements, not optional platform features. Multi-operator management also creates an attractive cybersecurity target.
AI can misdiagnose a fault or misclassify an image. Recommending an action to ground controllers is therefore different from commanding a spacecraft. Satlyt says operators will retain command authority as it pursues anomaly detection and multi-agent decisions; that boundary needs validation in actual integrations.
Commercial incentives may be as difficult as the technology. Unused processor time does not automatically justify another operator's liability or revenue-sharing terms. Without common interfaces, every integration becomes a bespoke engineering job, weakening the repeatable software economics behind the platform argument.
The next tests must establish more than a launch
Satlyt expects to attempt computing across two different spacecraft next year. A meaningful disclosure would identify the platforms and demonstrate coordinated processing, latency, resource use and recovery—not merely a message exchange. Two identical machines could prove distribution without establishing broad interoperability.
Repeat customers and independent spacecraft builders would strengthen the commercial case. Agreements, launched hardware, active workloads and paid renewals are different evidence levels. The strongest operational data would come from customers or research partners, alongside internal benchmarks, while Google pursues inter-satellite links and SpaceX retains its deployment-scale advantage.
Mission reports, test definitions and contracts can be tracked in a searchable engineering-document knowledge base. Satlyt has moved beyond a proposal, but its defining claim remains ahead: portable, safe and economically repeatable computing across mixed fleets. That—not another Android comparison—is what would turn onboard tools into an orbital platform.