【Factorio】Interplanetary Logistics and Rocket Transport Design (Space Age)

Interplanetary rocket transport in Factorio 2.0 with Space Age becomes much more stable when you design it as an extension of ground logistics rather than treating it as a special one-off delivery event. The approach that has proven most reliable is to structure your system with the rocket silo as the supply side, cargo landing pads as receiving and requesting points, and the space platform hub serving dual roles as both a requester and passive supplier.

I'll be honest—when I first started, I only wanted to send 200 repair packs via rocket. But the launcher wouldn't fire because it was waiting for a full load, and once the supplies arrived at the destination, the cargo landing pad's single-stack receiving capacity created a bottleneck that caused serious congestion. Through troubleshooting, I discovered that by establishing just a few ground rules—minimum payload thresholds, surrounding infrastructure layout, and per-planet request assignments—even small supplementary shipments and emergency resupply runs could be fully automated and run smoothly.

This guide is written for players ready to move beyond manual space logistics management. It covers how to distinguish between regular bulk shipments, small supplementary runs, and emergency repair shipments, and explains practical design rules that prevent bottlenecks.

Foundational Knowledge for Factorio Interplanetary Logistics and Rocket Transport

Checking Target Version and DLC

The foundation of this discussion is Factorio 2.0 + Space Age. Space Age launched on 21 October 2024 as an expansion that fundamentally changed how rockets are positioned in the game. As the expansion itself makes clear, reaching space and accessing other planets has become central to progression, so it's more helpful to view rockets as regular logistics equipment rather than as "endgame reward infrastructure".

Losing this framing makes it harder to compare intra-planetary and inter-planetary logistics using the same design principles. I initially viewed space logistics the same way I'd expand train networks on a planet, but Space Age requires a deliberate conceptual shift. Within a planet, the rule is straightforward: if you need constant high volume, use belts; for long-distance bulk movement, use trains; for short-distance flexibility, use logistic robots. Between planets, there's no alternative—rockets become essential because they're the only primary means to transfer resources to other worlds.

With this framework in place, transport method comparison becomes much clearer. Belts excel at continuous supply at a base speed of 1.875 tiles/second, with high-speed versions doubling that and express versions tripling it. However, they become unwieldy over long distances. Trains are specialists at consolidating long-distance bulk movement and often become the workhorses of large-scale transport. Logistic robots can navigate obstacles freely and handle flexible distribution, but charging infrastructure and service radius become limiting factors. At the boundary between planets, that three-way system breaks down entirely, and rockets take over because they're the only way to bridge the gap.

Differences from Vanilla Satellite Launches

In vanilla Factorio, rockets had a reputation as "the near-endgame cutscene"—a lasting memory for many players. I certainly held that view strongly: satellites = ending. So when Space Age arrived, it took me a while to shift my mental model toward treating rockets as production infrastructure to be mass-scaled and scheduled.

But Space Age changes this completely. Rockets are no longer occasional special events. They become your daily logistics backbone for construction material runs, repair shipments, and planet-specific resource cycles. In ground terms, designing "how to run" rocket logistics is as fundamental as placing belts or train tracks. Once you understand this shift, intra-planetary backbone design and inter-planetary resupply design click together as one unified system.

The satellite element hasn't vanished entirely. The cargo landing pad has a built-in mechanic where satellite-carrying rockets award 1,000 space science packs on launch—a detail confirmed in the 『cargo landing pad - Factorio Wiki』 page. However, this guide's focus is how to handle rockets as freight transport, not as a research vehicle. Knowing that research pack reward mechanic exists is useful background, but the design centre should remain on "what, from which planet, in what shipment type do I want to flow?"

Cargo landing pad - Factorio Wiki

wiki.factorio.com

Watch Out for Version Differences in Recipes and Specs

Rocket information is particularly prone to mixing old and current details. This matters because outdated articles or recipe screenshots can derail your current design.

The baseline figure to lock in is: rockets need 100 rocket parts to complete, with each part counting as 1% progress. This is the current standard on the 『rocket part - Factorio Wiki』 page and forms the foundation for fitting a single shipment into your production line. If you think of one rocket launch not as "a single big event" but as "a multi-step manufacturing process with 100 increments", the logistics of part supply become much more readable.

Older rocket documentation mentions Rocket Control Units (RCUs), which have been retired in Space Age. If you're basing assumptions on the old system, you'll get confused wondering "why don't I need RCUs anymore?"—but that's a version difference. Looking at the 『Upcoming features - Factorio Wiki』 page and the current rocket part requirements makes it clear: pre-2.0 vanilla rocket composition and 2.0 + Space Age rocket composition are different systems and shouldn't be read as the same thing.

This difference runs deeper than recipe changes—it reshapes design philosophy. If you keep the old mental model, rockets remain "ultra-endgame luxury goods", but Space Age treats them as infrastructure to integrate early. That context shapes everything: when building intra-planetary logistics, it pays to think ahead to how eventually you'll feed the rocket silo, reducing waste. For instance, consolidating steady bulk flows onto belts, routing long-distance raw material and construction material via trains, and handling fine supplementary deliveries to the silo via robots works very well together. Then beyond that junction point, cross-planet shipments ride rockets. When that integration clicks, ground and space logistics stop feeling like separate games entirely.

Rocket part - Factorio Wiki

wiki.factorio.com

The Three Facilities Forming Interplanetary Logistics and Their Roles

Rocket Silo

The rocket silo is the most straightforward of the three facilities: the supply side. In operational terms, think of it as the dispatch point that sends resources made on the ground into orbit for other worlds. My design work became much cleaner once I reframed it mentally as a "supply chest for space". The architecture of ground-side aggregation becomes straightforward: collect what you want to send, feed it into the silo. What looks special is, in mental organisation, just the next step in ground logistics.

Rockets themselves complete at 100 rocket parts, as documented on the 『rocket part - Factorio Wiki』 page. That means a silo isn't just a place to stack cargo—it's a facility managing manufacturing progress for each shipment. This trait means a silo's bottleneck isn't only "I don't have enough stuff to send". It can also stall because rocket part supply dries up, cargo sits scattered and can't aggregate, a small shipment can't meet launch criteria, and similar failure modes.

In practice, anchoring the silo to the factory's exit point as a consolidation hub for shipments tends to be more stable than feeding random lines directly into it. Pre-aggregating items that need inter-planetary balancing—building materials, repair goods, ammunition, module stock—clarifies what you're sending and to which destination. Conversely, jamming many disparate supply lines into the silo directly means ground-side congestion becomes inter-planetary delay.

Once you commit to treating the silo as the supply operator, design decisions clarify. Rather than expect the silo to make sophisticated local decisions, hold the ground layer responsible for sustaining inventory and pushing it out. I began treating the silo as "space logistics' shipping department" rather than "space logistics' command centre", and responsibility shifted to the requesting side to pull what the silo supplies. This separation makes troubleshooting much faster.

Cargo Landing Pad

The cargo landing pad acts as a receiving and requesting hub on the planet side. It's where material descending from orbit lands, and simultaneously, it's the window showing the orbiting system "what this planet wants right now". Mapping it mentally to ground-side request chests makes the whole inter-planetary logistics picture suddenly visible. That parallel understanding is what finally made things click for me.

The critical detail in the official 『cargo landing pad - Factorio Wiki』 is that it can only receive one stack per delivery. This is deceptively fundamental. When imagining bulk deliveries, it's easy to miss: the receiving end isn't infinitely greedy. For small high-frequency resupply, this works fine; but if delivered goods bunch up, the landing pad becomes the bottleneck.

Because of this constraint, the area surrounding the landing pad must be fast at clearing deliveries. Whether received items go to robots, immediately onto belts for sorting, or to a train depot staging area hugely affects how smoothly operations flow. In my experience, the landing pad is less a warehouse and more the planet's front door. If packages pile up at the door, the next shipment queues. You must plan the unload route as part of the landing pad strategy, not separately.

There's a mechanic where launching a satellite-carrying rocket causes the cargo landing pad to receive 1,000 space science packs, but from a logistics design angle, "receiving planet's access point" is the more useful framing. Place requests here, receive orbit deliveries here, redistribute to ground logistics. Once that flow becomes visible, deciding what each planet self-supplies versus imports becomes much easier.

Space Platform Hub

The space platform hub is your space-side operations centre. From official pages, it has inventory, features auto-request functionality, and acts as the platform's core. The most operationally useful mental model is: it's a request chest, but items in it also feed into platform operations—think of it as having both a requester face and a supplier face.

This dual nature—"a place collecting what you want, and a place fuelling orbital work"—isn't something the official docs state down to the letter, but treating it this way makes running platforms much easier. It was my biggest initial confusion point. Thinking of the hub as a plain warehouse, you can't reconcile why it makes requests or why platform-side production depends on its inventory. But once you frame it as "gathering point for what's needed, and resource pool for orbital tasks", it makes sense.

In platform operations especially, you can't just line up chests and organize freely like on ground. How you understand the hub's role becomes the design axis. Wanting construction materials or repair goods is request-chest behavior; having on-hand stock become the platform's operational resources is supply-side behavior. So this facility alone isn't simply "receiver" or "sender"—it's the space-side backbone of both demand and reserves.

With this framing, the three facilities align cleanly: ground aggregates and launches via rocket silo; planet receives and requests via cargo landing pad; space coordinates demand and holds stock via hub. Honestly, after grasping this, I stopped seeing space logistics as "a complex system" and started treating it as "standard logistics chest roles, just split across locations".

Space platform hub - Factorio Wiki

wiki.factorio.com

Facility Role Comparison Table

While text explanations work, building designs benefit from seeing roles split in one place. Especially "who's the supplier, who's the requester, where does it jam" visibility helps troubleshooting speed.

What stands out is that the three aren't similar boxes—launching, receiving, space-side relay show clear division of labour. When something jams, slicing it as "sending broke" vs. "receiving's full" vs. "space-side request logic is muddled" drastically shrinks the hunt. After I separated these concerns, running speciality planet shipments and emergency repair runs on the same network became much easier.

Steps to Build Your First Automated Transport Line

Research: Rocket Silo and Reaching Space

For a minimal working setup, the starting point is rocket silo research. Without it, you literally cannot push goods from ground to orbit. Since your goal isn't "move maximum cargo", but rather auto-run small resupply shipments between Nauvis and orbital space or other planets, your first milestone is stabilizing one shipment.

Setting up rockets means stacking rocket parts to completion, as per the 『rocket part - Factorio Wiki』 spec. A common early trap is feeling like "I've unlocked space logistics" the moment you place the silo. In reality, engineering the supply lines feeding the silo and aggregating the cargo you want to send are still open problems. I remember that first rush of "the world opened up"—but honestly, the real work started after.

One mindset that helps at this stage: keep your first shipment narrow—construction supplies plus minimal resupply goods. If you expand the shipment scope immediately, you won't see where it clogs. The failure mode is that you research, get excited, overload the request, and then both silo undersupply and request misconfiguration hit at once, making everything impossible to debug. Going narrow first and prioritizing repeatability means when your launch hits, you know exactly which step worked.

Advancing to Planets/Platforms

Next, you need a destination. Two routes exist: send directly to resupply an orbital platform or land on another planet's surface. For a minimal setup, the easier path is to build a space platform first and set up resupply delivery to it. Orbital platforms are central to Space Age and allow surface-orbit cargo exchange when positioned above a target planet.

Crucially, you must think: "where is the platform stationed when I make the handoff?" If the platform isn't in the target planet's orbit, ground-orbit trades don't happen. So what looks like a logistics problem can actually be a scheduling mistake. I've definitely had the silo running smoothly while the platform orbited the wrong world, cancelling all deliveries silently. This blindspot catches many players.

The same logic applies to direct planetary landings—verify the landing site is prepared before automating resupply. If you automate delivery to a planet with no receiving infrastructure, cargo arrives but can't unload; the next shipment then queues uselessly.

Placing the Cargo Landing Pad

For surface receiving, the cargo landing pad is the top priority. Without it, you have no planet-side receiving mechanism. Execution-wise, it's not just "place pad" but place pad + connect unload routes immediately, treating both as one unit. That tight coupling prevents later regrets.

As the 『cargo landing pad - Factorio Wiki』 confirms, receiving is one stack per drop. This matters hugely in practice. Cargo stacks fast without fast offload, and the receiving slot gets clogged, slowing subsequent drops. Early thinking often goes "small shipments will clear fast enough", but in reality, small shipments suffer most from this limit because multiple item types hit the pad together and bottleneck at the exit.

Placing the pad adjacent to belt or robot unload points keeps things manageable. For robots, the logistics network service radius is 50x50 tiles, so nesting everything inside one radius works cleanly. A common mistake is siting the pad remotely and later extending long unload lines to it—then monitoring and adjusting both delivery confirmation and bottleneck hunting become tedious.

Configuring the Space Platform Hub's Requests

If the destination is an orbital platform, the hub becomes your focus. Without requests here, ground-side has no signal for what to send. The hub is request origin for resupply, so initial automation works best by requesting only the minimum supplies for one startup phase.

For example, early requests should include just the construction materials you'd use during the initial platform expansion. Overloading request items muddies which one's failing to arrive. Manual requests also require specifying the source planet, so unless you know which world is supplying what, confusion spreads fast. I once set up a planet resupply expecting supplies from Nauvis when the request was pointed elsewhere—silo hummed along but no delivery came.

For a first run, "this shipment is for platform construction startup" is the clearest framing. If you want to use ghost construction to outline expansion, auto-requests pair well. If you want fine-grained control over which planet supplies what, manual requests are more transparent to debug.

Connecting Ground-Side Supply

Once requests are active, they don't pull goods by themselves—you must feed the rocket silo. For a minimal setup, skip enormous dedicated stations or train networks. Simply create one reliable supply line into the silo. Belts or robots both work, but belts are easier to visualize for initial debug.

The key is separating rocket part materials from cargo itself in your head. When the silo stalls, ask: "Are delivery goods missing, or are rocket parts backing up?" Conflating them leads to chasing phantom problems. I've definitely wasted time boosting cargo supply when the real bottleneck was part manufacturing.

For early automation, channel dedicated surplus goods rather than haphazardly dumping ground logistics into the silo. If shipment intent changes every cycle, testing results get noisy and you can't reproduce issues clearly.

Test-Running Small Shipments and Checking Logs

Once wiring and requests are live, skip straight to production and instead test-run a small delivery. The goal isn't just "does cargo arrive?"—it's "does it await full-load caps?" and "do cargo landing pads get swamped by single-stack receiving limits?" Those two checks matter hugely.

The minimum payload threshold is one critical behaviour to watch. Public wiki pages don't exhaustively document default values, but community observation confirms rockets try to fill before launching. If you don't lower the minimum, small-shipment auto-launch hangs on "nearly loaded". I hit that exact wall on my first attempt—building supplies wouldn't launch until the silo had way more than needed. Lowering the threshold immediately unblocked everything.

Trace the flow in logs: cargo gathers at silo → rocket launches → platform/surface receives → landing pad outputs downstream. Wherever it halts, that's your bottleneck. If arrival happens but onward flow slows, suspect weak landing pad discharge capacity first.

For this test phase, redefine success as "complete one cycle with small volume", not "deliver large quantities". Once that cycle runs, expanding request items or shipment count doesn't destabilize. If the first cycle itself is shaky, expanding just breaks it wider.

Design Fundamentals: Full-Load Waiting, Single-Stack Limits, and Per-Planet Requests

The top fail-mode in small resupply is "I set requests but rockets won't launch"—appearance of "full-load waiting". Here, important caveat: official docs don't spell out defaults in explicit detail. Community playtesting suggests "rockets load to capacity before launching" behavior, so practical operations usually involve lowering the minimum payload threshold. For authoritative precision on this mechanic, checking the Factorio forums or community hubs (e.g., r/factorio, factorio.jp communities) is advisable.

By contrast, bulk runs on ore, intermediates, or building materials don't want minimum payloads set too low—you'd get ten-shipment fragmentation instead of dense batches. Small resupply and bulk runs are different animals on the same rocket infrastructure. Splitting them conceptually pays off:

Small shipments chase speed; bulk shipments chase density and receive-side capacity. Conflating them creates a lose-lose: small goods lag, bulk goods pile up downriver.

The Single-Stack Receipt Bottleneck at Landing Pads

The often-overlooked constraint is in the 『cargo landing pad - Factorio Wiki』: one stack per delivery. Ground-side production and launches can run flawlessly, but if the landing pad and its surroundings can't discharge goods fast enough, subsequent deliveries queue.

For small-run resupply, this limit isn't obvious. It bites when bulk shipments concentrate on one pad. I once consolidated all building materials onto one pad on a destination planet. Silo and launch worked fine, but on-planet discharge lagged so badly that resupply felt glacial. Root cause? Single landing pad intake, plus weak surrounding infrastructure.

Remedy: multi-pad distribution + beefed-up discharge pathways. For planetary bulk movement, trains are the backbone; nearby short-range is express belts, and multi-item sorting favours robots. With robots, anchoring the intake to a 50x50-tile logistics network range gives good visibility and fast response.

Mental model: small resupply is "one pad to adjacent exit"; bulk is "multiple pads fanning into multiple downstream channels". Especially for bulk, just adding buffer chests before the pad won't help if the main line stays thin—you need the belt, train, or robot highway to widen all the way through.

Per-Planet Request Origins and Assignment Rules

Another high-frequency snag: each space platform request requires a specified source planet. Manual requests are hardwired to a single planet supply. If you write one request hoping goods flow from anywhere, you'll get silence if the designated source runs short.

Community logistics wisdom here is instructive: treating "allow any source" as forbidden and "same item needed from two planets = two separate requests" keeps operations sane. If you want Nauvis-made building material and locally-made equivalent, don't merge them. Instead, create "Nauvis material request" and "local material request" separately.

Vague sourcing breaks silent resupply. Multi-planet platforms are especially prone to "request set up but pointing the wrong way" bugs. I personally dodge this by narrowing small resupply scope and pre-deciding which planet supplies each run. Nauvis shipment? Mark it Nauvis. Local buffer? Mark local. When flow sags, source confusion doesn't compound the mystery.

Auto-requests behave differently—they'll accept from any available source. For scenarios demanding planet-specific preference, manual requests stay more transparent to trace.

Settings Checklist

Rather than obsessing over raw numbers, ask what failure mode each setting prevents. These four points help me kill the archetypal mistakes of "small goods stuck waiting" and "bulk goods piling up at landing":

• Is this request small-resupply or bulk?

Blurred role means you'll botch both minimum payload and pad count. Ammo and repair packs go small-resupply; materials and intermediates go bulk. Split them mentally from the start.

• Does minimum payload fit the request type?

Small goods want low thresholds (frequent launches), bulk goods want high thresholds (dense launches). Low-threshold small requests still waiting for full load will trigger long shortages.

• Is source planet explicitly set?

Manual requests depend on source clarity. Ambiguous source makes request failures impossible to isolate. Multi-planet restocking should duplicate requests, not merge them.

• Do landing pad count and downstream transport match?

Bulk receiving on one pad with thin onward transport jams at the pad. Pad count and belt/train/robot highway capacity are one integrated choice.

Official UI label precision isn't publicly exhaustive on all fields, but these four axes cover nine-tenths of space-logistics failure modes. Reality shows problems cluster around "can't deliver" variants—"sends fine, doesn't land", "lands fine, doesn't move"—more than outright send failures. So Settings matters less for quantity and more for full-load waiting, source clarity, and receiving throughput.

Transport Method Comparison: Belts, Trains, Robots, Rockets

Steady Ground Flow

When viewing intra-planetary logistics as a system, if flow is steady and you never want it to stop, belts are the baseline. Ores feeding smelters, smelted output feeding fabricators, fabricated items feeding assembly lines—straightforward flows favour belts. The 『transport belt Physics』 page documents base belt speed at 1.875 tiles/sec, high-speed at 2x, and express at 3x. Same layout, different colours = stepwise throughput increases.

Belts' real strength is making continuous supply visible. You see jams and shortages in the line itself, making root cause easy. I favour belts immediately after landing pads for initial sorting—robots look tidy but hide starvation points. Later adjustments become painful if you can't read the flow state.

Trade-off: long-distance full-belt lines grow unwieldy. Hundreds of tiles of belt require heavy reconfiguration with each upgrade or branch. So belts concentrate on "steady bulk in one segment"; distance routing goes elsewhere.

Transport belts/Physics - Factorio Wiki

wiki.factorio.com

Backbone Long-Distance Ground

Long distances favour trains decisively. Scale makes this stark. Once home base and ore fields separate, belts stop being viable—reconfiguration costs and expansion friction spike hard. Trains consolidate multi-resource stations, handle bulk volume, scale by adding cars or schedules. Rail setup costs (station design, signals) exist, but backbone throughput is strong. Ore, plate, and materials benefit most—anything arriving in large sustained batches from far away.

Chaining platforms to planets uses the same logic: stage a depot near the landing pad, redirect through trains to subdistribution. The depot swallows landing-pad variability; downstream runs smooth and visibly jammed layers.

For what it's worth, I often run robot intake (pad → buffer) then train trunks (buffer → factories). Robots polish the pad's per-drop jitter; trains hold steady bulk velocity. Sites don't thrash, bottlenecks show clearly, and multi-player coordination stays sane.

Short-Range Flexibility

For flexibility over range, logistic robots are the clear choice. Roboport service is 50x50 tiles—nest intake and destination inside one zone and usability jumps. Robots ignore terrain; multi-item sorting, mopping up before depots, resupply runs, and depot redirection all suit robots. They shine in complex layouts and short-range tight quarters.

But robots aren't universal. The charging bottleneck hits hardest. When demand spikes, not robot count but charging throughput lags. Flow shrinks while the robot fleet sits in charging queues. Robots buy flexibility over throughput. They excel at "intricate nearby, multiple items, low steady volume" and falter at "planet-wide backbone". If you ask robots to be your main long-distance highway, you'll sink enormous charging infrastructure before satiation.

Versus belts and trains, robots' place is purchasing freedom over flow volume. Near depots, malls, resupply posts, initial landing pad sortation—here robots shine. Away from that niche, cost explodes.

Interplanetary

Crossing planets forces rockets as essential. That's the hard boundary. Belts, trains, robots—all strong intra-planetary—cannot address cross-planet transfer. Ground dominates until you hit the planetary edge; only then does rocket duty begin.

Interplanetary flow diverges from ground even while sitting on the same infrastructure. Ground jams from "thin rail", "slow belt", "short roboport range". Rockets jam from full-load caps, payload design, landing pad discharge. Landing capacity is king—single-stack receipt means arrival bottlenecks bloom regardless of launch power. Treat rockets like trains is wrong; treat rockets as carefully packaged one-time batches landing into finite throughput is right.

Splitting by role—construction batches, repair batches, planetary-specialty batches—prevents muddled responsibilities. Pre-deciding the landing pad → belt/train/robot flow unlocks design clarity. The moment rocket discipline clicks, space and ground feel like one system.

Quick comparison table:

Decision Flowchart

Rather than competing methods, ask which segment gets which type. The logic is straightforward:

1. Target on different planet?

• Yes → Rocket
• No → Continue

1. Same cargo type, continuous high volume, same path?

• Yes → Continue
• No → Logistic robot

1. Long-distance backbone connecting stations?

• Yes → Train
• No → Belt

1. Short-range, high variety, frequent routing changes?

• Yes → Logistic robot
• No → Belt

This tree makes role assignment clear: steady bulk = belt, distant bulk = train, nearby flexible = robot, cross-planet = rocket. Real designs combine all four: "rocket to planet → robot preclearing → train backbone → belt steady supply". Once that one-line architecture clicks, space and ground stop feeling like separate games.

Common Failure Modes and Fixes

Overstocking and Constant Rocket Launches

A frequent new-player trap: conflating request size with full-load settings. Say destination wants items slowly, but you set high minimum payload. Rocket waits forever. Then it suddenly launches with bundled surplus, receiving side gets swamped and runs out of storage or discharge. Result: the worst state—"starved normally, drowns occasionally".

Worse, it looks like progress since backlog finally