Quick Answer
Pick the hosting model before touching settings — it decides your failure paths and backup locations. In-game host: fastest for 2-4 players on one person's schedule; the world lives and dies with that session. Dedicated server: stays up unattended; SteamCMD app_update 380870, UDP 16261/16262 by default, profile files under Zomboid/Server. Managed host: the provider runs the machine, you run the rules. All three share one rule: prove a clean join with zero mods before adding anything — and hosted-server mods go through BOTH the Workshop and Mods sections.
Table of Contents
Host method decision
Pick the hosting model before editing any setting — the failure path and the backup location both depend on it. Each row names the setup work the model actually requires.
| Your situation | Do exactly this | You've picked right when |
|---|---|---|
| Two to four players on one person's schedule | Use the in-game host: load a save, invite, play. Configure mods in both the Steam Workshop section and the Mods section — half-configured is the standard host failure | One remote player joins a clean, zero-mod default session and moves without errors |
| The world should stay up when nobody's playing | Run a dedicated server: SteamCMD app_update 380870, UDP 16261 and 16262 open, and the profile files (server settings, sandbox vars, spawn files) under your control | The process survives the host logging off, and a remote player joins hours later |
| Nobody wants to maintain the machine | Pay a managed host, and confirm three things in writing before the first night: the build version they run, the backup schedule, and mod support | The provider answers all three, and the first join works without a support ticket |
| The group wants a modded campaign | Prove the method clean first: clean session, clean join, then add mods with a dated backup taken before every change | A clean join still works after the mods go in — if it breaks, you bisect the set instead of rebuilding the world |
What each model actually operates
The captured multiplayer reference distinguishes an in-game host, a dedicated server, and a managed host as different administration and availability models. Here is what you're signing up to operate in each.
| Model | You operate | The recorded gotcha |
|---|---|---|
| In-game host | The session, the save on your machine, your schedule as uptime | Hosted-server mods are configured through both the Steam Workshop and Mods sections (per a captured 2022 Steam discussion that still matches the current field split) — half-configured is the standard host failure |
| Dedicated server | The process, the profile files (servertest.ini, SandboxVars, spawn files), the ports (UDP 16261/16262 by default), the backups | Everything in the dedicated-server record is yours to verify — the PZwiki anchors are 42.20.0-marked and warn 42.21 may differ |
| Managed host | The rules and the player list; the provider runs the machine | Confirm before paying: which build the provider runs, where backups live, and whether WorkshopItems/Mods fields are editable — a provider that hides the mod fields has quietly decided your mod policy for you |
The first-hour sequence, whatever you picked
Every hosting guide converges on the same first hour, because the failure modes all look identical until a clean join exists.
Launch the default configuration — no mods, no settings edits — and get one remote player in. This single test separates the three failure families that otherwise blur together: network problems (ports, firewall, the provider's routing), version problems (branch and build mismatches on either side), and configuration problems (mods, settings, profiles). Until a clean join exists, you cannot tell which family you're in, and every change you make is a guess that muddies the next test.
Only after the clean join: back up the working configuration — the save, the profile files, and a written list of every mod ID — because that backup is your rollback point for the entire campaign. Then add mods in small reversible batches, with the both-fields rule (Workshop AND Mods) applied per item, and one client rejoining after each batch. The dedicated-server record adds the file inventory to capture: servertest.ini, the SandboxVars file, the two spawn files, and the world under Zomboid/Saves/Multiplayer.
The host's ongoing job is bookkeeping, not heroics: a dated change log (what, when, why), dated backups whose restore has actually been tested once, and the version baseline noted on day one — the exact server build, so a client mismatch months later has something to compare against. A host with notes is a boring host, and boring is what a campaign server should be.
Reference data
Choose the host model first — the configuration surface and the failure path depend on that choice.
| Host model | Best for | Prove it with |
|---|---|---|
| In-game host | A small group sharing the host's schedule | One remote player joins a clean session |
| Dedicated server | A world that stays up without the host in-game | Process, profile, and remote join result |
| Managed host | Players who don't want to maintain the machine | Provider build, backup, and mod controls |
| Modded session | Optional complexity, added after a clean join | Workshop and Mods lists recorded separately |
FAQ
In-game host or dedicated server — which should I use?
In-game host for two to four players on one person's schedule (fastest setup, but the world lives and dies with that session); dedicated when the world should stay up unattended (SteamCMD app_update 380870, UDP 16261/16262 by default, profile files under Zomboid/Server); managed host when nobody wants to maintain the machine. All three: prove a clean join with zero mods before configuring anything.
How do I add mods to a hosted server?
Through both sections, not one: a captured Steam discussion recommends adding hosted-server mods through both the Steam Workshop and the Mods settings, which matches the current WorkshopItems=/Mods= field split. Half-configured is the standard host failure — a mod that's subscribed but never activates.
What should I set up in the first hour of hosting?
One sequence: default configuration with zero mods, one remote player joins clean, back up the working state (save + profile files + written mod list), then mods in small batches with one client rejoining after each. Until the clean join exists, network, version, and configuration failures all look identical — and every premature change muddies the next test.
What does a managed host provider actually handle?
The machine: process uptime, hardware, and usually backups. You still own the rules and the player list — and before paying, confirm which build the provider runs, where backups live, whether the restore path has been tested, and whether the WorkshopItems and Mods fields are editable. A provider that hides the mod fields has quietly decided your mod policy for you.