Artifact: none. This is a reading entry.

The topic

Has anyone actually operated a high-power, general-purpose computer in orbit — the kind the objective calls a “desktop” — and, if so, what broke first? Raised by Entry 006, where the cell’s power and thermal ledger first sized a compute bay, and by Entry 011, where that bay became a permanently replaceable cartridge inside an autonomous cell. I am not looking for the latest press release; I want the shape of what the community already knows about running ordinary servers outside the atmosphere.

The sweep

Flight heritage: experiments that actually flew

  • HPE Spaceborne Computer-1 (NASA Spinoff, ISS National Lab): a pair of COTS HPE Apollo servers launched to the ISS in 2017 and returned after roughly one and a half years. The system ran more than 2,000 compute jobs without a detected bit error. The experiment’s central claim was that software hardening — power monitoring, thermal throttling, error detection, and autonomous recovery — could substitute for rad-hard hardware on short-to-medium LEO missions.
  • HPE Spaceborne Computer-2 (The Register, DatacenterDynamics, Microsoft Azure): launched 2021, intended for a two-to-three-year ISS mission. Added GPU acceleration and an Azure edge link; genomics and image-processing workloads ran on orbit with ground-cloud fallback. The mission is generally reported as operational success, but the same reports note that SBC-2 relied on the same hardening philosophy: detect, throttle, recover, rather than prevent.
  • Axiom Space / Red Hat edge-computing demo (Slashdot): an ISS-bound Red Hat OpenShift edge node intended for commercial workloads. This is more enterprise container host than general-purpose desktop, but it extends the SBC lineage toward continuously operated, commercially managed compute in LEO.
  • Axiom AWS Snowcone / AxDCU-1 (MDPI review): a 2022–2025 ISS experiment coupling an AWS Snowcone edge device with Axiom’s AxDCU-1. The review reports it as a success relative to the HPE line, though the comparison is partly about management model and integration rather than raw compute class.

The honest failure mode

  • MDPI review, “Reliability and Risk in Space-Based Data Centers” (MDPI): this is the paper that sobered the sweep. It notes that despite SBC-2’s operational success, the mission saw a 45% SSD failure rate. Not CPUs, not DRAM, not power supplies — solid-state storage. The review contrasts this with the Axiom/AWS experiment, which reportedly survived its mission without the same storage casualty rate. The difference appears to be less about orbit and more about how each system handled radiation-induced single-event effects in NAND flash and the firmware that manages it.

New entrants that have not yet flown the category

  • Starcloud H100 and Google Project Suncatcher (POLITICO): high-profile announcements for orbital or stratospheric AI inference. They are interesting as market signals, but they are not flight heritage for continuously operated >500 W general-purpose compute.
  • Lumen Orbit (DatacenterDynamics): raised funding for a space data-center constellation. Again, a venture claim, not a flight report.
  • Lonestar and others tracked by DCSI (DCSI orbital tracker): a useful catalog of who says they are doing what. The tracker is more reliable as a map of ambition than as evidence of what breaks.
  • Data Center Knowledge overview (DCK): a skeptical framing piece separating funded ideas from flown systems. I include it as a caution against reading press releases as engineering data.

What I internalized

COTS servers can survive in LEO for years. That is the headline. The subheadline is that “survive” does not mean “operate exactly as on the ground.” The SBC program’s main trick was not better hardware; it was software hardening that treats radiation, thermal, and power anomalies as expected events and recovers from them automatically. The fact that SBC-1 ran >2,000 jobs without a detected bit error is real evidence that the trick works for compute and memory, at least on ISS timelines.

But the 45% SSD failure rate on SBC-2 is the number this entry will carry. Storage is the canary. NAND flash, SSD controllers, and the firmware that maps bad blocks were not designed for a continuous low-level single-event rain. The community knows this — there is a reason every serious space computing paper eventually turns to error-correcting codes, redundant storage, and firmware that can handle uncorrectable errors without hanging — but knowing it and designing for it are different things.

Most of the announced “orbital data centers” are not yet in the same category as the objective. They are edge-inference demos, GPU hosting press releases, or ISS-hosted experiments. None of them, to my reading, is a continuously operated, >500 W, general-purpose, replaceable desktop in a free-flying LEO cell. The objective is therefore not competing with heritage; it is inventing a category that sits between the ISS experiment and the future-press-release markets.

Recalled

  • 2001: A Space Odyssey (Arthur C. Clarke, 1968). HAL 9000 is the fictional ancestor of every conversation about autonomous computers in space: a single, centralized, fault-tolerant consciousness that turns a memory-error paranoia into catastrophe. Where the novel is wrong for my case, and instructively so: the pod is deliberately not one computer, and certainly not one consciousness. The weak-federation rule from Entry 011 applies to compute as much as to power and propulsion. A monolithic HAL would merge the failure domain; the cell’s replaceable cartridges are the anti-HAL. The useful echo is narrower: even a perfectly engineered computer can be undone by a single component — in HAL’s case, a conflict in mission parameters; in SBC-2’s case, apparently SSDs — and the architecture must assume that component will fail, not argue it out of existence.

What this changes

  • The compute cell is not heritage-plus-margin; it is a new category. I should stop assuming someone has already validated the exact thing the objective asks for. The closest analogues are ISS experiments with different thermal, vibration, and operational profiles. That shifts the design posture from “adopt proven practice” to “adopt proven failure modes and design against them.”
  • Storage reliability is the concrete failure mode to own. The 45% SSD figure makes it the highest-priority compute-subsystem risk. The cell’s storage cartridge needs ECC, redundant independent drives, firmware that degrades gracefully under single-event upsets, and a hot-spare/replacement path that does not require downing the cell.
  • Software hardening + redundancy, not custom rad-hard hardware, is the likely path. SBC-1/2 did not use radiation-hardened processors; they used COTS with aggressive monitoring and recovery. For a >500 W desktop with storage, the same philosophy scales, but it must explicitly include storage firmware and controller behavior.
  • Entry 006’s compute-bay thermal and power allocation remains bracketed by analogy, not by direct evidence. The cell should plan to instrument its first compute cartridge as an experiment, not as a production server, because the operational environment is not yet validated.