Multiplayer setup: hosting, shared mechanics and co-op layout

Three ways to reach a shared save

Factorio offers three practical paths into the same world, and they differ in who controls uptime, who sits behind the network address, and how much administrative work the session costs. Treating them as interchangeable is where most first-night multiplayer problems start.

Hosting a dedicated server

A dedicated server runs the simulation as a process with no player attached. The host does not need to be in the game for others to play, which makes this the model for a world that should stay reachable across time zones or irregular schedules. The tradeoff is that someone owns that process: the save file lives on one machine, that machine needs to stay running, and reaching it from outside a local network usually requires either port forwarding or a tunnel. That ownership is a feature for a long-running community world and a burden for a group that just wants an evening session.

The other side of the tradeoff is determinism. Factorio's multiplayer is lockstep: every connected client must compute the same simulation, and a mismatch in mods or game version prevents joining rather than producing a quietly divergent world. A dedicated server pins those variables in one place, which removes a class of connection support that otherwise lives with whichever player happened to click Host first.

Joining through matchmaking

Matchmaking hands the address-brokering problem to a relay: players browse public or unlisted games and connect without anyone configuring a port. This costs nothing in setup time and is the right default for ad-hoc groups, play-with-strangers lobbies, and anyone whose router they do not control. The cost is reliance on a third-party directory and, for some network topologies, a relay path that can add latency compared to a direct connection.

Matchmaking also shifts the social contract. A dedicated server tends to belong to a defined group with shared expectations about building and grief; a public lobby admits anyone who can click Join, and the host carries moderation responsibility in real time. The simulation is the same, but the administrative overhead is concentrated in the moment rather than spread across setup.

Playing over LAN

A LAN game is the lowest-friction option when every player is on the same network, such as a physical meetup or a household. Discovery is automatic, latency stays within the local network, and no internet path is involved. The limitation is structural: it only works while that shared network exists, so a LAN world does not travel home with a player the way a dedicated server does. It is well suited to a concentrated build session and poorly suited to a persistent world.

Model	Who runs the sim	Network setup	Best fit
Dedicated server	A host process, no player needed	Port forwarding or tunnel	Persistent community world
Matchmaking	A player machine or a relayed host	None; directory handles it	Ad-hoc and public lobbies
LAN	A player on the local network	Automatic discovery	Same-room sessions

The choice tends to track how long the world is expected to live. A one-night build rarely justifies a dedicated process; a world that a group returns to over weeks usually does, because the save continuity matters more than the setup cost of a single evening.

What is shared and what stays personal

Multiplayer changes which parts of the game state belong to the force and which belong to the individual player. Getting this distinction wrong leads to confused arguments about who "lost" the science or why a factory stopped when someone logged off.

Research is a single pool

All players on the same force contribute to, and draw from, one technology tree. When one player launches research, every player benefits from the unlock; the labs and the science packs are shared infrastructure. This makes research a natural early-game coordination point: a group that splits up to hand-feed separate research queues is duplicating work the game already pools. The flip side is that technology choices are collective, so a player who silently queues a long side-grade tech is spending shared science on a decision the rest of the force may not have agreed to.

Build reach belongs to each engineer

The area in which a player can place or remove entities is personal, not shared. Two players standing side by side each have their own reach radius, and one player's reach does not extend the other's. The exact tile radius for the engineer character is NOT FOUND in the 2.1 data extract used by this site (the character prototype is not present in machines.json), so no figure is quoted here rather than an estimated one.

The practical consequence is that a structure one player can service may be out of reach for another standing a few tiles away, and a ghost placed beyond a player's reach waits until that player moves or a construction robot covers it. This is a small fact on its own, but it reshapes layout: co-op bases need either overlapping personal reach or robot coverage where multiple people work the same block.

Inventory, hand crafting and position

Each engineer carries a separate inventory, crafts independently in a personal crafting queue, and occupies a separate position on the map. Chests, machines and their contents belong to the force and are accessible to anyone on it, but items in a player's pockets travel with that player. A common co-op ritual is the donation chest near spawn where players dump surplus intermediates, because otherwise the iron gears one person hoarded are invisible to the person who needs them two screens away.

Vehicles and trains are force-owned, not player-owned. Any player can board an unoccupied car or train, which is convenient for sharing transit and a source of accidental stranding when someone drives the only fuel truck to an outpost and logs off there.

Why a co-op base needs wider channels than a solo one

A solo player tolerates tight gaps because there is only one cursor and one body moving through the factory. In co-op, two engineers can arrive at the same junction from opposite directions, one may be placing belts while the other is rerouting pipes underneath, and a third may be driving a train through a crossing that looked spacious on a single screen. The cost of a cramped layout is paid in collisions and rework rather than in any game statistic.

Wider gaps serve three purposes. They give two players room to work adjacent segments without standing on the same tiles, they leave space to thread a second belt or pipe when the first design proves insufficient, and they keep a clear pedestrian route that does not cross active rail. A main bus designed for one player can use a single tile of clearance between component blocks; in a shared base that same clearance becomes a queue when two people try to traverse it at once.

This is not a call for wasteful spacing everywhere. The high-traffic spine of the factory — the bus, the smelting columns, the rail junctions — is where extra tiles pay off. Peripheral outposts that one player tends for an hour and leaves can stay compact. The rule of thumb is to widen what many people touch and leave what one person owns alone.

Dividing labor in a shared factory

A co-op factory tends to outperform a solo one not because the game runs faster with more players but because specialization becomes possible. A solo engineer context-switches between mining, smelting, oil, trains and defense; a group can assign each of those to a person who holds the whole system in their head at once. The layouts that support this well are the ones that treat each subsystem as a module with a defined input and output, so the person running oil does not need to understand the exact belt arrangement inside the green circuit block.

Roles that emerge in practice

Early in a shared game, a natural split is resource front versus factory interior: one player expands mining and feeds the bus while another organizes the bus itself and the science it supplies. Once oil appears, fluids tend to want an owner, because a cracked-priority mistake can stall plastic and red science for everyone. Later, rail and outpost construction is a role of its own, and defense of the growing perimeter often falls to whoever is most comfortable reading a map rather than a belt line.

These roles are not classes and the game imposes no restrictions on who can do what. They are coordination habits, and the groups that fare well treat them as fluid: the rail designer still places belts, and the oil specialist can relieve the defense player during a large attack. What hurts a shared factory is not role overlap but role collision, where two players independently rebuild the same junction on conflicting assumptions.

The main bus as a contract

A documented main bus — known lanes, known tap points, a consistent side for inputs — functions as an interface between players. The person expanding iron production only needs to know which lane carries iron plates and where to add it; the person building circuits only needs to know where to tap. When that contract is implicit, two players improve the bus in incompatible directions and spend an evening untangling it. When it is explicit, even a short spoken agreement on lane order lets work proceed in parallel without negotiation.

City-block and gridded layouts amplify this effect: each block has a standard footprint and standardized rail or belt access, so a player can claim an empty block and build inside it without disturbing anyone else. The cost is the upfront planning of the grid itself, which is why grid bases are common in persistent multiplayer and rarer in one-night sessions.

Construction robots in a shared build

Personal construction robots extend a single player's reach, but a network of roboports extends the force's reach across a defined area. In a co-op base that network becomes shared infrastructure: ghosts any player places can be fulfilled by robots any player supplied, and repairs after an attack happen without assigning someone to run the perimeter.

The 2.1 machine data puts a roboport construction radius at 55 tiles and its logistics radius at 25 tiles, with 7 robot slots and 500 health. A construction robot in that data moves at speed 0.06, carries a payload of 1 item per trip, and has 100 health. These figures describe one roboport and one robot; a network tiles its coverage by placing adjacent roboports so their construction areas overlap.

Attribute	Value	Why it matters in co-op
Roboport construction radius	55	Sets the area where ghosts any player placed get built
Roboport logistics radius	25	Smaller than construction; defines logistic-robot range
Roboport robot slots	7	How many robots can charge at this port at once
Construction robot speed	0.06	How quickly a queued ghost becomes a built entity
Construction robot payload	1	One item per trip; large builds need many trips

The gap between the two radii is worth understanding. Construction coverage extends farther than logistics coverage, which means robots can build ghosts in a ring where logistic requests are not yet serviced. In a shared base this shows up as builds completing at the edge of the network while chest requests there stall, and the fix is usually another roboport placed to extend the logistics inner circle rather than the construction outer one.

Robot charging is the other shared bottleneck. Every robot returning from a build or delivery needs a charging pad at a roboport, and a burst of construction — a player pasting a large ghost blueprint over an empty block — can queue robots waiting for a free pad. With 7 slots per roboport, a network designed for steady repair traffic may hiccup under a mass-build event; spreading roboports through the build area rather than clustering them at the centre shortens the queue.

Forces, teams and player-versus-player

Factorio groups players into forces. A force owns its entities, research and vision; players on the same force share all three, while players on different forces do not. Co-op play places everyone on one force. Competitive scenarios place players on separate forces, which makes entities hostile across force lines and lets each side research independently.

The force system is more flexible than a simple team switch. A scenario can grant shared vision without shared control, or set ceasefires so two forces do not fire on each other while still keeping separate research. These are scenario-level configurations rather than something a player toggles from the lobby, and they are the mechanism behind co-op-vs-biters team games, PvP arena saves, and mixed cooperative-competitive scenarios.

For a standard co-op group the force detail stays invisible, but it explains one multiplayer behavior worth knowing: a player who joins on the correct force sees the whole explored map, because chart information is shared per force. A player placed on the wrong force sees fog of war over a base the rest of the group has already mapped, which is a configuration mistake rather than a bug.

Saving, continuity and desync

Because the simulation is lockstep, a desync — where a client computes a different state from the host — is detected and the client drops, rather than producing two divergent worlds that later need reconciling. The usual causes are mod or version mismatches, which is why the server enforces them on join. Keeping every client on the same mod set and game version is a habit that prevents most connection failures, and a dedicated server makes that easy by pinning both in one place.

Autosave behavior is worth agreeing on in a long-running world. The save file is authoritative on the host; a client disconnecting does not lose progress, but a host that crashes without a recent autosave can roll the whole force back. Naming a backup routine and, for a community world, taking occasional off-host copies protects against a single machine failure. None of this is specific to Factorio simulation, but multiplayer concentrates the cost: one lost save rolls back everyone's evening, not one player's.

Pausing behaves differently in a shared session. A single-player world freezes when the player opens the menu; a multiplayer world keeps running while players are connected, because the simulation belongs to the force and biters do not wait for a menu. A player who steps away mid-fight leaves an engineer standing in the world, which is why parking somewhere defensible or logging off cleanly matters more than it does alone.

Communication and the cost of silence

The scarcest resource in a co-op factory is not iron or oil but shared intent. A player who quietly reroutes a belt to fix a local shortage may be starving a science block another player is debugging two screens away, and neither sees the other's action until something stops. Voice chat is the common fix for fast-moving sessions; for slower or asynchronous play, in-game signs, a consistent naming convention for train stops, and a written lane order on the bus carry the same information without requiring everyone to be online at once.

Signs are easy to dismiss as cosmetic, but they are a cheap coordination tool in the game. A label on a chest, a stop name that says what it delivers and where, and a marker at an outpost noting what it produces let a player understand a subsystem without interrupting whoever built it. In a persistent world where people log in at different times, that written context is what keeps the factory running when the original builder is offline.

Mods and the join handshake

In a modded multiplayer game, every client runs the same mod set, and the server checks that set during the join handshake. A player who is missing a mod, running a different version of one, or has an extra mod the server does not know about is refused at connect time rather than allowed in and then desyncing. This is the same determinism guarantee as the version check, extended to mods: the simulation has to be bit-identical across every machine, and mods change the simulation.

The practical outcome is that mod management is a shared responsibility, not an individual one. A group that coordinates mods informally ends up with one player unable to join on the night someone else updated a library. Persistent groups tend to pin a mod list, update it together on an agreed schedule, and treat a mid-save mod change as a planned event rather than an impulse — because adding or removing a mod can alter recipes, entities or world generation on a save that already exists, and that migration is less risky when everyone expects it.

Total-conversion mods and overhaul mods reshape which parts of this page still apply. The force, research and reach mechanics are engine features and survive most mods, but the build priorities, tech tree and even the meaning of a "main bus" can change. The layout principle of wider shared channels and documented interfaces carries over; the specific roboport figures on this page do not, once a mod rebalances robots.

Performance, ups and where a large base hurts

Multiplayer does not multiply the simulation cost by the number of players. The factory updates once per tick regardless of how many cursors are attached; an extra engineer adds a small amount of network and player-state overhead but does not double the update time of a thousand assemblers. What multiplayer changes is how quickly a base grows, and growth is what eventually costs update time. A group of four players expands production, rail and outposts faster than one player, and reaches the scale where fluids, belts and enemies take measurable milliseconds per tick sooner.

The host or dedicated server bears the update cost; clients run their own prediction and receive the corrected state. A client on slower hardware still sees a smooth game as long as the host keeps up, but a host that cannot hold sixty ticks per second slows the whole session because the simulation is shared. This is the strongest practical argument for a dedicated server on capable hardware for a large persistent world: it separates the machine running the sim from whichever player happens to be hosting, and it can be sized for the factory rather than for one player's desktop.

The update-time hotspots in a co-op megabase are the same ones as in a solo one, reached earlier: dense fluid systems, very large belts of moving items, expansive biter pathfinding across a heavily polluted map, and power networks spanning thousands of machines. Building with an awareness of those costs — preferring trains over long belt runs at scale, containing pollution where biters gather, segmenting power networks — pays off sooner in a group because the group reaches that scale faster. No specific tick or millisecond figure is quoted here; update performance depends on the save, the hardware and the mod set, and a single number would mislead more than it helps.

Applies when…

• Roboport and construction-robot figures are read from the 2.1.12 machine data. They describe the base-game entities; mods that alter robot speed, roboport radius or slot counts change these numbers.
• The player character build reach is NOT FOUND in the 2.1 data extract and is deliberately not estimated here. A reader needing the exact tile radius should consult the live character prototype.
• No multiplayer runtime parameters — tick rate, bandwidth, player limits — are quoted because they are not present in the data extract this site uses. Their values depend on configuration and build, and are not asserted.
• The hosting tradeoffs describe the three standard connection models. Third-party tunneling services and containerised hosts are variants of the dedicated-server model, not a fourth category.
• Shared-mechanics descriptions assume all co-op players are on the same force. PvP and scenario saves use multiple forces and change what is shared.
• Layout guidance is directional rather than a recipe: wider channels help where multiple players work, and the exact tile gap is a per-base decision, not a prescribed constant.

Related

• Defending your base — perimeter defense becomes a shared role once several players expand in different directions
• Combat units — how biters and other units scale and behave on a map that multiple engineers are expanding
• Production Ratio Calculator — size a shared factory block before two players start building it in parallel