DEV Community: Suman Sarkar

The cloud is moving to orbit. Here is what is real so far.

Suman Sarkar — Tue, 27 Oct 2026 21:54:25 +0000

On 1 October, Google put four of its AI chips into orbit on a satellite about the size of a refrigerator. Two weeks later, Nvidia's CEO said his engineers are designing a new kind of server with SpaceX, meant to run in space. For software developers, the cloud they deploy to may one day include machines that are not on the ground at all. This post looks at what is real today, who gains from it, and what the next step looks like.

What is real comes first. In November 2025, a startup called Starcloud launched Starcloud-1, a satellite of about 60 kilograms carrying one Nvidia H100 GPU. It was the first data center class GPU to run in orbit, and the team used it to train a small language model in space [1][2]. On 1 October 2026, Google's Project Suncatcher prototype followed with four TPUs. Because of heat limits, those chips run Google's open Gemma model for 15 minutes at a time, and the mission is planned to operate for a year [3].

That is two satellites and five data center chips.

Then there is what has been proposed. In February, the FCC accepted SpaceX's application for up to one million orbital data center satellites [4]. Starcloud filed for up to 88,000 on 3 February [2], and a young startup called Orbital filed for up to 100,000, with 10 gigawatts of computing power [5]. Together, those three filings ask for about 1.19 million satellites, by my own count.

Between the two sit the designs. In June, SpaceX showed AI1, its first data center satellite design, at about 150 kW peak and 120 kW sustained, with a 70 metre wingspan [5]. A Google research paper published in October says each data center satellite may need 50 to 100 kW, roughly what one rack draws on Earth [6]. On 15 October, Jensen Huang said Nvidia and SpaceX engineers are designing a new server together, one that could run in space and on Earth [7].

So the honest picture is this. A few chips are flying, the designs are serious, and the filings are requests for permission, not proof that anything works at scale. The companies say so themselves. SpaceX's IPO prospectus calls orbital AI compute a very hard technical problem [8], and the lead of Project Suncatcher does not expect space compute to beat ground data centers on cost within five years [9].

Every new place to run software creates new work. The people closest to the hardest constraint usually gain first, and in orbit that constraint is power.

Developers who write lean software come first. In orbit, every watt has to be collected by a solar panel and every bit of waste heat has to leave through a radiator. Code that does the same work with less compute is worth more there than anywhere else. The model running on Google's prototype is Gemma, a small open model [3]. Engineers who know how to make models smaller and faster gain a place where that skill is the whole job.

Electronics, thermal and power engineers gain too. Orbital is hiring engineers for thermal, power, mechanical and electrical work [10]. Starcloud's next satellite is planned to carry the largest commercial deployable radiator flown so far [11]. Hardware that survives radiation and sheds heat without air is becoming its own product category.

For infrastructure and reliability engineers, the job changes shape. A technician cannot walk up to a server in orbit and replace a part [3]. Systems that report clearly, recover on their own and move work away from a failing node become the core of the job. Teams that already run large fleets through automation start with an advantage.

In large scale engineering, the cost of every compute cycle is visible. In my own work on systems at that scale, I saw decisions that were perfectly acceptable on a small system become a clear no once scale came in. Precomputing a new data point for every customer, back through all their history, is fine when the data is a few gigabytes. When the data runs to exabytes, the better move is to first ask which customers actually need it.

Teams whose data is born in space gain in a very direct way. Earth observation satellites can produce hundreds of terabytes of raw data a day, more than the links to the ground can easily carry [12]. Processing that data in orbit means sending down answers instead of raw images. Starcloud planned to use its first satellite to analyse radar data from Capella Space for exactly this reason [13]. Farmers, shipping companies and city planners who rely on satellite data stand to get their answers sooner.

Satellite operators gain as well. Starlink satellites perform a collision avoidance maneuver about every two minutes on average, and most of the processing behind them still happens on the ground [12]. More compute on board lets those decisions happen where the satellite is.

Founders and small teams have room here too. Starcloud designed, built and launched its first satellite in 21 months on 3 million dollars of pre-seed money, and in August it raised again at a 2.3 billion dollar valuation [14]. Big companies will build the satellites. Small teams can build the layer around them: scheduling, monitoring and testing for compute that nobody can touch.

If I had to name who gains most, it is two groups: people whose data already lives in orbit, and developers who treat compute as something scarce.

In 2018, Microsoft sealed 864 servers inside a steel tube and lowered it to the seafloor off the Orkney Islands. When the tube came back up in July 2020, those servers had failed at one eighth the rate of a matching group on land [15]. Microsoft did not go on to build undersea data centers, but it kept the lessons for its research on reliability [16].

I am not trying to predict what orbital data centers will become. What I take from Project Natick is simpler. Putting compute somewhere new teaches engineers things they could not learn at home, even when the place itself does not become the new normal.

The next step is not a million satellites. It is small and specific. Google plans to launch two satellites in 2027 to test whether they can share work over laser links between them [17]. Starcloud plans a second satellite with its large radiator and paying customers on board [11]. These are plans, not achievements, and plans in space often move.

There are real hurdles. Heat has to leave through radiators, launch still costs a great deal, and nobody can drive over to fix a broken server. People have cleared hurdles like these before, one experiment at a time. That is the question this series keeps asking: what changes for engineers when orbit becomes an ordinary place to run software? The answer starts with satellites like the one Google launched four weeks ago.

For now, running compute in orbit costs far more than running it on the ground. One analyst's rough model puts the cost of launching and running a GPU in space for a year at ten times or more the cost on Earth [12]. The clearest early customers are the jobs that need compute next to the sensor: processing Earth observation data in orbit and helping satellites avoid each other. For a small team, the opening is the software that makes remote, power-limited compute easy to use.

Companies are looking at orbit because compute on Earth is scarce and power hungry. The same scarcity shows up on every developer's bill as tokens and GPU hours. An AI coding tool that reads the whole repository for every question, or retries a failing call without limits, spends compute nobody planned for. The tools that last will treat every call as having a cost and will show that cost before they spend it.

The picture changes again once humans live and work beyond Earth. Communication between planets already depends on relays. On Mars, the rovers send most of their science data up to orbiters, which pass it on to Earth, because each rover loses its line of sight to Earth for about 12 hours a day. A one-way signal between the two planets takes between 3 and about 22 minutes [18]. In September, NASA chose Blue Origin, under a contract worth up to 700 million dollars, to build a dedicated Mars telecommunications orbiter, due for delivery by the end of 2028 and planned to operate at Mars by 2030 [19]. Around the Moon, ESA's Moonlight programme plans five satellites for communication and navigation, with first services in late 2028 [20].

A relay that can also compute is a natural next step from there. With minutes of delay on every message, a question asked on Mars cannot wait for an answer from Earth. A data center sitting in orbit next to the relay could process data where it arrives, answer local questions on the spot, and send only the results across the long link home. Seen that way, the cost question also looks different. On Earth, an orbital data center competes with a cheaper building on the ground. For a crew on Mars or a base on the Moon, the comparison is with having no nearby compute and no fast link at all. When communication becomes something a community depends on, the price of building that infrastructure is weighed against the value of staying connected.

Sources

The 1.19 million total and the five chip count are my own sums of the figures below.

What happened when AI found a decade-old hole under 70% of the web?

Suman Sarkar — Sat, 24 Oct 2026 21:19:18 +0000

Wednesday, 21 October 2026. For most people it was an ordinary working day. Then, one after another, government websites in France, Denmark, Finland and the Netherlands went dark. Even the site of the Dutch cyber security agency disappeared behind a maintenance page. Across the Atlantic, Canadian federal sites followed. Nobody had broken in. Their own operators had switched them off, racing to patch two critical flaws in PHP, the language that runs about 70% of the web. The flaws had been hiding for more than a decade, until frontier AI models helped researchers find them. If you write software for a living, this is a week worth slowing down for.

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and security firms call them PHP2Shell. Both are rated 9.2 on the CVSS v4.0 scale, which counts as critical (Quartz). They are memory safety bugs in how PHP cleans up after a fatal error, especially an out of memory error. A crashed request can leave stale internal state behind, and a later request can reuse it (Wiz Research).

What makes them unusual is where they live. The bugs sit in PHP itself, below the application. Wiz showed unauthenticated remote code execution on the latest WordPress, Drupal and Joomla container images, and showed that attackers could read passwords, tokens and API keys from server memory without taking over the server at all. Every PHP release of the last decade is affected by at least one of the bugs, going back to version 5.4 (Wiz Research).

The timeline, as the researchers and responders have published it:

timeline
    title PHP2Shell, from discovery to patch (2026)
    19 Aug : Wiz finds the first flaw with AI assistance
    20-21 Aug : Remote code execution confirmed on Drupal, then WordPress
    24 Aug : Flaws reported to the PHP security team
    21 Sep : PHP acknowledges and starts a coordinated fix
    20 Oct : PHP announces a critical release for the next day
    21 Oct : Patches ship at 14:00 UTC, NSA issues guidance, sites go offline

Wiz used its own Wiz Atlas tool together with Gemini 4 Argon and GPT-5.6 Sol. Its researchers wrote that a single person with frontier models finished in a week what would once have taken a world class team months (Wiz Research). Separately, Ryan Austin of the security firm Calif found the same class of bug while auditing PHP under OpenAI's "Patch the Planet" initiative (Forkast).

The disclosure did not stay quiet. Technical details leaked before the planned release (Recorded Future). PHP announced on 20 October that fixes would ship the next day at 14:00 UTC, and that it might release earlier if details went public (PHP Foundation). The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (Quartz). The same day, the NSA told organisations that could not update right away to take the affected system offline until it was mitigated (SecureWorld).

Many did exactly that. Government sites in France, Denmark, Finland and the Netherlands went dark for a while, including the website of the Dutch cyber security agency itself, and the Irish news site The Journal went offline to strengthen its defences (ABC7). Canada's AI minister said some federal sites were taken down as a precaution (CBC).

None of this is entirely new, and the researchers who found PHP2Shell say so themselves. Wiz compares it to two earlier turning points: Heartbleed in 2014, which showed how fragile the shared code securing the internet was, and Log4Shell in 2021, which showed how deeply one dependency can hide inside everything (Wiz Research).

The closest echo is Log4Shell. It was disclosed on 9 December 2021 with the maximum severity score of 10 (ITPro). Within days, Quebec shut down nearly 4,000 of its government sites as a precaution (Security Affairs). Five years later, governments made the same choice for the same reason.

AI finding real bugs is not new either. In 2024, Google's Big Sleep agent found an exploitable memory safety bug in SQLite. The developers fixed it the same day, before it reached an official release, so no user was ever exposed (Google Project Zero). The difference this time is age and reach. Big Sleep caught a fresh bug in code that had not shipped. PHP2Shell was a decade old, already running on most of the web, and its exploit leaked before every server could be patched.

Everyone running PHP had to act, even those whose own code was clean. For website owners and small businesses on WordPress, Drupal or Joomla, that meant patching the same day. Malwarebytes notes that PHP 8.1 and older no longer get routine security updates, which leaves abandoned sites and forgotten admin panels as the long tail (Malwarebytes). Governments chose a few hours of downtime over the risk of a breach. In the Netherlands even DigiD, the national login service, went offline (Isatis).

Most everyday users never saw an attack. They saw a maintenance page. Their real exposure is quieter, because the memory disclosure bug could leak passwords and session tokens without leaving much trace (Wiz Research).

Behind those maintenance pages, a lot of people worked late. On release day the PHP Foundation warned that a volunteer run package repository might not update in time, then reported that its maintainer, Remi, signed and shipped the packages anyway (PHP Foundation on X). Before disclosure, Wiz had worked with Google Cloud, Cloudflare, AWS, Microsoft, Fastly, Akamai, Vercel and others to prepare protections for customers who could not patch at once (Wiz Research).

For AI labs and the people building AI tools for developers, this week was a public demonstration of both sides of the same capability. The models that helped find and exploit the flaws also helped detect attacks and verify the fix.

I do not want to predict what this means or where it takes us, so I will stay with what we already know. PHP started in the 1990s as a small tool for personal web pages and grew into the foundation of most of the web. Nobody planned that. It grew fast because it was easy to use, and every year of growth added code that would be hard to change later. Wiz traces PHP2Shell back to architecture decisions made more than a decade ago (Wiz Research).

That is the trade every new technology makes. You move fast because the thing you are building did not exist before, and nobody knows yet which corners matter. Some of those corners turn into incidents years later. The same is true of AI right now. It is new, it is moving fast, and it just showed it can both expose an old risk and help close it.

Working at a cybersecurity company made me conservative about the technology I choose, and secure by design has always been my first choice. That work also taught me that security is never finished. A system that is safe today, with exactly the same configuration, can be vulnerable tomorrow because something changed somewhere else. PHP2Shell is one example: the old code stayed the same, but AI made its flaws practical to exploit. Encryption is another. Most of what protects us online rests on math problems that today's computers cannot solve in any useful time, yet a capable enough quantum computer could solve them quickly. That is why NIST published its first three post-quantum encryption standards in August 2024, so organisations can start switching before such a machine is built (NIST).

History is full of people who used a bad moment to make things stronger.

After Heartbleed (2014). OpenSSL, which secured a large share of internet servers, had very little funding. Within weeks, the Linux Foundation launched the Core Infrastructure Initiative, backed by Amazon, Google, Microsoft, Intel and others. Its first act was paying two full time OpenSSL developers (Linux Foundation).
After Log4Shell (2021). The White House brought software companies and open source foundations together in January 2022. By May they had a 10 point plan, an estimated $150 million over two years, and about $30 million already pledged (MeriTalk).

This week already has its own small version of that pattern. The PHP team announced the release a day ahead so people could prepare. Cloud providers shipped protections before the details were public. A volunteer signed packages through the night. People showed up.

This special edition steps outside the usual schedule, but it asks the same question as the rest of Space Native Engineering: what happens to engineering when space becomes an ordinary place to run software? On a satellite or a lunar base, you cannot always switch a system off and patch it over lunch.

There will be more weeks like this one. Old code will meet new tools, and something will break that nobody expected. That is not a reason to slow down. It is a reason to build with the lessons we keep paying for: fund the shared foundations, find the bugs before attackers do, and design for the day something fails. That is how we will reach space too: one hard lesson at a time, each one leaving the foundations stronger.

This is only the start for me, and I plan to keep writing here for the long haul. I am also close to sharing something I am excited about, so check back in a few days.