host opinions · june 2026
StarRupture Shipped a Dedicated Server, Then Made You Fight It
A couple of weeks ago we praised a small Roman survival game for shipping a clean dedicated server on day one. StarRupture is the other half of that lesson. It also shipped a server most of the genre refuses to ship. It just shipped it rough enough that the real question is not whether the server exists, but whether the studio keeps fixing it.
The half of the lesson we skipped
When we wrote up Romestead, the point was simple and a little smug. A small Swedish studio shipped a first-party dedicated server on launch day, while bigger co-op games shipped peer-to-peer and parked servers on a someday roadmap. Shipped beats announced. End of story.
StarRupture complicates that neat little filter, and it should. Because Creepy Jar, the Polish studio behind Green Hell, did ship a dedicated server for its new sci-fi base builder. It is right there, a first-party tool, the thing Subnautica 2 and Solarpunk would not give you. By the Romestead logic, that is a pass.
Except the server launched janky. Not "indie rough around the edges" janky, but "the client connects over a different protocol than the server is listening on" janky, with a startup flow so unintuitive that a wave of players assumed the feature was broken when it was technically working. So the honest version of our own filter needs a second clause. Shipping a dedicated server is necessary. It is not sufficient. The server also has to be usable, and if it is not usable on day one, the only thing that turns it from a checkbox into a real tool is the studio actually maintaining it.
That is what makes StarRupture worth a host opinion. It is the test case for the part of the story Romestead let us skip.
What StarRupture actually is
StarRupture is a first-person open-world base builder with factory automation, survival pressure, and combat, set on the alien planet Arcadia-7. You extract resources, wire up sprawling industrial chains, and fend off waves of alien creatures while the world tries to kill you. Think the automation itch of a factory game welded to a survival-combat loop, built in Unreal Engine 5 with Nanite and Lumen doing the heavy lifting on the look.
It came in hot. The game cleared over 500,000 wishlists before launch and pulled a peak above 6,700 concurrent players in a pre-launch playtest that scored around 91 percent positive. It hit Steam Early Access on January 6, 2026 at a discounted 15.99 dollars, and the user reviews have settled into Very Positive territory. Creepy Jar has been public about the plan: roughly a year in Early Access, a full 1.0 targeted for 2027, with new biomes, wildlife, building tiers, and combat mechanics on the roadmap.
The multiplayer is the part this audience cares about. Co-op runs up to four players, one host and three others. By default it is host-based, which means the world lives on the host's machine and that machine has to be on for anyone to play. That is the same trap we keep flagging across the genre. The difference is that StarRupture does not leave you stuck there. It offers a dedicated server as the way out. It just makes you work for it.
The server it shipped, warts and all
Here is what Creepy Jar actually put in players' hands, and why it reads as real intent buried under rough execution.
The dedicated server is a first-party Windows tool you launch through a batch file, not a community hack. It listens on the defaults you would expect from a Steam game, UDP 7777 for game traffic and UDP 27015 for the Steam query, both of which you forward through your router and Windows firewall. On paper that is a perfectly normal dedicated server. The problem is everything around the edges of that paper.
The launch-window bug that generated the most noise was almost comically basic. The server bound to UDP 7777 while the client tried to reach it over TCP 7777, so a correctly configured server would simply refuse connections, and players had no obvious way to tell that the mismatch, not their setup, was the culprit. On top of that, attempts to start a session could throw a Web Remote Call deserialization error pointing at a map asset, which is exactly the kind of message that makes a normal person close the tool and write an angry forum post.
Two more rough edges round out the picture, and they are the ones that still bite. The server does not auto-reload the last save on restart, so bringing the world back after a reboot is a manual step rather than a thing that just happens. And the whole thing is Windows only, with no official Linux build, which closes the door on the cheapest and most common way people quietly run a persistent game server on a small box. None of these is fatal. All of them add up to a tool that punishes you for not already knowing the routine.
The idle-state dance, in plain terms
The single biggest source of "the dedicated server is broken" complaints is not actually a bug. It is a design choice that nobody explains in the tool.
When you launch the StarRupture server, it does not start a world. It boots into an idle state and sits there, listening but empty. If you point a friend at the IP at that moment, they get a timeout and reasonably conclude the server is dead. The actual step is that you open the game's Manage Server menu, point it at the server's address, set a password and a session, and start it from there. Only then is the world live and joinable.
The server starting is not the same as the world starting. StarRupture splits those into two steps and tells you about neither.
Once you know the dance, it is fine. A handful of setup guides have sprung up specifically to walk people through it, and the community has converged on a reliable sequence. But "once you know the dance" is doing a lot of work in that sentence. A tool that needs a third-party guide to perform its core function on first launch is a tool that shipped before its onboarding did. That is the gap between StarRupture's server and Romestead's. Both exist. Only one of them is something you can stand up on a quiet afternoon without a browser tab full of workarounds open beside it.
Why the studio's track record matters here
If the story stopped at "the server is janky," this would just be a complaint. It does not stop there, and that is the genuinely interesting part.
Creepy Jar is not a first-time studio fumbling its first multiplayer feature. It is the team that shipped and supported Green Hell through years of Early Access and beyond, a game that grew co-op and dedicated-server support over its lifetime rather than at launch. They have walked exactly this road before. That history is the reason to read the rough StarRupture launch as a starting point rather than an ending.
And the post-launch record backs that read. The April 2026 Update 1 shipped a round of dedicated-server stability fixes alongside its content, specifically calling out improved stability when a dedicated server loads a session and proper synchronisation issues that only showed up in server play. Later hotfixes, including 0.2.6, went straight at dedicated-server crashes on loading game sessions in certain scenarios. This is not a studio that shipped a server, took the marketing screenshot, and walked away. It is a studio iterating on the server in its actual patch notes.
That distinction is the whole ballgame for a self-hoster. A janky server from a studio that abandons it is a trap. A janky server from a studio that keeps it in the patch notes is a server that will quietly become good. The launch state told you almost nothing useful. The patch cadence is telling you something real.
The metric this case actually tests
We keep coming back to two filters on this site, and StarRupture forces a third one out into the open.
Filter one: shipped beats announced. StarRupture passes. The server exists, today, from the studio. Compared with a co-op game where the server is still a roadmap line, a rough server you can wrestle into working is strictly more useful than a perfect server that does not exist yet.
Filter two: the launch-day server is the leading indicator. StarRupture passes here too, with an asterisk. The presence of a first-party server at launch told you Creepy Jar expects people to run persistent worlds. The state of that server told you they shipped it early. Both are true at once.
Filter three, the new one: a server is only as good as the studio's willingness to maintain it. This is the filter Romestead let us skip because its server worked out of the box. StarRupture does not let us skip it. A dedicated server is not a static feature you tick off at launch. It is a piece of infrastructure that either gets patched into something dependable or rots into a footnote. The signal to watch is not whether a game's server is perfect on day one. It is whether "dedicated server" keeps appearing in the patch notes three, six, twelve months later. For StarRupture, so far, it does.
The honest bottom line
If you are running a four-person StarRupture crew and you were waiting for permission to stand up a persistent world, here it is, with conditions. The server is real, it is first-party, and the studio is actively fixing it. You will pay for that with a Windows-only box, a manual session-start dance the tool refuses to explain, and a save reload you have to do by hand after every restart. In exchange, your world stops depending on one person leaving their PC on, which is the entire reason a dedicated server is worth the trouble.
If you only play in short synced bursts with everyone online at once, the default host-based co-op is genuinely simpler, and there is no shame in using it until the server tooling smooths out.
The broader point is the one StarRupture made us say out loud. Shipping a dedicated server is the price of admission, not the finish line. Romestead cleared the whole bar in one jump. StarRupture cleared the first part loudly and is grinding out the second part in its patch notes. That is a more common, more honest version of how a good game server actually comes to exist, and the studios worth pointing a box at are the ones still showing up in the changelog long after launch week.