Keep the dedicated server only if your group needs an independently running world and accepts staying on the 0.3.5 branch; if you need Update 3, evaluate player-hosted co-op instead. If StarRupture is the server’s only workload, do not renew until you have checked the branch, saved-world recovery, and a workable alternative.
This is for community hosts and small groups comparing an existing dedicated-server rental with player-hosted co-op.
It is not an installation guide or a recommendation to rent a server for every game session.
Last updated November 8, 2026. The game-status details below are checked against the official dedicated-server and Update 3 announcements, the official 0.3.5 hotfix notices, and the StarRupture activity chart. The chart shows player activity, not search demand or proof that your community will remain active.
The decision is about continuity, not just the next update
The official announcement says dedicated-server support is stopping. After Update 3, the 0.3.5 version that supports dedicated servers is expected to remain available as a separate branch, but it will not receive later updates and will not include Update 3. The developer’s dedicated-server announcement is the source for that distinction.
That gives you two separate questions:
- Can the group still access its existing dedicated-server version? The announced 0.3.5 branch is intended to remain available.
- Will that branch keep up with new content? No. The announcement says it will not receive later updates or Update 3.
Do not treat “the branch remains available” as “the dedicated server remains actively supported.” The first is about access to a particular version; the second is about future updates and compatibility. Your renewal decision should follow the group’s preferred play pattern, not the assumption that the old server will eventually catch up.
| Your group’s priority | Path to evaluate | Main condition to verify |
|---|---|---|
| Members join the same world at different times | Keep the 0.3.5 dedicated server for now | Everyone accepts the frozen version, and clients can still join that branch |
| The group wants Update 3 content | Test player-hosted co-op | The host’s availability and the current co-op rules work for your group |
| The world matters, but nobody has checked save recovery | Pause the renewal decision | Make a separate copy and test recovery before changing modes |
| The machine also runs other services or game servers | Assess the whole machine | Decide whether the other workloads justify keeping the server |
When a persistent world matters more than new content
A dedicated server is worth considering if your members do not play at the same time and expect the world to be available when they log in. That benefit is separate from whether the game branch continues to receive updates. A community can choose to keep its existing world and accept the limits of 0.3.5, but should communicate that choice before renewing.
Before you treat the current world as a reason to continue renting, check:
- Whether each player’s client can select the same 0.3.5 branch as the server.
- Whether the server starts and members can connect using the version they intend to keep.
- Whether you have identified the actual save location and can restore a copied save.
- Whether the community is willing to stop receiving new content on that branch.
- Who will handle server restarts, access issues, and save copies if the usual administrator is unavailable.
The official 0.3.5 hotfix announcements can help you confirm which fixes were published for that version. They do not change the announced distinction between a branch remaining accessible and that branch receiving future updates.
Make a recoverable copy before you change anything
Do not guess a save path from a guide written for another version. Find the directory used by your current server, confirm that the process is stopped or that the game’s documented save procedure has been followed, and then set the path yourself. For example:
export SAVE_DIR="/replace/with/the/confirmed/save-directory"
export BACKUP_DIR="$HOME/starrupture-save-check"
test -d "$SAVE_DIR" && tar -czf "$BACKUP_DIR/world-before-mode-change.tar.gz" -C "$SAVE_DIR" .
sha256sum "$BACKUP_DIR/world-before-mode-change.tar.gz"
tar -tzf "$BACKUP_DIR/world-before-mode-change.tar.gz" | head
The first command checks that the path exists before creating an archive. The checksum gives you a way to verify that the archive has not changed; listing its contents helps catch an empty or incorrectly targeted archive. An illustrative output might look like this:
<checksum> /home/operator/starrupture-save-check/world-before-mode-change.tar.gz
<archive entries from the confirmed save directory>
The placeholder checksum and file listing above are examples, not game-specific output or a claim about the save-file names. Keep the original copy untouched. Test restoration on a separate environment that you control, and only then decide whether the group can accept the result.
When Update 3 is the deciding factor
If your members want the new content, a frozen 0.3.5 dedicated-server branch does not meet that requirement. The developers have published an Update 3 content announcement and a separate public test branch notice. Those announcements establish that Update 3 content and public testing have been announced; they do not establish a final release date or confirm how existing dedicated-server saves will behave in co-op.
Treat the co-op option as something to test against your group’s habits, not as a guaranteed one-for-one replacement for the dedicated server. Ask:
- Can the group arrange sessions when the player hosting the world is available?
- Does your group accept that the world may depend on a player-hosted session being started?
- Has anyone verified the current game rules for joining, saving, and resuming?
- Does a test session preserve enough of the group’s progress to make the switch acceptable?
If you cannot confirm these points, do not promise members a seamless migration. Keep the dedicated-server world intact while you test the new mode with a separate copy or a fresh test world. Do not overwrite the only working save to discover whether migration works.
When your group can meet around one host
Player-hosted co-op may suit a small, regularly scheduled group that is usually online together and can rely on a host being present. That is a different operating arrangement from an independently running server. It may be acceptable for a fixed team, but it is a poor fit if members expect to enter the same world whenever they choose.
Discuss the difference directly with the group:
- Host availability: Who can start and host sessions, and what happens when that person cannot play?
- Scheduling: Are members comfortable coordinating play times rather than joining on their own schedule?
- World continuity: Does the group need the world to remain available between sessions?
- Progression: Have you tested whether the current game supports the group’s intended save and progression path?
- Version choice: Is the priority the old dedicated-server world or access to Update 3 content?
The official announcements do not confirm that an existing dedicated-server save can be moved to co-op without loss. Until the developers document that behavior or your own isolated test verifies it, treat save transfer as unknown. Avoid making a renewal decision based on a migration assumption.
When other workloads change the rental calculation
If the machine also runs other game servers or legitimate services, the end of active StarRupture dedicated-server support does not automatically mean you should cancel the entire rental. Assess the full workload: which services still need a continuously available host, who uses them, and whether they have a tested alternative. If StarRupture is the only reason you rent the machine, compare the value of preserving the 0.3.5 world against the cost and effort of moving the group.
For an actual product and billing review, check the OSFP Cloud server options rather than assuming that a game update changes your rental terms. OSFP Cloud’s listed AMD physical servers use an AMD EPYC 7543P with 32 cores and 64 threads, with 128 GB or 256 GB ECC memory options. Storage is two directly connected 1 TB NVMe drives, without hardware RAID. Bandwidth options are 250 Mbps, 1 Gbps, or 2 Gbps, all listed as unmetered. The datacenter is in Tokyo. These are product specifications, not a guarantee about StarRupture performance or player capacity.
| Existing use of the machine | Renewal question | Sensible next check |
|---|---|---|
| StarRupture only; the group needs the old world | Is the frozen 0.3.5 branch worth keeping available? | Confirm branch access, save recovery, and group acceptance of no later updates |
| StarRupture only; the group requires Update 3 | Can co-op meet the group’s schedule and progression needs? | Test the current mode with a separate world before ending the existing arrangement |
| StarRupture plus other ongoing services | Do those services independently justify the host? | List owners, required availability, and migration plans for every workload |
| No one has verified the product or billing terms | Is the rental still appropriate for the remaining use? | Review the current product table and the billing-cycle guidance |
Do not infer that a rental is unnecessary just because one game’s dedicated-server branch is frozen. Equally, do not renew automatically because the machine is already running. Compare the machine’s remaining workloads with the rental terms shown in the current product information.
A renewal check you can complete before changing plans
Use this sequence so you can reverse course if the test fails:
- Record the current state. Note the server’s game version, selected branch, startup method, save directory, and the last time the community confirmed that it could connect.
- Copy and verify the save. Use the confirmed directory, create an archive outside the live save location, and verify that the archive can be listed and restored in a test environment.
- Ask the community to choose a priority. Get an explicit answer: preserve the 0.3.5 world for asynchronous access, or prioritize Update 3 and evaluate co-op.
- Test the intended path without replacing the live world. For the old branch, have representative members confirm they can select the matching version and connect. For co-op, verify host availability and the current save and progression rules.
- Review every other workload. If other services remain, decide whether they need this machine and whether they have a tested alternative.
- Only then adjust the rental. If the group has not validated a replacement and still depends on the old world, avoid ending the current arrangement before its saved data and access plan are secure. If the server is only for StarRupture and the group chooses co-op, plan the change after the test succeeds.
This order makes the decision reversible for as long as possible. It also separates three different risks: losing access to the current world, losing access to the old branch, and paying for a machine that no longer has a useful workload.
StarRupture renewal questions
What does “the old branch remains available” mean for my group?
It means the announced plan is to retain a 0.3.5 version that supports dedicated servers as a separate branch after Update 3. It does not mean that the branch will receive Update 3, later content, or ongoing updates. Before you renew, confirm that your players can select the same branch and that the game still supports your intended way of joining.
Is a StarRupture dedicated server the right choice for players who log in at different times?
It can remain useful if your group values an independently running world and is willing to stay on 0.3.5. That benefit does not make the old branch current. Verify that the group can access the branch, that the save is recoverable, and that members accept the absence of later updates before treating the dedicated server as a long-term choice.
Should I move to co-op before Update 3 is fully released?
Do not move the only copy of your world based on an unverified compatibility assumption. The public test announcement confirms a test branch, not final behavior for your save or a final release date. Check official updates, then test the current co-op mode with a separate world or copy and confirm that the group accepts its host and scheduling requirements.
Does losing StarRupture dedicated-server updates mean I should cancel the whole machine?
Only if StarRupture is the sole workload and the group no longer needs the old world. If the host also runs other game servers or services, assess those uses separately. Review their availability needs and migration plans, then compare the remaining value with the current product and billing terms instead of making the decision from one game’s support change alone.
Make the renewal conditional on verified use
If your group requires a world that members can enter independently, keeping the StarRupture dedicated server on 0.3.5 can make sense—but only if everyone accepts that it is a frozen branch and you have tested recovery. If Update 3 is essential, evaluate player-hosted co-op on a separate test before retiring the existing world. If the machine also supports other long-running workloads, make the rental decision for the whole machine, not for StarRupture alone.
A shared VPS or public-cloud instance can suit a temporary test or a light workload, but shared resources, variable usage charges, or limits on system and storage choices may not fit a host you need to control for multiple ongoing services. An exclusively rented AMD physical server is more relevant when you have a continuing workload that needs dedicated machine resources; it is not a reason to rent a full machine for a short test or for a game mode that no longer needs it. Check OSFP Cloud’s current product options against the services you will actually keep, then renew only when those services justify the host.
Questions
Can players still use the old StarRupture dedicated server after Update 3?
The announced plan is to retain the dedicated-server-supported 0.3.5 version as a separate Steam branch after Update 3, but that branch will not receive later updates or Update 3 itself. Treat continued access as different from continued support: verify that your clients can select and run the same branch before deciding to keep the world online.
Will the 0.3.5 dedicated server branch receive more patches?
The official support notice says the 0.3.5 branch will remain available for dedicated servers but will not receive subsequent updates. Check the official announcements again before renewing, since a later policy change would affect this decision. Do not assume that a server staying accessible means its game content, compatibility, or fixes will continue to advance.
How does a dedicated server differ from player-hosted StarRupture co-op?
A dedicated server is the better fit when your group values an independently running world that members can join on different schedules. Player-hosted co-op is worth evaluating when players can meet while the host is available and the group wants to follow Update 3. Confirm the current game rules and save compatibility; do not assume a dedicated-server world can transfer intact.
Should a StarRupture community host renew the server now?
Not automatically. If the server is only for StarRupture, first confirm that the group accepts remaining on 0.3.5 and that the existing save can be recovered. If Update 3 is essential, test the co-op option before changing the rental. If the machine also runs other ongoing services, judge renewal against those workloads as well.
Keep Your Server Flexible Beyond Update 3
Run your workloads on a whole physical server with dedicated CPU and memory.
From $462 / month