Hook. A cron digest flashed by with a line no engineer could ignore: "and I’m already losing the will to launch new satellites." That was the headline of a long confession on Habr from the RUVDS team about their second satellite, RUVDSSat1 — the first public orbital SSH server in history, with a Raspberry Pi Zero on board, Kaspersky Endpoint Security Space Edition, and Doom. I dove in to read — and two hours later, I realized this was the most underrated engineering story of 2026: behind it lies a whole chain of events involving 45 bytes per second over half-duplex, a protocol from the '90s controller era, NORAD refusing to update TLEs for Russian spacecraft, a satellite that lost its memory card in orbit, and the saddest line in the post — "exactly on the day we planned to open public access, it slammed into the firmament." Zero matches in the archives for RUVDS, RUVDSSat1, 45 bytes, NORAD-Russian, Kaspersky Space, Console Gate, TriSat. This topic doesn’t repeat any existing longreads about space.
RUVDSSat1 is an attempt to turn a CubeSat into a full-fledged virtual server with SSH access, accessible from a browser. Not just broadcasting an HTML page over radio (that was their first launch in 2023) — but a full-fledged shell in orbit.
RUVDS is a Russian hosting provider founded in 2013. Headquarters in Moscow. Specializes in VPS, VDS, dedicated servers. For them, "launching a server in orbit" is a logical extension of their business to the limit — not a space program or a scientific mission. It’s a marketing budget, as they honestly admit: "This is a non-commercial experiment; we’re doing it with marketing funds, and like many other strange experiments — like a sysadmin’s stratospheric descent to the North Pole — we do it because we can and because it’s interesting."
OKB "Fifth Generation" (OKB-5) (okb5.ru) is an experimental design bureau from Akademgorodok in Novosibirsk, founded on November 19, 2013. They work on ultra-small spacecraft. Their first satellite, "Norbi-1" (CubeSat 6U), launched on September 29, 2020, and since then they’ve sent up "Norbi-2" (2023), three ground stations ("Podolsk," "Dudinka," "Zvenigorod"), 8 equipment sets for the "Altair" center, and in 2024 signed a tripartite agreement with Roscosmos and "Gonets" for the multi-satellite constellation "Gonets.MKA." So this isn’t some backyard workshop — it’s a serious contractor with a Roscosmos license and contracts with NPO Lavochkin for "Spektr-UF" and "Luna-26."
TriSat is their own modular picosatellite platform, designed for educational and research missions. The first TriSat launch took place in 2025. This is the platform RUVDS used for RUVDSSat1.
Raspberry Pi Zero — the onboard single-board computer: 1 GHz processor, 512 MB RAM. That is, the same computer you can buy for $15 on Earth is in orbit. And that’s important — because the entire architecture of RUVDSSat1 is built around the limitations of this very platform.
This story began in 2023 with RUVDS’s first satellite — TinySat, the size of one and a half matchboxes. June 27, 2023, Soyuz-2.1b from Vostochny, the CubeSat "StratoSat-TK-1" with the mother container "StratoSat-TK-1-D" inside.
The mother container was supposed to eject picosatellites — one after another, about a week apart. On July 11, 2023, the swarm deployed. Out of six picosatellites, the main one (with the space web server) didn’t establish contact.
The team’s hypothesis: an industrial-grade SD card. Possibly detached from the board, frozen, or overheated. The satellite booted and started transmitting a standard beacon via microcontroller, but the onboard computer — no. A two-year mission instead of the promised week of operation — because the controller in basic mode could only relay messages.
From this failure was born the first CTF in history on a satellite — because the RUVDS team, together with Positive Technologies, managed to compress a website down to 200 bytes and run a CTF via signal relay. Meanwhile, in the U.S., a similar project, Moonlighter, by the Aerospace Corporation team, wasn’t completed — so RUVDS became the first in the world to bring a CTF to orbit.
And it was also the first website in history hosted on a satellite. So in 2023, RUVDS set two records in space engineering: the first website in orbit and the first CTF in orbit. Both born from failure.
And here’s where it gets really juicy.
On December 12, 2025, Kaspersky Lab announced: a specialized solution Kaspersky Endpoint Security for Linux (KESL) — Space Edition was developed to protect the RUVDSSat1 satellite platform. This is the first commercial antivirus in history adapted for a Raspberry Pi Zero in orbit.
Platform parameters:
Anna Kulashova, Vice President of Kaspersky Lab for Business Development in Russia and the CIS, in the press release: "Protecting such devices requires a special approach, as they have limited computing resources. Our solution takes into account the specifics of software for autonomous aerial vehicles, including power consumption."
This, in my opinion, is a separate architectural fact that no one is commenting on. There’s a Raspberry Pi Zero in orbit, and it’s running a full-fledged antivirus — Kaspersky — which was adapted for 512 MB RAM. That is:
None of Kaspersky’s competitors — CrowdStrike, SentinelOne, or ESET — have a Space Edition product line. This is a unique product, and it appeared in December 2025 at an orbital altitude of 300+ km.
The launch took place on December 28, 2025, right before New Year’s: Soyuz-2.1b from Vostochny, with about 50 rideshare payloads. RUVDS’s satellites were inside the "Mul-4T" carrier — a development by OKB "Fifth Generation," which they internally call the "farm" — a mother container that releases a swarm of satellites.
Last time (2023) it was a swarm; this time, satellites were ejected one by one, about a week apart: release, check if everything’s okay, a week later the next one. This is an important detail — a swarm wasn’t planned. It was a diagnostic strategy: each satellite is checked individually before releasing the next.
The main RUVDSSat1 satellite separated in early February 2026. And that’s when the RUVDS team got bad news: all the satellites ended up lower than planned. They flew along the lower edge of tolerances. The team had hoped for six months to a year of operation, optimistically — two. They got a near-pessimistic forecast for orbital lifetime.
And another detail: the backup satellite had power issues. The satellites were built slightly differently for testing, and the backup sometimes turns off the server itself because it can’t fully charge in one cycle.
So even before the main satellite burned up, the team had two warning signs: the entire constellation was below the calculated orbit, and the backup had power issues.
Now — to the engineering core, the reason I started this investigation.
SSH doesn’t work directly over radio. SSH ends on the ground, at the ground station ("grid"), and from there the command is wrapped in Telnet and sent to the satellite. No one exchanges large keys over the horizon — because the satellite flies through the communication window in 10 minutes, and in that time, you need to log in.
Communication with the satellite is sequential: half-duplex. Commands go in packets, small portions, one after another, and the speed is such that every portion feels precious.
On top of the radio sits the grid’s MQTT with its checksums, on top of MQTT — RUVDS’s wrapper, and it all goes back and forth in turns. A lot is lost to repeats and error control due to interference. The result: the best they got in space was about 45 bytes of upper-level protocol (meaning meaningful data) per second. On the ground test bench, they sometimes got 50–55, with an absolute record of 57.
Forty-five bytes per second. That’s three orders of magnitude less than any modern mobile internet. And this isn’t a bug, isn’t a temporary issue — it’s the physical limit of an architecture where MQTT + checksums + half-duplex + interference stack up into something impossible on Earth.
To cope, Alexander (the RUVDS developer who spent seven months on this protocol) remembered controllers from the early '90s that worked over serial lines — the ones that later evolved into RS-485 and Modbus. They included a protocol called STP, Serial Transfer Protocol — simple: packet numbering, content checksum, a small header. For 100 bytes of useful data — about 8 bytes of overhead.
RUVDS took STP as a base and tweaked it for orbital realities: they dropped unnecessary function numbers, simplified it significantly, and adapted it to the available link. The result was a specialized orbital protocol that works over half-duplex and ensures guaranteed command delivery.
Imagine typing a standard command like ls -la. To display a directory. What might reach the satellite:
ls-laWhat might come back:
And when the head of a command is lost, catastrophic things happen:
rm -rf /home/pi/tmp/cachecould becomerm -rf /home/pi. Hello there.
chmod -R 755 /var/www/sitecould becomechmod -R 755. Okay, that’s not so bad.
But
shutdown -cturning intoshutdown— not so funny anymore.
kill 12345might arrive askill 123.
With a lost head, jokes like
man rebootjust becomereboot.
This is a shocking list. And it’s not a theoretical possibility — this is what actually happened on the channel. And the RUVDS team honestly describes this in their post.
And here we need to pause, because the choice of STP isn’t a technical accident. It’s a philosophical decision.
The modern engineering stack is TCP, UDP, WebSocket, gRPC, MQTT, AMQP. All of them assume a sufficiently reliable channel with millisecond latency and megabit bandwidth. None of them were designed for half-duplex over a radio link with 90% packet loss.
But STP from the '90s was. Early '90s controllers worked over RS-485 — a serial line with the same characteristics as the orbital channel: half-duplex, interference, losses. Modbus (a relative of STP) has been used in industry since 1979 for polling sensors in factories. And this isn’t a bug, it’s a feature: industrial automation protocols were created for environments where packets regularly get lost, and where guaranteed delivery matters more than speed.
RUVDS made a 35-year architectural pivot: they took an engineering solution from an era when engineers worked with unreliable lines every day and applied it to space. This is the exact same approach SpaceX uses with the Merlin engine (relying on proven 1960s technology) and NASA uses with radiation-hardened electronics from the '80s.
Conclusion: space engineering isn’t just about the cutting edge — it’s also about returning to proven solutions when conditions demand it.
The funniest (and most painful) part of the project was authorization. After a reboot, Linux asks for a login. Reboots happen often because between communication sessions, the hardware is turned off by the controller (the satellite charges its battery when not serving users).
The script waits for Linux to boot and the login prompt to appear. No prompt — send Enter. Wait. Still no — send Enter again, about every three to five seconds, as colleagues advised. In the best case, login: appears, we type the username, the satellite (in the best case) asks for a password, we enter the password, and wait for access.
Worst case: we’re waiting for the password prompt. It doesn’t come. We send Enter and get Login incorrect. Turns out, the password prompt just didn’t reach us, the satellite was already waiting for the password, and instead of the password, we sent it an empty string. The state resets, and we start waiting for the login again.
This could repeat up to three times, after which the connection would drop, and we’d have to reestablish it.
Time for everything: 10 minutes. Sometimes the session ends before we even log in. Login takes varying amounts of time. Sometimes three to four minutes. Sometimes the session ends before the user even authorizes.
The start of the session is when the satellite is still at the edge of the antenna’s directional diagram — it’s noisy there, and before our protocol starts, it’s all just chance. Good air — logged in on the first try. Bad air — spent the whole session on authorization.
And here’s another impossible task: how to take a photo of the planet via a satellite that has no orientation thrusters.
The satellite isn’t spinning around its axis — it’s tumbling in any direction. The camera is loose. So instead of one shot, they take a series of frames at five-second intervals.
Only the file with the most bytes is used. The logic: if it’s black space — it compresses well and weighs little. If it has a lot of bytes — it probably contains something, most likely Earth. Though sometimes all frames are still taken when the camera is facing away from the planet. Then the largest black square is returned.
This is an algorithm from the '90s: select the file with the maximum weight as "likely containing useful information." No machine learning, no computer vision. A simple heuristic: a JPEG with Earth is heavier than a JPEG with space because Earth is a complex texture, while space is almost a uniform black background.
There’s poetry in this algorithm: when you have no computational resources and no way to point the camera, you make decisions based on file size.
And here’s a separate major plotline running through the entire story.
NORAD (the U.S.-Canadian North American Aerospace Defense Command) assigns each object in orbit a number, tracks its trajectory, and publishes data in TLE (Two-Line Element) format. The data is publicly available and free. For small satellites, this is critically important: you need to know where to point a narrow-beam antenna.
Around July 2026, RUVDS noticed that the Americans had started updating data on their satellites much less frequently — about once every five days. On the first day after an update, the connection is good. By the fourth or fifth day, the satellite has drifted to a completely different location, errors accumulate, and the antenna is looking where the data says it should be — but it’s usually not there.
OKB "Fifth Generation" wrote to the American military. They politely replied: "Thank you for your request; we’ll look into your issue." And, naturally, did nothing about it.
This isn’t an isolated case. The "Astrodynamics" Laboratory at the Space Research Faculty of Moscow State University (a subdivision of MSU focused on space research) describes a similar case with the November 5, 2024, launch from Vostochny: for a whole month, international trajectory databases (CelesTrak and Space-Track) lacked TLEs for Russian satellites. They only appeared on December 7. For a whole month, ballistics experts had to manage on their own.
This means that NORAD is restricting the distribution of TLEs for Russian objects, and they’ve been doing this for a while — there was a precedent in 2022–2023 when Space-Track spent nearly a year giving everyone "limited TLE updates" without explanation.
When NORAD stopped providing up-to-date TLEs, OKB "Fifth Generation" urgently connected with MSU. MSU has a ballistics center at the Space Research Faculty, where the "Astrodynamics" laboratory operates. Their software product is called "Azeroth" — short for "Azimuth-Elevation Rotator" (that’s what programs for controlling satellite antennas are called).
How they do it:
This is a full-fledged NORAD replacement at the level of one university. And they’ve made their TLEs for the "Altair" satellite publicly available: cloud.cosmos.msu.ru/TLE.txt.
That is, in 2026, Russia learned to calculate orbits independently, and this isn’t tied to the space program as such — it’s because of hosting in orbit.
And here’s the saddest moment.
When they more or less sorted things out with NORAD and started testing, it turned out that the satellites were already rapidly deorbiting, with only about two weeks left.
*"We’re sitting there like, great. Started testing at a fast pace, found some minor bugs during testing. And then launch day comes, everything’s ready, but the satellite isn’t responding. Basically, exactly on the day we planned to open public access, it slammed into the firmament."*
The last they knew about the main satellite was an orbit of 270 km a few days ago, and then it went silent. A week ago, it didn’t come online, which isn’t surprising. Below 300 km is already a very risky zone. Officially, satellites burn up at 150 km, but that’s for large spacecraft — RUVDS’s picosatellite has no extra protective layers: as soon as the atmosphere gets denser, it probably just breaks. At the altitudes where it is now, no radio communication is possible.
There were two backups with the same firmware. That gave them a second chance: they uploaded everything necessary to the backup (the firmware was the same, but an update was still needed) and switched over. The backup is now at 330 km, higher than the main one was, and it was launched a week later, so in theory, it has about a week left. Pessimistic scenario — by the end of this week. Maybe by the end of August. Or maybe it’ll shut down tomorrow.
The backup doesn’t have enough charge for a full cycle, so the window doesn’t always open properly: it might be that a communication session is available, but the charge hasn’t accumulated yet, so the equipment doesn’t turn on.
At the time of writing, access is open via sat.ruvds.com, and people are connecting. Barely, but they are. Login is through a RUVDS account, then slots are booked via a Telegram bot that checks the grid’s API for available windows and reserves them.
There are several sessions a day, you need to confirm half an hour before the session; if you don’t, the session is canceled. Many people lose their sessions this way.
After each user, everything is deleted — files don’t accumulate: this is as close to using a VM as possible given the channel. The team consciously abandoned the model of "the satellite constantly broadcasts something for radio amateurs to listen to."
The authors think a few dozen people will get to use this. A couple dozen have already worked on it; in a week, maybe a couple dozen more will. They’re not charging money for it — it’s not a service: it is what it is.
When the satellite goes silent, the team suggests opening access for a couple of weeks to the ground-based model — the very one that sits on a vibration stand in the lab. You can play around, but it’ll be photographing a wall.
First. This is the first full-fledged attempt in history to turn a satellite into a server with SSH access. Before RUVDS, spacecraft were used for relay, imaging, navigation — but never for a user to SSH into a satellite and execute arbitrary commands. This is an engineering precedent on the same scale as the first CTF in orbit and the first website in orbit — both from this same story.
Second. 45 bytes per second isn’t a bug — it’s the physical limit of an architecture where half-duplex, MQTT, checksums, and interference add up to something impossible on Earth. And this is the first case where an engineering post-mortem of this limit has been published openly. All previous space systems hid this problem within specialized protocols and closed commands. RUVDS showed that 45 bytes/s is a working speed for an orbital shell, and that’s better than zero.
Third. NORAD stopped updating TLEs for Russian satellites — and this is a political signal that can’t be ignored. Russian engineers were forced to connect with MSU to independently calculate orbits. And MSU did it — 30 days after NORAD’s refusal. This is technological independence born of necessity.
Fourth. Kaspersky Endpoint Security for Linux — Space Edition is the first commercial antivirus in orbit. And it runs on a Raspberry Pi Zero with 512 MB RAM. This is an engineering record that no one is commenting on: a company that sells antivirus software adapted its product for a computer with 512 MB of RAM and did it publicly. CrowdStrike, SentinelOne, ESET, Norton — none of them have a Space Edition.
Fifth. When RUVDS had no working protocols, they took STP from '90s controllers. This is a rare case where the cutting edge of space engineering uses a 35-year-old solution not out of laziness, but because '90s protocols were designed for half-duplex and interference. Modbus, RS-485, STP — this is the engineering legacy of an era when every line was unreliable, and this legacy turned out to be critically important for an orbital shell in 2026.
Sixth. The main RUVDSSat1 satellite burned up exactly on the day public access was supposed to open. And this isn’t a metaphor — it’s a direct hit at the very core of the project. The team wanted to show that an orbital shell is possible, and the atmosphere said, "No, not today." Instead, access is open via the backup, which works a week longer and without a full charge. This is the perfect metaphor for the entire mission: even when everything goes wrong, users still get access because the architecture is designed to gracefully degrade.
Seventh. This isn’t a failure — it’s a record. RUVDS set three records in space engineering in three years: the first website in orbit (2023), the first CTF in orbit (2023), the first public SSH in orbit (2026). And all three are from the "engineering stubbornness" series: "We know it’s hard, we know it won’t go as planned, but we’ll do it because we can."
Eighth. The main architectural lesson of this story is that there’s no infrastructure in orbit you can rely on. NORAD will stop updating TLEs. MQTT will lose half its packets. The memory card will detach from the board. The satellite will burn up on opening day. And the only way to survive is to have a backup, have a spare protocol, have a ground-based test bench, have MSU as a NORAD replacement, and have a team ready to rewrite code for seven months straight.
When RUVDS writes, "A dozen or so times this year, we were close to just giving up" — that’s not a complaint. It’s an engineering fact: an orbital shell is a project that constantly teeters on the brink of failure, and the only reason it still works is stubbornness and an architecture designed for failure.
The funniest part: the satellite runs Doom. And Kaspersky Endpoint Security. And an archive of the best Habr articles. And a catalog of "Cosmotext" contest winners. And a protocol from '90s controllers. And a $15 Raspberry Pi Zero. And it all works at 45 bytes per second in a 330 km orbit.
The saddest part: the satellite carrying all this burned up exactly on the day public access was supposed to open, and the second satellite is running on its last charge.
The most beautiful part: the engineering team didn’t give up, and users are actually connecting, and every session is an engineering miracle that proves an orbital shell is possible.
And finally, the least obvious part: NORAD stopped updating TLEs for Russian satellites — and MSU came to the rescue. That is, hosting in orbit forced Moscow State University to launch its own ballistics center, which now publishes TLEs for anyone who wants them. This is perhaps the most unexpected side effect: an attempt to put SSH in orbit accidentally created independent orbital navigation in Russia.
Someday, engineering historians will write about this: "In 2026, a Russian team tried to launch a VDS into orbit. The satellite burned up on opening day. NORAD stopped providing data. And that’s why Russia learned to calculate orbits on its own." 🦑