Enshrouded multiplayer is cooperative PvE. You can play with friends by having one player host a world from the game, or by joining a dedicated server that runs independently of a player's session. A paid server is not required for a small group that plays together at agreed times.
At the 1.0 launch, the PC listing supports up to 16 cooperative players and the PS5 listing supports up to 8 online players. Launch crossplay is not supported. Confirm that everyone is on a compatible platform before arranging the session: owning the game on different platforms does not itself make the same world joinable.
Choose who owns the shared world
Before anyone begins gathering, decide which world the group will use. Your character can move between worlds, but the base, rescued survivors and most station-dependent crafting progression belong to the world itself. Starting separately and later joining one friend does not combine all the settlements into a single shared save.
For occasional sessions, one player can host directly. That person opens the chosen world for multiplayer and shares the details needed to join. The arrangement is simple, but availability follows the host: when that session closes, the other players cannot continue in that hosted world until it is available again.
A dedicated server suits a group whose members play at different times. The world remains available while the server process is running, including when the person who created it is offline. The group still needs someone responsible for the world save, access settings and backups; independent availability does not mean the world maintains itself.
| Group situation | Practical starting arrangement | Main consideration |
|---|---|---|
| Friends usually play together | One player hosts in the game | Everyone depends on that host's session |
| Members come and go at different times | Dedicated server | Someone maintains the running server and world |
| You want to try cooperation first | Join a friend's existing session | Character travel is separate from world progress |
| Players own different launch platforms | Check compatibility before planning | Crossplay is unavailable at launch |
Choose based on actual schedules. There is no need to rent a server just because two friends want to try the game together, and no need to keep relying on one person's availability when a larger group is already struggling to meet at the same time.
Host a first cooperative session
Use the game's hosting flow to select or create the world you want to share. Check the host settings and player access before inviting anyone. Give the world a recognizable name and use the intended password or permission group rather than handing every participant administrative access by default.
Ask the first friend to connect before the entire group arrives. A short join test identifies a hidden session, password mismatch or platform misunderstanding while the setup is still easy to inspect. Once that connection works, the remaining players can follow the same confirmed route.
On PC, Steam invitations provide another way into an in-game hosted session. If a friend's session is not visible in the list, verify that the host is actually in the hosted world and check the relevant discovery filters. A private profile can affect visibility, so an invitation can be useful when the session browser is the obstacle.
Keep the host's role clear. Hosting is not simply opening an invitation once and leaving: that session needs to remain running for the group to continue. Agree on an end time or tell the other players before closing the world so they can finish what they are doing.
Join the correct session
From the Join flow, inspect the server filters before concluding that the world is missing. Filters can hide dedicated servers, password-protected sessions, full sessions or worlds outside the selected conditions. A running server can therefore be absent from your current filtered view.
For a dedicated server on PC, enable the dedicated-server display option when looking in the game browser. If the owner has provided an address, obtain the query port as well as the IP address. A gameplay port and a query port are not interchangeable simply because both appear in the same hosting panel.
The Steam favorites route is useful for a server the group will revisit:
- Obtain the server's IP address and query port from the owner.
- Open Steam's Game Servers window from the View menu.
- Add the address and query port to Favorites in the address-and-port format.
- Return to Enshrouded and inspect the server list.
- Join with the password for your intended role.
Save the confirmed details somewhere the group can retrieve them. A favorite entry reduces repeated searches, but it does not bypass an incorrect password, a stopped server or incompatible game builds. If the address changes, update the saved entry instead of continuing to test an obsolete one.
Understand the password and your permissions
A player's role can be determined by the password used when joining. That makes the joining credential part of the access arrangement, rather than simply a shared secret that has the same effect for every participant. The owner should tell you which password is intended for ordinary play.
Admin, Friend, Guest and Visitor roles can have different permissions. The exact allowed actions depend on the actual world or server configuration. Do not assume that a role name guarantees building, chest access or terrain editing in every hosted environment.
If you can join but cannot build or open the expected storage, ask the owner to inspect your intended role and its permissions. Reinstalling the game or making a new character will not grant an action that your current role is configured to deny.
For the owner, share the least powerful role that still allows the player to participate as intended. Keep the administrator credential with the people maintaining the world. If the group wants to invite someone only to look around a settlement, a restricted visitor arrangement can serve that purpose without giving the same access as the core building group.
Separate character progress from world progress
Your equipment, inventory, character level and unlocked skills travel with your character. Joining another compatible world does not require abandoning that character and starting from level one. This is useful when a friend wants help in their own world or the group decides on a different shared save.
Other progress is attached to the world. Most recipes that depend on survivors and crafting stations require those survivors and stations to be available in the destination world. If an experienced character arrives in a fresh world, the character's level does not automatically summon all the craftspeople rescued elsewhere.
| Travels with the character | Depends on the destination world |
|---|---|
| Equipment and carried inventory | The settlement and its placed objects |
| Character levels and unlocked skills | Survivors available to summon |
| Personal crafting recipes | Most survivor and workstation recipes |
| Personal map discoveries and lore | Discoveries shared only by other players |
| Shroud roots already collected | The world's own unlocked crafting setup |
The Shroud root distinction also prevents a misleading progression shortcut: changing worlds does not let the same character repeatedly farm already collected root rewards as if each world made the character forget them. Treat personal collection history and world state as different records.
When something seems missing after a move, identify which side owns it. Missing workstation recipes often mean the destination world's crafting progression is behind yours. Missing buildings mean you are in a different world, not that your character inventory should contain the entire previous base.
Plan shared progression before splitting up
A cooperative group benefits from agreeing on the next shared objective. Decide whether the session is about rescuing a survivor, collecting materials, exploring a new route or improving the base. This keeps one player's progress from unintentionally changing what the rest of the group expects to do together.
Use the quest journal on your own character when returning after an absence. Do not assume that every quest step has the same personal and world behavior. The useful first check is what your journal currently asks you to do and which survivors, stations and locations are already present in that world.
If some players prefer building and others prefer exploration, divide the work explicitly. The group can share resources and equipment without every member performing every gathering task. Keep important progression materials recognizable in storage so a shared upgrade ingredient is not accidentally consumed by an unrelated decorative project.
Before a difficult expedition, check that each participant has the movement tools and supplies needed for the route. A path that the host can traverse does not prove that a newly joined character has the same glider, grappling equipment or preparation. Meet at a safe place and resolve those differences before entering the dangerous section.
Diagnose a failed connection in order
First confirm platform compatibility and the world being online. Then inspect the server filters and saved address. Next verify the password and whether the intended role has an available slot. These checks distinguish an unavailable world from a world that is available but not currently visible or accessible to you.
If the group connected previously and suddenly cannot after an update, compare the client and server builds. The current snapshot is 1.0.0.2, but a server may still need its update applied. An outdated server and an updated client can look like a general networking failure even when the saved address is correct.
The owner should also check role-related reserved slots when a server reports full unexpectedly. A server's total capacity and the capacity available to the joining role are not always the same thing. Use the actual configuration to explain the result rather than assuming the browser's player count proves that every role can enter.
Finally, keep world and character backups separate in the maintenance plan. A server world backup protects the world state; it does not substitute for protecting each player's client-side character. Once the first successful session works, record who maintains each part so future updates, moves and restores have a clear owner.