How to Join a Romestead Server and Play With Friends

Pick the right way to play together first

Before anybody starts typing addresses or forwarding ports, decide which multiplayer setup actually matches your group. In Romestead, the developers do not host any servers: the “host” is either one player running the world from their game, or the machine running the dedicated server. That matters because it decides who has to stay online, which network path your traffic takes, and what breaks first when connections are poor.

Use this matrix to choose the least awkward option for your group.

The trade-off is straightforward. Steam-hosted games are the easiest because joining goes through the Steam Datagram Relay network, which the developers say is usually more stable and faster and also hides the host’s IP. The weakness is persistence: if the host quits, crashes or just goes to bed, the world is gone until they return. Direct IP and dedicated servers ask a bit more from the person running them, but they remove the Steam join path from the chain, and players told the developers that connecting this way made their repeated disconnects disappear.

Join a friend’s hosted game through Steam

This is the quickest route when one player is happy to be the host and everybody is playing in the same session.

For the host

1. Open Multiplayer.
2. Choose Host multiplayer.
3. Pick the world you want to host.
4. Use the Use password option if you want the session locked.
5. Select Host.

The host’s machine is doing two jobs at once: running the world and playing in it. That means the host’s internet upload quality matters to everyone else, not just their own play. If your group has one person with the strongest connection, let them host; that is the first thing the developers themselves recommend.

For invited players

1. Wait for the Steam invite and accept it, or open the host from your Steam friends list and join from there.
2. If the host set a password, enter it exactly as given.
3. Load into the world with your character.

This route needs no port forwarding because the join is handled through Steam rather than a public port on the host’s router. That is why it is the cleanest option for quick sessions. The downside is that your world availability is tied to the host staying online and in control of that save.

For players on the same network

If everybody is on the same home network, use Host LAN multiplayer instead. That keeps the traffic local, which removes outside internet routing from the equation. It can be a cleaner fix than Steam invites when the issue is the route rather than the world itself.

Join a server by IP and port

Use this method for Host LAN sessions, self-run dedicated servers and rented servers. It is also the route to try when Steam joining works in theory but your group keeps seeing disconnects in practice.

The join path looks like this.

1. Open Multiplayer.
2. Choose Join multiplayer.
3. Create or select a character.
4. Open Advanced/LAN.
5. Enter the server Address and Port in the separate fields.
6. Select Connect.
7. If asked, enter the server password.

The important detail is that Address and Port are not one combined field. If your host sends 123.45.67.89:8050, enter 123.45.67.89 in Address and 8050 in Port. If you paste the whole string into the Address field, you are likely to get Invalid Address or Unknown Host.

Joining by IP is more literal than Steam invites. The game is trying to contact exactly the machine and UDP port you specify, so every small mistake matters: a wrong digit, a stale IP, a changed port, or a server that has not fully finished starting. The good side of that strictness is that once the path is correct, you bypass the Steam join layer completely.

On dedicated servers there is no server browser and no Steam token system to hide the details from players. People join with the address and UDP port you give them, then the password if one is set.

If you are the one running the server

For friends to join successfully, you need to share three things: the public IP, the port, and the password if the server uses one. Sending only “the server is up” is not enough, because Romestead’s direct join expects exact network details.

What to share on a rented server

Your host panel usually shows the IP and port together, and the password is usually in the startup or config settings. Wait until the panel shows the server as fully started before telling people to connect; trying early often looks like a timeout even though nothing is wrong except the world is not ready yet.

What to set on a self-run dedicated server

In config.json, the key fields for joining are Password and Port. A password can be null for no password, but a random password is strongly recommended. A blank password makes the server public to anyone who knows the address, and there is no server browser to act as a filter.

{
  "Password": "set-a-random-password",
  "Port": 8050
}

Romestead uses UDP 8050 only by default. If you change the port in the config, you must allow and forward the new one instead. On a self-hosted machine, there are two separate network jobs:

• Firewall allow rule: lets the server process receive UDP traffic on the machine itself.
• Router forward: sends outside traffic from your public connection to the correct machine on your home network.

That is why a server can work locally but still fail for outside friends: the software is running, yet the packets never reach it from the internet.

This is the network path to check on home-hosted dedicated servers.

Windows firewall:
New-NetFirewallRule -DisplayName "Romestead Server" -Direction Inbound -Protocol UDP -LocalPort 8050 -Action Allow

Linux:
sudo ufw allow 8050/udp

After that, forward UDP 8050 on the router to the server machine’s local IP. If the machine later gets a different local IP from the router, the old forward points at the wrong device, which is why a restart can break a setup that worked the day before.

Useful console checks and commands

Use list in the server console to see who is connected. If a player is causing trouble, kick and ban use IP addresses, and bans only last until the next server start.

list
save
stop
say <message>
kick <ip>
ban <ip>
unban <ip>

stop does a full save and then stops the server cleanly, which is the safe way to close it. quickstop skips that save. The server autosaves every 6 minutes and keeps one rolling backup in saved_worlds/, but a clean stop still matters if you are moving the world or changing branch. If you want more background on the admin side, our guide to self-hosting a game server covers the practical setup work around running a box at home.

Keep everybody on the same version and branch

If you see the exact message “Client version 0.X.X_X is not compatible with server version 0.X.X_Y”, the host and joiner are on different Romestead versions. The player or server on the lower number must update. If you have already updated in Steam and the message still appears, restart Steam so the running client actually switches to the new build.

On a dedicated server, the server tool must be updated too. Re-run the same SteamCMD app_update you used for the Romestead Dedicated Server tool, which uses app 4763510. The tool needs a Steam account that owns Romestead, and if you are self-running it on Linux it uses dotnet Server.dll with the .NET 8 Runtime; on Windows it uses Server.exe.

If you are trying the developer-recommended 0.26.3-beta branch to fix disconnects, everybody must be on that same branch, including the dedicated server. The good part is that saves are compatible between the beta and main branch, so changing branch is low-risk. How you know this fix worked is simple: the version error disappears and the join proceeds to the password or load stage instead of failing immediately.

Fix repeated disconnects in the order the developers suggest

Repeated disconnects usually mean network messages between host and client are not arriving in good time. That can be the host’s upload, the route between players, or the join method itself. Work through the fixes in this order instead of changing everything at once, so you can tell what actually solved it.

Use this flow to narrow it down quickly.

1. Put the strongest connection in the host seat.

   In player-hosted multiplayer, the host is the server. They simulate the world and send updates to everyone else, so weak upload or unstable routing on the host affects the whole group. The extra load sits mostly on the host’s upload and CPU. If this helps, other players should see fewer pauses and fewer disconnect warnings without changing their own setup.

2. Try the 0.26.3-beta branch.

   The developers specifically point disconnecting groups to this branch, and saves are compatible between beta and main. The trade-off is administration: everybody, including any dedicated server, must be on the same branch or you trade disconnects for version mismatch errors. You know it helped if the same group can play longer under the same conditions.

3. Join by IP instead of Steam.

   Steam joining goes through Steam Datagram Relay, which is usually good and protects the host’s IP. But the developers also report that players stopped disconnecting after hosting through Host LAN multiplayer or the dedicated server tool and connecting by IP. Why that can help: you remove the Steam join path and use a direct UDP route to the server instead. The trade-off is extra setup, because internet players may need port forwarding on self-hosted worlds.

4. Move the world to a dedicated or rented server.

   This fixes two common weaknesses at once. First, it circumvents the Steam-hosted session path. Second, it separates the server from the host’s play PC, so one person’s game client is no longer competing with the world process for CPU time, memory and network upload. It also solves the “host left, world vanished” problem because the world stays online without a player remaining logged in.

5. Try a VPN for the affected player or the host.

   The developers suggest this because some disconnects are really routing problems between networks, not a Romestead world problem. A VPN can force a different route. The trade-off is that it adds another layer to the path, so it is only useful when the existing route is bad. If the network quality indicator steadies and only that player’s drops stop, the route was the issue.

The network quality indicator added in the Autumn Update (0.26.1, September 2026) is the quickest way to spot where the weakness really is. If only one player shows poor quality while everyone else is fine, start with that player’s route. If several players all look bad relative to the host, the host connection is the likely bottleneck. If the host quits and everybody is thrown out, that is not a route problem at all; it is simply the limit of host-and-play.

Symptom, likely cause, first fix

These are the most common join failures and what they usually mean in Romestead. Start with the first fix before you move on to broader changes.

Player count, difficulty and basic capacity planning

Romestead is designed for 1-8 players. The developers say it is finely tuned for 1-4 players, but it scales for groups up to 8 players, and difficulty scales with the number of players in the world. That scaling affects more than balance: more players also mean more state to simulate and more updates to send, which raises CPU, memory and outbound bandwidth load on the host or server. Romestead is on PC through Steam only for now (it is Steam Deck Verified), so there is no console version or crossplay to plan around; the developers have said console versions would only come after full release.

For dedicated servers, the wiki guidance is a 2 GHz 4 threads CPU, 4GB RAM for a standard world up to 4 players, and 8GB for large worlds or 5+ players. Outbound network use can reach 2 MB/s. Large worlds also need 8GB RAM just to generate. If you are planning hardware rather than just joining a friend, our overview of game server hardware requirements helps you line those jobs up with the machine you intend to use.

The important resource split is this:

• CPU: world simulation and keeping server ticks responsive.
• RAM: holding world data, player state and larger world generation.
• Outbound bandwidth: sending updates to every connected player.

If you host and play on the same PC, the game client and server work compete for those same resources. That is why host-and-play feels fine for a small casual session but often becomes the weak point for larger worlds or more players.

One advanced server setting worth knowing

SleepThresholdMs defaults to 10 ms. Setting it to -1 keeps the server always busy for the least jitter, and the developers prefer that for best gameplay. The trade-off is plain: it runs the CPU at 100%. Leave the default if you are trying to keep resource use sensible; consider -1 only when the machine has CPU headroom and you are chasing smoother feel rather than lower usage.

Keep the world online without the host

If your real problem is not “how do we join once?” but “how do we keep this world available?”, stop treating it like a quick host session. An always-on setup changes the social bottleneck as much as the technical one: nobody has to wait for a particular friend to come online just to load the world.

If you are moving from a hosted save to a dedicated or rented server, you do not need to abandon the world. Upload the save folder through the host’s file manager or FTP so the server loads the same world. If you want that always-on route without doing the home network work yourself, our Romestead server hosting comparison is the quickest place to sort managed options from self-run ones.

Romestead server FAQ

How do I join a friend’s Romestead game?

If your friend is hosting from the game, they go to Multiplayer > Host multiplayer and you join from the Steam invite or friends list. If they are running a Host LAN, dedicated server or rented server, use Multiplayer > Join multiplayer > Advanced/LAN and enter the Address and Port separately. Ask for the password too if the world is locked.

What port does a Romestead server use?

The default port is UDP 8050, and Romestead only needs that one UDP port. On a home-hosted dedicated server, that port must be allowed in the firewall and forwarded on the router to the server machine’s local IP. If you change the port in config.json, use the new port everywhere instead.

Why does Romestead say my client version is not compatible with the server?

The message means the client and server are on different game versions or branches. Update whichever side has the lower version number, and if you are using a dedicated server, update that too by re-running the SteamCMD update. If anyone is on 0.26.3-beta, everybody including the server must match that branch.

Why do I keep disconnecting from my friend’s Romestead world?

The developers say repeated disconnects usually mean network messages are not arriving in good time. Start by having the strongest connection host, then try the 0.26.3-beta branch, then join by IP to a Host LAN or dedicated server instead of through Steam. Use the network quality indicator to see whether the weak point is one player’s route or the host’s connection.

Can my friends play in our Romestead world when I’m offline?

Not if you are hosting from the game itself. In that setup, the world exists only while your game is running and hosting. To keep the world available when you are away, move it to a self-run dedicated server or a rented server.

More Romestead and co-op server help

The host comparison, plus our guides on running a game server yourself.