Factorio Logistics Guide | Belt vs Train vs Robot - When to Use Each

In Factorio, picking your logistics method based on distance and throughput rather than personal preference leads to much more stable factories. Belts handle short-range high-volume transport within your factory, trains own long-distance bulk hauling between outposts, and logistics robots shine at low-volume multi-item delivery across obstacles.

I've run 100-station train networks where adding robots just at station unloading made everything dramatically easier, while carelessly stretching long-distance belts cost me full rebuilds more times than I'd like to admit. That distinction matters more than you'd think.

This article uses vanilla v2.0 as the baseline and evaluates logistics choices across five axes: distance, throughput, scalability, power/UPS impact, and design complexity. The goal is to give you a practical decision framework that separates trunk logistics from auxiliary logistics, helping you avoid the most common selection mistakes.

Factorio Has Three Logistics Methods

Trunk vs Auxiliary Logistics

Factorio's logistics break down into three methods: Transport belt, trains, and logistics robots. A practical way to think about their roles is to separate trunk logistics (the factory's backbone) from auxiliary logistics (fine-tuning and last-mile delivery).

Trunk logistics handles items that flow in high volume and would cripple the entire factory if they stopped -- ore, plates, circuits. For in-factory transport, Transport belts take the lead. For inter-base and remote resource delivery, trains are your workhorse. Belts have the advantage of making flow visually trackable, so bottlenecks and shortages are easy to spot. Throughput benchmarks: yellow belts move 15 items/sec, red belts 30 items/sec, blue belts 45 items/sec. These numbers form the basis for designing in-factory steady-state transport. Belts also pair naturally with the main bus layout (running key materials in parallel trunk lines), making them approachable from early to mid-game expansion.

Trains, meanwhile, prove their worth at distances where routing belts hundreds of tiles becomes painful. Cargo wagons are treated in community practice as long-distance bulk haulers, and viewing trains as your "logistics highway" stabilizes your overall design.

Logistics robots occupy a different niche. Since robots fly over obstacles and take the shortest path, they work best as auxiliary logistics that handle edge cases rather than serving as the main artery. Station unloading assistance, mall restocking, multi-pack research lab supply, and construction material delivery across walls are all prime robot territory. The Factorio Wiki's logistics network page categorizes robots as less fuel-efficient than belts or trains but far more flexible.

The setup that gave me the most stability at scale was trains as the trunk, belts for steady in-factory lines, and robots only for the last-mile gaps. Once I adopted that structure, I stopped having to tear up trunk lines every time I reorganized a section. Early on, the temptation was "robots are convenient, just use them for everything," but putting robots on trunk duty made bottlenecks much harder to diagnose. Conversely, forcing belts onto every last detail meant even minor material additions triggered full line reworks. Rather than pitting the three methods against each other, layering their responsibilities produces the most Factorio-like growth.

Belt transport system/ja

wiki.factorio.com

Target Version and Terminology

The baseline here is vanilla v2.0. The focus is on building standard factories on Nauvis. Space Age introduces planetary logistics and space platforms as additional layers, but those sit on top of "how to use the three ground logistics methods" rather than replacing them. Since robots aren't always available in space scenarios, even with the DLC, establishing your belt/train/robot roles on the ground first provides the foundation.

A quick terminology alignment. UPS stands for Updates Per Second -- how many game ticks the engine processes each second. In large factories, whether this value stays stable directly affects your perceived game speed. When comparing logistics methods as "UPS-friendly" or "heavy," that's referring to processing load.

A logistics network is the delivery zone formed when Roboports connect to each other. Each Roboport has 4 simultaneous charging slots, and when demand exceeds charging capacity, robots start queuing up nearby. Robots aren't a "just add more" solution -- you need to design around charging point density as well. That's the quirk that distinguishes robot logistics from belts and trains.

The main bus runs key materials like iron plates, copper plates, and circuits on multiple parallel belts, with production lines branching off to draw what they need. In practice, grouping 4 belts together with 2-tile gaps between groups works well. The layout looks simple, but the ability to see "what's being drawn from where" keeps it relevant well past the beginner stage into mid-scale factories.

Adding a Space Age perspective briefly: planetary and space logistics represent new layers being added, not the ground-level belt/train/robot roles disappearing. If anything, weak trunk logistics on the ground makes everything collapse faster when you layer space logistics on top. That's why this section deliberately locks down the three ground categories first.

The Five Decision Axes

Choosing a logistics method works best when you cut across five axes rather than going with gut feel. I run through these five every time I start a new factory.

First up is distance. Short-range and in-factory transport defaults to belts. The longer the distance, the stronger the case for trains. Robots are convenient at short to medium range but tend to fall apart as trunk logistics over long distances. They can fly anywhere, sure, but "can fly far" and "suited for long distances" are different things.

Next is throughput. Resources that flow constantly in high volume -- ore, plates, circuits -- belong on belts or trains. Belts give you predictable per-second throughput, and trains batch large volumes efficiently. Robots handle low-volume multi-item delivery well but aren't built to endlessly shuttle a single resource at high flow rates.

Third is scalability. If you plan to expand production lines later, how much of the trunk you can preserve matters. Belts are intuitive but become painful to reroute over long distances. Trains scale nicely with additional stations and tracks, pairing well with modular base designs. Robots handle layout changes gracefully, but scaling the entire network too large makes localized problems harder to spot.

Fourth is power and UPS. Belts don't consume power for transport itself, so your line structure stays visible even during blackouts. Robots sit at the opposite end -- heavily power-dependent, with charging waits and processing load increasing alongside robot count and flight distance. Trains involve design complexity with signals and stations, but consolidating long-distance bulk transport into a single line often proves easier to manage than running endless belts. If you're thinking about UPS at scale, "everything on robots because it's convenient" leans toward dangerous territory.

Fifth is design complexity and visibility. Belts show you the flow at a glance, making problem spots easy to find even for beginners. Trains have a learning curve around signals and station design, but once understood, they're powerful at scale. Robots are easy to place but can mislead you about where charging congestion is happening or which items are short. In other words, easy to deploy and easy to operate are different things.

Mapping these five axes, belts land at "short distance, steady high volume, high visibility," trains at "long distance, high volume, high scalability," and robots at "short to medium distance, low-volume multi-item, high flexibility." Keeping these positions in mind prevents confusion when you later dive into signal design or station layouts, because "why this logistics method" stays anchored.

The Bottom Line: Choose by Distance, Volume, and Flexibility

If you want the conclusion up front: short-range high-volume goes to belts, long-range high-volume goes to trains, low-volume multi-item and obstacle-crossing goes to logistics robots. Anchoring on this eliminates most logistics indecision.

I used to leave this boundary fuzzy early on, reaching for "whatever's easiest right now," and it always came back as rework costs. The worst case was when I'd stretched red and blue belts across multiple screens to a petroleum area -- converting that to a single train line cleaned up both routing and construction scope dramatically. Felt like cutting the build time in half. These transition decisions land better when driven by criteria rather than instinct.

Three-Method Comparison Table

A quick side-by-side makes it easier to internalize, so here are the key comparison points:

The key takeaway from this table is that each method has a different strong axis. Belts are "visible, stable, strong inside the factory." Trains are "move bulk over long distances." Robots are "handle awkward terrain and varied items." Keep that mental model and selection gets straightforward.

Compressed across the five axes, decisions roughly follow this pattern: short distance leans belt, long distance leans train. Low volume with many item types leans robot. Frequent layout changes where belts can't route cleanly favor robots. Conversely, assigning trunk materials to robots will eventually bite through charging waits and network bloat. Each Roboport only charges 4 robots simultaneously, so visual smoothness hits a wall at charging capacity sooner than you'd expect. This behavior is core to robot operations as described on the Factorio Wiki's logistics network page.

Logistic network/ja

wiki.factorio.com

Decision Flowchart

In practice, starting from distance eliminates most ambiguity. I run through this sequence mentally every time I build new transport.

1. Is the distance short or long?

In-factory or adjacent-block transport defaults to belts. Inter-base, remote ore patches, petroleum fields -- anywhere "stretching belts gets painful" -- puts trains as the primary candidate. Robots don't become the front-runner here; they sit in reserve for short-to-medium range special transport.

1. Is the required volume high or low?

High-volume steady flows of ore, plates, and intermediates belong on belts or trains. Low volume with many item types where delivery targets are scattered favors robots. Feeding multiple science packs to labs or restocking a mall with building materials are textbook examples.

1. Are there layout constraints?

Cliffs, lakes, existing production lines, defense perimeters, tight factory corridors -- if belt routing gets ugly, robot value jumps sharply. Flying over obstacles to deliver via the shortest path is their defining strength. Trains also work if you can carve out rail space, but for fine-grained maneuvering, robots win handily.

1. Is there power and UPS headroom?

Robots are convenient, but "just add more robots" doesn't scale. Larger networks mean more charging waits and longer flight distances. At stages where power is unstable or processing load is already a concern, keeping robots off trunk duty produces better stability. Avoiding overcommitment here prevents factory-wide overhauls later.

1. How much design complexity are you comfortable with?

Want something working immediately with visible flow? Belts. Want clean long-distance organization? Trains. Want minimal-footprint fine adjustments? Robots. Trains have a learning curve, but for long-distance bulk transport, the investment pays back quickly.

Following this flow, the principle stays simple: short-range high-volume = belts, long-range high-volume = trains, low-volume multi-item obstacle-crossing = logistics robots. Layering "trunk vs auxiliary" on top of that is the only additional consideration needed for practical operation.

Exceptions: Station-Front Robots, Malls, Lab Supply

The general rules are simple, but there are specific exceptions where robots excel. Knowing these gives you the nuanced "robots aren't weak, and they aren't all-powerful" understanding.

First is station-front robot unloading. Run the long-distance trunk on trains, then hand off to robots for the short station-to-factory-entrance delivery. This captures both trains' long-haul efficiency and robots' handling flexibility. I use this in every large outpost. Robots struggle on trunk routes but thrive in station-limited zones. Their strengths show most cleanly here.

Second is mall restocking. Building materials and maintenance supplies have inconsistent demand across many item types, so routing everything with belts gets cramped fast. Running main materials on belts while delegating small parts and finished-product restocking to robots opens up design freedom. Malls aren't "high-throughput production lines" -- they're "stockpiles for a wide variety of items," which naturally suits robots.

Third is multi-pack research lab supply. As science pack types increase, belt branching gets complicated. Straight-line belt setups are powerful, but during phases where lab placement changes frequently, robot delivery speeds up reconfiguration. Especially if you plan to expand the research area later, running a separate trunk to the area and using robots only for the final lab delivery produces a clean result.

Beyond these, construction material delivery across walls and renovation scenarios where you don't want to demolish existing factory sections also benefit from robots. The pattern is clear: robots work best as a tool for solving constraints, not distance. Using them to fill gaps that belts and trains can't cleanly handle prevents unnecessary network expansion.

One important reminder: robots don't become more capable as you expand the network. Sparse Roboport placement leads to more charging waits than flight delays. Growing by increasing coverage area rather than charging density is a trap. Station-front robots, mall restocking, and lab supply all work precisely because the scope is narrow and the role is well-defined.

When to Use Transport Belts

Hard Numbers and Throughput Benchmarks

Belts are the right choice primarily for short to medium range, when you need to continuously move the same item in high volume. The numbers make the case clearly: per the Factorio Wiki's Transport belt page, yellow belts carry 15 items/sec, red belts 30 items/sec, and blue belts 45 items/sec. Having these fixed throughput values makes it easy to estimate "how many belt lanes does this material need."

Belts also let you track flow visually. Jams, backflows, lane imbalances, and supply shortages are all visible, making root cause identification accessible even for beginners. Belts don't need power to operate, so they're stable from the earliest stages. Their combination of visibility and accessibility is why they work so well as the factory's structural logistics.

For smelting, the numbers translate directly. To fully saturate one yellow belt with iron plates, you need 48 stone furnaces or 24 steel furnaces. Once I memorized those figures, smelting array design became dramatically easier. Build at yellow-belt scale, upgrade to red when demand grows, then blue -- that staged progression keeps designs stable.

On the UPS front, belt-centric factories tend to be relatively predictable and stable. However, piling on excessive splitters and balancers on high-density belt networks adds computation overhead. Belts are light when used simply, but complex distribution mechanisms introduce their own weight. Keeping that awareness helps with design decisions.

Best Uses: Main Bus, Smelting Arrays, In-Line Transport

Belts' sweet spots are clear, especially main bus layouts, smelting arrays, and same-module in-line transport. All three share common traits: "the item being moved is mostly fixed," "throughput is steady," and "you want to maintain visible routing."

In a main bus, multiple materials flow in parallel over long stretches, with branch-offs at each production area. Belts excel here because you can see at a glance what's flowing where, making whole-factory comprehension easier. The established pattern of 4 belts per group with 2-tile gaps between groups creates natural spacing for adding underground belts and splitters later, making expansion much smoother.

That "2-tile gap" looked excessive to me at first. But after starting with a skinny 2-belt yellow bus and upgrading through red to blue, I became deeply grateful for it. Without gaps, upgrading the belts themselves is easy, but relocating adjacent infrastructure is painful. Starting with a little breathing room means additions and bypasses slot in naturally, avoiding total teardowns.

Smelting arrays are equally belt-friendly. Feed ore in, run plates out sideways -- supply and deficit are both visually obvious. The fixed furnace-count targets make yellow-belt-scale arrays easy to replicate horizontally. Receiving ore via train and running belt-based smelting from the station onward is a clean configuration precisely because belts are "easy to design around fixed throughput."

For in-line transport within the same module, belts handle local high-volume shuttling well. Moving gears, circuits, and plates at steady rates between adjacent assemblers is where robots would be overkill and trains would be over-engineered. Materials flow alongside the assembler row, making surpluses and deficits immediately visible. The factory's "wiring diagram" literally becomes the logistics.

Limits and Common Mistakes: Long-Distance Overuse, Modification Cost

That said, belts aren't meant to stretch indefinitely. Management cost spikes the moment you go long-distance. Running multiple belt lines to distant ore patches, routing around lakes and cliffs, crossing through defense perimeters and existing factory blocks -- in these scenarios, ongoing maintenance and modification quickly outweigh the initial build effort.

I've done the "just belt it over, it'll be faster" thing with distant ore. The result was always the same: the moment I wanted to add capacity, everything fell apart. Adding one more belt lane triggers underground belt swaps, crossing reworks, and defense infrastructure conflicts all at once. The modification is worse than the original construction. Committing to long-distance belt infrastructure makes the eventual transition to trains a major construction project.

Modification weight compounds this. The more complete a belt layout is, the wider the ripple effect of any change. Upgrading to blue is mechanically simple, but when branch points, balancers, smelting outputs, and assembly line inputs are all interconnected, you end up touching a much larger area than intended. This is exactly why building in some breathing room from the start pays dividends.

UPS considerations apply here too. Belts themselves are stable, but long trunk lines loaded with heavy splitter chains, complex balancers, and dense branching accumulate processing sources. Belts are light when used simply -- that nuance better matches the actual experience. As factories grow, belts' advantage lies in "visibility" and "simplicity."

So belts dominate short-to-medium range trunk and in-factory transport, but overloading them with long distances and terrain crossings creates pain quickly. Route remote resources to trains, delegate fine-grained last-mile delivery to robots, and let belts focus on flowing thick and stable inside the factory. That's where they perform at their best.

When to Use Trains

When to Introduce Trains and Scaling Mindset

In one sentence, trains' value is remote resources and high-capacity trunk lines. Belts handle short-range in-factory routing more naturally, but once ore patches deplete and mining outposts push further out, trains' advantages become immediately apparent. For long-distance ore delivery and serving as the backbone connecting distant outposts, trains have more growth potential than any alternative.

For beginners: you don't need to force trains into a starring role from the start. Honestly, I jammed things up plenty of times early on thinking "just lay track and you're done." Trains are powerful, but that power activates "when introduced at the right time for the right reason." If your factory still operates within a compact area, sticking with belts is faster and clearer. The signal to switch is when you find yourself running multiple belt lines to distant iron or copper patches -- that's your cue.

The scaling mindset differs from belts too. Rather than comparing trains in raw items-per-second, it's more practical to work backward from your target SPM to determine consist size and station count. Actual throughput varies heavily based on consist length, loading/unloading setup, and dwell time. So instead of pinning down "this train carries X items/sec," start from "how much of what do I need at this outpost" and adjust route count and consist size from there.

Processing before transport also creates interesting decision points. For iron-line items, shipping steel instead of raw iron plates can yield better cargo efficiency. Over long distances, "where do you process?" directly shapes your rail network's load. Whether you smelt at the mining site or centralize raw ore -- that choice changes trunk rail demand. Rather than memorizing numbers, thinking about which cargo maximizes value per wagon guides route design decisions.

Station Design and Signaling Basics

Once you commit to trains, the real challenge isn't the tracks themselves -- it's station design and signaling. Without these, trains become "things that occasionally freeze everything" rather than "convenient long-distance haulers." Complexity notably steps up from belts once you introduce double tracks, intersections, and stacker lanes.

Regular rail signals divide track into blocks, allowing one train per block. Chain signals only permit entry when the exit is clear. In practice, the widely cited "chain signal at entries, rail signal at exits" pattern is remarkably effective, dramatically reducing intersection deadlock. Before I understood this, I repeatedly had trains halt in intersection centers and block entire networks. Trains cause bigger problems when they stop in the wrong place than when they're running.

Around stations, failing to provide waiting areas means congestion ripples back to intersections. When mining or smelting stations get busy, trains queue on the mainline, blocking intersections and triggering cascading jams. Building stackers outside the mainline to absorb waiting trains solves this. At 100-station scale, this was the single most impactful improvement I made. Stackers plus a prioritized mainline structure transformed the entire network's congestion profile. Train problems most often resolve by keeping waiting trains off the mainline.

For systematic signal design, refer to the official Wiki and community signal guides (chain signal usage in particular draws heavily from community practice, so multiple implementation examples exist). The priority isn't memorizing complex intersections but internalizing two fundamentals: never create blocks shorter than your train length and never let trains stop inside intersections.

Core Uses: Remote Ore, Inter-Module Transport, Station-Front Robot Combo

Trains shine brightest at remote ore delivery. As iron, copper, coal, and stone mining sites push outward, a single train trunk line beats running multiple belt lanes every time. When a patch depletes, you just add a new mining station pointing at the same receiving station -- easy life extension. Rebuilding long-distance belts every time mining locations shift becomes increasingly painful in the late game.

Next strongest is inter-module intermediate transport. If you've divided your large factory into smelting, circuit, and science pack zones, connecting them by train makes expansion natural and early stability easier to achieve. Modular factories allow adding production blocks as separate installations, but weak trunk logistics between them creates immediate bottlenecks. Train connections enable a "just add the needed production block off to the side" mindset. Belts inside the factory, trains between factories -- that role division fits cleanly.

In practice, station-front robot unloading stands out as exceptionally effective. Trains handle the bulk long-distance delivery; robots distribute from the station to nearby facilities. With Roboports charging 4 robots simultaneously, the short station-adjacent range keeps things controllable and highly practical. Trying to robot-deliver far beyond the station, though, quickly reveals charging wait degradation. In my experience, trains and robots don't compete -- they're collaborators. Long-distance trunk on trains, last-mile handling on robots makes loading/unloading design dramatically easier.

For related operational and design details, the official Wiki's train and signal pages plus community guides offer practical examples. Start by prioritizing "don't create blocks shorter than your train" and "don't stop trains inside intersections."

When to Use Logistics Robots

Best Uses and Examples: Mall / Player Supply / Labs / Station-Front

Logistics robots are, frankly, fuel-inefficient. The tradeoff is flight paths unconstrained by wiring or belt routing, passing freely over obstacles and building layouts. So their starring role isn't steady-state high-volume transport like belts, but rather short-to-medium range delivery of low-volume multi-item cargo to wherever it's needed. Miss this distinction and slowdown hits before convenience does.

The clearest example is mall restocking. Rather than neatly belting every building material, routing gears, circuit boards, iron plates, inserters, and assembler components through logistic chests in the needed quantities adapts better to factory changes. I end up running malls mostly on robots, not for efficiency but because they follow factory modifications easily. Swapping recipes doesn't require rerouting, lowering the psychological barrier to adjusting your building material lines.

Player supply is another robot sweet spot. Belts and trains can't easily top off your personal inventory, but within a logistics network, ammo, walls, belts, power poles, and module materials flow naturally. When repairing defense lines or expanding stations, needing many different items in small quantities is exactly where robot strength becomes obvious.

Research lab multi-pack supply is also a natural fit. Research consumes multiple science pack types simultaneously, and while elegant belt setups exist, having robots handle distribution near the lab cluster speeds up reconfiguration. Especially when adding labs later -- no belt rework needed. Labs tend to cluster together anyway, keeping robot flight distances short and the use case straightforward.

Combined with trains, station-front short-distance unloading assistance is outstandingly effective. Trains deliver in bulk, robots handle the station-to-nearby-facility handoff. As discussed earlier, this division of labor works extremely well. Robots bog down on trunk routes but become instantly convenient in localized station zones. My impression: robots aren't "the logistics star" but rather the squad handling the final push, and that framing prevents most failure modes.

Throughput and Charging Constraints

The most overlooked aspect of robot operations is that throughput isn't determined by robot count alone. Adding more robots seems like it should increase capacity, but if charging points can't keep up, that's where things break. Each Roboport charges 4 robots simultaneously. When that bottleneck stays tight while demand grows, the constraint becomes charging waits, not delivery itself.

This behavior becomes clear in practice. Slightly increasing item requests looks fine initially, then shortly after, robots start congregating around Roboports and delivery noticeably slows. I initially assumed "not enough robots" and added more units, but what actually helped was adding more Roboports. Once I placed additional Roboports, it became immediately obvious that charging waits -- not flight capacity -- were the bottleneck. Throughput recovery was dramatic.

Moreover, when charging conditions deteriorate, robots don't just wait neatly -- they tend to keep flying on partial charge and slow down. So instead of "delivery takes a bit longer because volume is up," the entire network gradually and uniformly degrades. Unlike belts where you can estimate X items/sec per lane, intuitive scaling of robot networks easily leads to misdiagnosed slowdowns.

The Factorio Wiki's logistics network and Roboport pages explain the mechanics, but the operational insight that actually matters is: before adding robots, suspect charging bottlenecks. Robot logistics is convenient, but far more delicate on the throughput side than it appears. Strong with low-volume multi-item loads, but loading everything onto the same network creates sudden pain.

Network Design Tips: Segmentation, Range Control, UPS/Power Awareness

The most failure-prone robot design is connecting everything into one massive network. It looks easy to manage, but in practice robots fly long distances to distant requests, and charging demand clusters unevenly. Stack mall, labs, station unloading, and player supply all on one network, and congestion outweighs convenience. I tried this in a large base and knew it was broken the moment robots started flying end-to-end across the factory.

The safer approach is segmenting networks by purpose. Separate mall, lab, and station-front networks keep robot destinations local, simplify troubleshooting, and prevent one zone's congestion from spreading. This also works well in multiplayer -- someone expanding the station area won't accidentally slow down lab supply.

Roboport coverage shouldn't just expand indefinitely either. Roboports have a 50x50 tile logistics area and 110x110 tile construction area, but daisy-chaining all the way to distant mining outposts or defense perimeters creates long delivery paths that immediately get heavy. Separate "places you want construction reach" from "places you want constant logistics connections" for stability. Extending the logistics net to the frontline for convenient repair and then leaving it permanently connected to the main base drags peacetime supply into the equation.

Power deserves attention too. Robots are handy, but when they jam up, charging demand concentrates at specific points. If power generation is tight at those moments, robot network slowdown and power shortage create a vicious cycle. At scale, massive robot networks also become unfavorable from a UPS perspective. Hard numbers don't tell the whole story here, but experientially, "everything on robots because it's convenient" factories consistently become harder to tune later. The design principle: don't make robots your universal transport solution. Keep coverage short, scope local, and charging points dense. Following those three guidelines lets you extract robot convenience without the downsides.

Community resources like the Japanese Factorio Wiki's robot network page cover charging-count-aware operational knowledge well. In practice, using robots only where needed rather than blanketing the factory produces the most stable results. Robots are a trap when expanded carelessly but genuinely excellent when their role is focused.

ロボネットワーク - factorio@jp Wiki*

factorio@jp Wiki*

wikiwiki.jp

Common Mistakes and Practical Transition Order

Three Failure Patterns with Concrete Fixes

The most common trap is thinking "this method is powerful, so let's standardize on it everywhere." In Factorio, even individually strong logistics methods break in unexpected places when asked to handle everything. I've rebuilt factories over this pattern more times than I can count.

Mistake 1: Full robot conversion. Loading labs, mall, station-front, and player supply all onto one robot network looks brilliant at first. Then demand spikes, charging waits cascade, delivery slows, power gets strained, and UPS starts dipping. Worse, failures in a giant single network are hard to diagnose -- belts show you jams visually, but robots just feel "kind of slow." The fix is straightforward: segment networks for local-only use. Separate lab, station-front, and mall networks, and robots stop making unnecessary long trips.

Mistake 2: Long-distance ore on belts. Belts feel natural in the early game, so extending them to distant ore patches seems logical. I did this all the time. But as distance grows, terrain routing, defense interactions, midpoint repairs, and future rerouting all compound. When a patch depletes, demolishing and rerouting long-distance belts is miserable. Shift the mindset early: route remote resources to trains. Belts for short in-factory organization, trains for external delivery -- that role split makes later expansion dramatically easier.

Mistake 3: Premature full train deployment. Trains are powerful, but jumping straight into station placement, turnarounds, signals, and intersections before your production lines are even established scatters the design. Honestly, I was completely lost the first time. Building an oversized mainline before knowing what the smelting and intermediate flows look like results in impressive stations with nothing behind them. The fix: introduce trains route by route. Start with one distant ore line, add petroleum next -- growing by individual routes keeps failures contained.

My experience says the most stable progression is clear: early game belt-centric, mid-game add trains, late game add robots as auxiliary. This order lets you expand without disrupting trunk logistics. Restated: trunk on trains or belts, last-mile on robots. That's the lowest-accident rate configuration. I've crashed research throughput by putting labs on full robot supply, then immediately stabilized by reverting to belt trunk with robot auxiliary. Robots are convenient, but they shouldn't carry the factory's backbone.

Practical Transition Steps

The trick to smooth transitions is not immediately deciding "belt or train or robot." Instead, inventory your routes by short/medium/long distance first. In-factory adjacent equipment is short range, base edge-to-edge is medium, external resource delivery is long -- and the best method differs significantly by category.

Then assess what each route needs to carry and at what sustained volume. Steady high-volume items like iron plates naturally fit belt trunks. Multiple item types in small quantities suit robot auxiliary. Belt throughput benchmarks (yellow 15/sec, red 30/sec, blue 45/sec) give clear decision inputs for trunk lines. Smelting targets work the same way -- stone furnaces produce iron plates at 0.3125/sec each, so 48 furnaces fill one yellow belt. Routes where these estimates apply cleanly should start as belt-based designs.

Apply the decision flowchart from there: short-range steady high-volume = belt, long-range high-volume = train, short-to-medium low-volume multi-item = robot. It looks complex but really comes down to "is this route trunk or auxiliary?" Trunk = belt or train, auxiliary last-mile = robot. Enforcing that separation prevents mixing.

For implementation, start small, learn, then standardize. Going all-in on train conversion or full robot lab supply at once means any failure affects too large an area. I typically start by training a single distant ore patch and adding robot-assisted station unloading only at that station. Lessons learned there feed into a station template, Roboport layout, and coverage pattern that makes subsequent expansion much lighter.

One particularly failure-resistant practice: don't fully remove belts before completing the transition. When moving distant ore from belt to train delivery, bring the train line up and confirm stable supply before decommissioning the old belt route. Same for labs and malls -- add robot auxiliary while keeping existing trunk in place, and behavior stays predictable. Parallel operation beats full cutover in practice every time.

UPS/Power Optimization Points

Logistics selection isn't just about "can it deliver" -- "will it slow down" needs attention too, or you'll pay for it later. Ignoring this leads to the unpleasant failure mode where everything technically works but the whole factory gradually bogs down.

For robots, the biggest impact comes from robot density and charging congestion. Roboports charge only 4 simultaneously, so demand concentration at a single point creates localized jams. Adding more robot units without addressing this often doesn't help. Giant single-network designs with everything loaded on create compounding UPS and power effects as robots fly farther and wait longer. Robots excel as support personnel, but putting them on trunk duty proportionally increases management costs.

In practice, the community-recommended intersection pattern of "chain signal at entries, rail signal at exits" (commonly called 'chain-in, rail-out') is effective at preventing deadlocks. This guidance draws primarily from community practice, so multiple implementation variations exist.

Belts are visually straightforward, but over-engineering balancers makes both design and modification heavier. Limiting to only the necessary alignment keeps belts a lightweight, stable trunk option. For in-factory steady-state transport especially, simple straight belts are easier to work with and troubleshoot. The fact that yellow-belt smelting targets (48 stone furnaces, 24 steel furnaces) give clear design parameters makes trunk belts naturally resistant to over-engineering.

From this perspective too, the pattern holds: early game belts, mid-game trains, late game robots as auxiliary. Belts build the factory skeleton, trains handle long distance, and robots absorb the annoying multi-item last-mile transport around stations and labs. This division balances power, UPS, and modification load well, making it a highly practical configuration. I tried running labs entirely on robots and hit slowdown, then reverted to belt trunk with robot handoff at the labs -- that configuration lasted the longest. Rather than making the convenient tool the star, placing each tool only where it belongs makes the whole factory stronger.

How Space Age Changes the Equation

Interplanetary Logistics and Trunk Design Philosophy

Space Age adds an entirely new dimension: what to move between planets and how. The interesting part is that more logistics options don't mean total freedom -- instead, where to place the trunk for each outpost gets asked more forcefully. Where ground factories needed belt/train/robot role allocation, Space Age layers "cross-planetary supply lines" on top.

The core thinking isn't fundamentally different, though. Interplanetary logistics feels like an ultra-long-distance trunk line. It's a layer above the trains connecting your factory's ends. So the framework becomes: establish the big flows between planets, then handle each outpost's internals with ground-level methods. Once I made that mental shift, everything got much easier. Initially I assumed "we're in space now, there must be entirely new optimal solutions," but the habit of separating trunk from auxiliary worked just as well.

The Factorio Wiki's Upcoming features page and Factorio: Space Age on Steam confirm that the expansion broadens logistics scale, but this section won't delve into progression or unique mechanics. The key awareness: in Space Age, which layer of logistics you assign to which method matters even more than "which method is most convenient."

Upcoming features/ja

wiki.factorio.com

Space Platform Constraints

Where Space Age most noticeably shifts your thinking is that "just use robots" doesn't always work in space. This caught me off guard initially. Late-vanilla instincts lean toward offloading tricky routing onto robots, but space platform scenarios have situations where belts and pipes form the assumed backbone, and a ground-style robot-dependent approach creates mismatches.

This isn't arbitrary inconvenience -- it reads better as game design that emphasizes building logistics structure first. On the ground, robots can absorb poor routing and layout compromises to some degree. In space, that escape valve is thinner, forcing you to decide "what comes from where and flows to where" with belts and pipes upfront. It might seem like a detour, but it actually produces faster startups.

I once tried extending the ground approach in space, planning to "clean up the small transport later," and ended up making flow harder to read. Switching to laying down belt and fluid trunk lines first brought immediate clarity. Robots are flexibility tools; belts and pipes are structural tools -- that distinction hits harder in Space Age.

Selection Principles Shared with Vanilla

Even with new elements, the selection framework's skeleton matches vanilla. Separating trunk from auxiliary, choosing the lead method by distance and volume, and estimating power and processing load all apply directly. Space Age doesn't demand a different philosophy. If anything, the expanded element count makes sloppy fundamentals collapse faster.

For example: interplanetary logistics leans trunk, in-base steady-state transport leans belt/pipe, localized handoffs and multi-item gap-filling lean robot. This maps directly onto the vanilla insight that "robots shouldn't carry the trunk" and "robots stabilize when limited to local scope." As noted earlier, robots are convenient, but Roboport simultaneous charging limits mean an apparently smooth network can suddenly degrade when density and waiting interact. In Space Age too, planning where convenience's backlash lands keeps designs viable.

What Space Age truly adds is layer count, not fundamentally different methods. Short-range and long-range ground logistics gain an interplanetary super-trunk above them. Space platforms then add belt-and-pipe-first environments. The vanilla principle of "keep trunks readable, keep auxiliary limited" therefore becomes even more relevant. Staying grounded in layer-based logistics thinking rather than chasing flashy new features keeps things organized and comprehensible, even without spoilers.

Summary

For a final quick-reference: short-range high-volume = belts, long-range high-volume = trains, low-volume multi-item and obstacle crossing = robots. When in doubt, just separate trunk from auxiliary before making any other decision.

• Use-case quick reference: Short-range bulk = belt / Long-range bulk = train / Low-volume multi-item with obstacles = robot
• Your next step: Map out your factory's short, medium, and long-distance routes and assign a primary method to each. A good starting configuration is main bus on belts, remote ore on trains, mall restocking on robots.
• Final note: Trains are fine to introduce only when they become necessary. Just auditing my existing factory against this decision framework visibly reduced both congestion and power spikes.