Vaultbreakers supports a party of up to three in the public Demo: the player plus as many as two friends. October Alpha notes describe a more developed social layer with Steam friend integration, invites, recently partied players, blocking, kicking, party-leader Haven behavior, and Haven hubs with up to ten Alpha players. Those Alpha features are announced scope, not a guarantee that every button exists in today’s Demo.
Check identity, build, and availability first
Every intended party member should run the same current client. AppID 4488770 is the public Demo; AppID 306910 is the unreleased base game; a historical Playtest listing is separate. Compare the visible title, Steam update state, build if shown, and whether each player completed the required onboarding.
Do not diagnose an old Playtest invitation as a Demo problem. Likewise, a base-game wishlist does not grant Alpha access. Follow the official instructions for the active test and avoid third-party keys, account transfers, or forced package installation.
Create the party from a stable state
Return everyone to Haven or the current client’s equivalent safe lobby. Let one player become leader and send one invite at a time. Wait for the member to appear before sending the next. Confirm the final party count and each member’s ready or location state before starting an expedition.
If an invite fails, cancel the stale request, verify Steam online and friend status, then resend from the same layer. Do not change leader, privacy, client, firewall, and overlay simultaneously; changing one variable makes the cause visible.
Understand the leader’s Haven
October notes say party members enter the party leader’s Haven and that the system can automatically make a Haven private. This is Alpha behavior to verify when the client opens. The practical questions are which upgrades or NPC states are visible, whose quest controls departure, and what happens when leadership changes.
Before an Alpha party forms, each player should secure personal inventory and read active quests. After joining, confirm whether displayed Haven changes are local, leader-owned, or shared. Do not spend materials based on an assumption about another player’s building state.
Separate social hubs from expedition parties
The same notes describe Haven hubs supporting up to ten Alpha players, while an expedition party remains a smaller group. Seeing more players in Haven does not mean ten can enter one expedition. Check the current party panel and mode rules rather than counting nearby avatars.
Use hub presence for social connection without sharing private account information. Recently partied lists can help reconnect after a good run, while block and kick tools can manage unwanted contact. Verify the exact Alpha interface before publishing button-by-button instructions.
Use matchmaking claims cautiously
The official sources support co-op and announced social improvements, but they do not establish a permanent server-region list, queue algorithm, latency threshold, role matching system, or cross-platform pool. Do not promise that selecting a region, changing DNS, or opening ports will fix a queue unless the current support instructions say so.
When matchmaking appears slow, record client, build, mode, difficulty, party size, UTC time, approximate location, queue duration, and whether direct invites work. Stop and restart the queue once from a stable Haven state. Repeated blind retries can hide an outage or access mismatch.
Diagnose party failures in a fixed order
Confirm the correct client and updates. Confirm Steam sees each player online. Confirm onboarding and Haven state. Confirm party capacity and privacy. Remove stale invites. Let a different player create a fresh party only after recording the first attempt. If one member alone fails, compare that member’s exact step with the successful members.
Avoid deleting save or configuration folders. Demo progress is announced to carry into Alpha, and destructive steps can cost useful evidence. Disable third-party overlays or injectors only as a controlled test, then restore the baseline if nothing changes.
Handle disconnects without inventing recovery rules
If a member disconnects, note whether they return to the expedition, Haven, or title screen and whether the remaining party continues. Record quest items, carried gear, and objective state before and after. Rejoin behavior can change by client and test; historical drop-in rules are not automatically current.
For repeated disconnects, capture party leader, member affected, location, action, build, error text, and whether voice or other network activity continued. This distinguishes a game-session symptom from a whole connection loss.
Use block and kick tools responsibly
October notes include block and kick support for Alpha. Use these for the live interface’s intended safety and party-management purposes. A kick can alter the affected player’s expedition or Haven state, so do not treat it as a latency fix. Blocking should not be reversed casually if it was used for harassment or safety.
When reporting conduct, use the official channel and provide the minimum relevant evidence. Do not publish account identifiers or organize retaliation. A gameplay guide cannot promise moderation outcomes.
Prepare the group for departure
Once the party is stable, agree on mode, difficulty, objective, route, loot pause, and extraction caller. Check health supplies, wounds treatment, equipment condition, and controller or input readiness. A technically successful party is not ready until everyone understands the expedition purpose.
For combat and route coordination, continue to the Co-op guide. For the difference between the public Demo’s PvE and the broader advertised game, use PvE and PvPvE.