Set Up a 7 Days to Die PvP Server: Rules That Hold Up

A 7 days to die pvp server needs more than a setting that lets players hit each other. Choose who can attack whom, how hard claimed bases are to break, what happens to a player’s inventory on death and what admins do when a raid crosses your rules. Put those choices in writing before the first player joins. In V3, player-versus-player mode and land claims are server properties; death drops and block damage live in SandboxCode, not the old standalone XML lines copied around in older guides. This reference helps you choose a coherent ruleset and check it before launch.

If you are running the server yourself, the game’s settings and serverconfig.xml are enough to configure these rules. If you’d rather edit them in a panel, Game Hosting’s 7 Days to Die server page has fields for PvP and claims, and its Players tab supports timed bans and announcements. Either way, decide the policy first; a control panel cannot make an unclear rule fair.

Choose who can hurt whom before inviting players#

PlayerKillingMode controls the basic PvP relationship. We installed Steam’s public dedicated-server app 294420 (build 25661908) on 16 October 2026 and inspected its V3.3.0 Stable serverconfig.xml; it uses 3 by default, which allows everyone to hurt everyone. That default is a surprise if your group expected cooperative PvE, so set the mode before sharing the server name or password. The official V3.3.0 Stable notes date that release to 5 October 2026.

Value	Mode	A fit when…
0	No one	Players want PvE and do not want player damage.
1	Allies only	Your community groups players into allies and wants rival groups to fight.
2	Strangers only	You want allies protected from each other while unaffiliated players remain vulnerable.
3	Everyone	Friendly fire is part of the rules and players accept open combat.

The mode tells the game who can hurt whom; it does not define a tournament, a safe zone schedule or permission to destroy every structure. Write down whether attacks are allowed everywhere, whether allies can switch sides, and what counts as an accepted raid. If you want peaceful building, set mode 0. For an opt-in community, mode 1 can reduce accidental team damage, but still explain how players become allies. After changing it, read the saved value in the current server configuration or panel and test with willing players in a disposable world.

Balance land claims against the kind of raids you want#

Claims make bases harder to damage while the owner is online or offline. Start with the settings together; increasing one number alone can create an odd rule. The current panel schema exposes claim count, size, dead zone, expiry, decay mode, online and offline durability, and offline delay. The default values shown by Game Hosting are five claims, 41 blocks wide, a 30-block dead zone, seven real days before expiry, slow decay, 4× durability online and offline, and no extra offline delay. Confirm the current defaults in your own build before setting up a community.

Claim choice	Current V3.3.0 default	Rule question to settle
LandClaimCount / LandClaimSize / LandClaimDeadZone	5 claims / 41 blocks / 30 blocks	Can a small team protect its main base without locking out a whole town?
LandClaimOnlineDurabilityModifier	4×	How hard should claimed blocks be while the owner is online?
LandClaimOfflineDurabilityModifier / LandClaimDecayMode	4× / 0 (slow decay)	Is an offline raid permitted, and at what point?
LandClaimExpiryTime	7 real days offline	How long can an inactive player reserve territory?
LandClaimOfflineDelay	0 minutes	Will a logout during an attack change the claim’s protection?

These defaults came from the public V3.3.0 Stable package’s shipped XML, not a copied V2.5 guide. LandClaimOfflineDelay is a timer before the offline hardness setting applies. Do not advertise it as guaranteed raid protection or as proof that an attack stops when someone disconnects. The setting description does not answer every mid-raid edge case. Choose a delay only after testing it in a private world on the same build, then publish exactly how your group handles combat logging. For a full field-by-field explanation, use the V3 server settings reference.

Decide what death costs and keep it separate from PvP mode#

PvP permission and death consequences are separate decisions. PlayerKillingMode decides whether player damage is allowed; death and item-drop choices are gameplay settings. Since V3.0, options such as DropOnDeath, DropOnQuit and block damage belong in SandboxCode. A guide telling you to add those as standalone serverconfig.xml properties is using an older configuration model.

Before launch, open the current Sandbox Options editor or the version-matched server panel and review:

Rule	Choice to make
Drop on death	Decide whether players drop nothing, their toolbelt, backpack, everything or another available option.
Drop on quit	Decide whether leaving the game has a separate inventory consequence. Avoid rules that punish an ordinary connection failure without warning.
Block damage	Decide whether player base damage matches your raid policy; do not assume that turning on PvP alone sets it.
Trader protection	Confirm how protected trader areas fit with the places where combat is allowed.

The available labels and ranges can change between game builds. Use the in-game options or the current version’s shipped catalog as the source; do not paste a SandboxCode value from a different version without checking it. Tell players which items they risk losing and whether quitting during a fight counts as leaving combat. The broad V3 server settings reference explains where those gameplay choices live.

Set newcomer protection without promising a safe server#

New players can be easy targets in an open PvP world. Review the current player safe-zone level and duration and the spawn-near-friend option, then explain what those settings protect. Spawn protection can soften the first minutes; it is not a general truce, and it does not replace an admin response to harassment. A public server also needs clear expectations for targeting new arrivals, destroying starter shelters and taking items from unattended storage.

If your community wants a gentler start, agree on a short, specific grace rule, such as no player attacks until a newcomer leaves a marked start area. Then decide how players signal when the protection ends and who can resolve a dispute. Avoid vague rules like “don’t be toxic”: players need to know which actions are allowed and what consequence follows. The settings reference can explain the server fields, but only your written policy can define community expectations.

Publish raid windows, wipes and evidence rules#

Write the rules where players will see them before joining. Cover the points that regularly cause disputes:

• Which PlayerKillingMode is active and whether allies can damage one another.
• Whether raids may happen at any time or only during published windows.
• What offline claims, logout delays and base damage mean for an attack in progress.
• Which inventory drops apply on death or quit.
• Whether trader areas and newcomer protection are exceptions.
• How to report a rule violation, what evidence admins need and how long to appeal.
• When the world will wipe, and which changes require a new save.

Keep a dated copy when rules change. Announce a new raid window or wipe date in game before it takes effect, rather than relying on players to notice a revised document. A short ruleset players can quote is easier to enforce than a long list of implied exceptions. Do not promise admins will reverse every disputed loss; define what information they review and what they can change.

Enforce disputes with commands and player controls#

Use admin tools for specific violations, not as a substitute for rules. The server’s blacklist and moderation commands can kick or ban a player; the current moderation commands guide explains the syntax and related access controls. For a small private server, a password may be enough. A public community should decide who can investigate reports, who can issue a ban and how another admin can review that decision.

Keep a record of the player’s ID, the rule involved, the reason and the duration. If the conflict is about a raid, save the relevant logs or other evidence before changing the world. Announce rule changes and scheduled restarts in plain language. Game Hosting’s Players tools include timed bans and server announcements if you’d prefer those controls in the panel; self-hosted admins can use the game’s own commands and files instead. Neither route determines whether a player’s accusation is true, so agree on the review process ahead of time.

Check the platform rules before opening crossplay#

This guide’s PvP settings apply to the current game, not the original console edition released in 2016. For PC with PS5 and Xbox Series X|S, the developer’s current dedicated-server cross-platform requirements require ServerAllowCrossplay=true, a public listing, EAC enabled, IgnoreEOSSanctions=false and a maximum of eight players. Players also need compatible versions. Console crossplay does not support PC mods, so do not plan a modded PvP setup and promise console players can join.

The official requirements page includes legacy-named gameplay options. In V3, many such gameplay settings moved into SandboxCode; do not add an old BloodMoon, drop or damage property to the V3 XML because an older crossplay checklist lists it. Start with the server’s current version and the developer’s accepted ranges, then check the in-game listing with the platforms you intend to support. The original Xbox One and PS4 edition is separate from today’s console crossplay; it cannot join this current dedicated-server setup.

If you use mods on a PC-only server, check each mod’s instructions: some run on the server alone, while client-side mods must also be installed by the players who need them. The developer’s mod-use guidance warns that third-party mods can be unstable or unsupported and says they must match the game version. It recommends a new save when isolating mod issues. For installation steps, see how server mods work. Keep a clean, version-matched copy of your world before testing an overhaul, and don’t describe a third-party mod as your own work.

Run a private rules check before the first public raid#

Before inviting the wider community, use a disposable world or a copy you can afford to lose. Check the rules in this order:

1. Confirm server and player builds match and the chosen PvP mode is visible in the saved settings.
2. Ask two consenting players to check whether the mode allows the intended attack and blocks the unintended one.
3. Confirm the claim’s online and offline settings separately; don’t infer claim behavior from a menu label alone.
4. Verify death and quit drops, trader protection and newcomer settings in the game version you will run.
5. Test the published report and ban process with a harmless, agreed example, then tell players where the final rules live.

This is a rules check, not proof of population, performance or protection from every raid edge case. If you would rather configure the server through forms and manage player actions from one place, compare the 7 Days to Die hosting setup with your self-hosted option. Keep your version, rules and save copies aligned before the real world starts.

Quick answers

Can you PvP in 7 Days to Die?

Yes. Set PlayerKillingMode to decide who can damage whom: no one, allies, strangers or everyone. The default is full PvP, so confirm the choice before players join.

How do I turn off PvP on my 7 Days to Die server?

Set PlayerKillingMode to 0 (No one/PvE), then save the server settings and restart if your host requires it.

How do I protect bases from offline raids?

Review the land-claim online and offline hardness, decay mode, expiry and logout delay together. None of these replaces clear raid rules, and you should test timing in a private world before making it a community promise.