[[Factorio]] Interplanetary Logistics and Rocket Transport Design (Space Age)

Interplanetary rocket transport in Factorio 2.0 and Space Age becomes dramatically more stable when treated as an extension of ground logistics rather than special event delivery. Organizing rocket silos as supply, cargo landing pads as receiving and requesting, and space platform hubs as requesting and passive supply centers is the approach I found least troublesome.

Honestly, at first I set up rockets just to send 200 repair packs, but they sat waiting for a full load and never launched. Even when they finally did arrive, the unloading at the cargo landing pad bottlenecked on single-stack receiving, causing significant headaches. What became clear was that by simply deciding minimum load thresholds, surrounding layouts, and per-planet demand rules upfront, I could automate bulk regular shipments, small replenishment runs, and emergency repair missions quite smoothly.

This article is for players in Space Age who want to graduate from manual space logistics to full automation, covering how to distinguish between bulk regular shipments, small replenishment runs, and emergency repair missions, breaking it down into design rules that don't jam up.

Factorio Interplanetary Logistics and Rocket Transport: Foundational Knowledge

Confirming target version and DLC

The foundation for this discussion is Factorio 2.0 + Space Age. Space Age released on October 21, 2024, and fundamentally changed how rockets are positioned. As Space Age itself clarifies, reaching space and accessing other planets become central to progression, making rockets not "late-game rewards" but "regular-use logistics equipment" in your understanding.

Without this context, comparing in-planet and interplanetary logistics becomes difficult. I initially approached space expansion like extending train networks, but Space Age required a conceptual shift. Within a planet, steady mass flow goes on belts, long-distance mass transport uses trains, short-distance flexibility favors logistic robots. But interplanetary, only rockets work. Rockets become the essential backbone for delivering goods to other planets.

Once you lock in this mental model, transport mode comparisons become much clearer. Belts excel at continuous supply—basic belt speed is 1.875 tiles/second, fast belts double that, and express belts triple it. However, longer distances cause belt networks to balloon in size. Trains handle those long-distance chunks beautifully, becoming the hero for mass transport. Logistic robots ignore terrain obstacles and handle complex layouts with ease, but robot charging and station coverage become bottlenecks. The moment you cross planetary boundaries, none of those three options reach—rockets become the sole solution.

Transport belts/Physics/ja

wiki.factorio.com

Differences from vanilla satellite launches

In vanilla Factorio, rockets were "almost an ending cinematic" for a long time. Most players remember rockets as "load a satellite and launch"—then the game ends. I definitely held that mental image strongly, so satellite = ending was deeply ingrained. When Space Age dropped, it took a bit to shift my thinking and treat rockets as mass-production equipment.

But in Space Age, it's completely different. Rockets aren't rare special events—they become the daily face of logistics, running construction shipments, repair runs, and planet-specific resource deliveries. It's like placing belts and trains on the ground: "how do I design this to work?" becomes the design challenge. Once you grasp this shift, in-planet backbone design and interplanetary resupply design click into a single coherent system.

Satellite payloads haven't disappeared. Cargo landing pads have a mechanic where launching a satellite-equipped rocket receives 1,000 Space Science Packs—confirmed in the Cargo landing pad - Factorio Wiki. But this article's focus isn't there; it's how to treat rockets as cargo transport. Knowing the space science pack mechanic is enough; the design focus should be "what, from which planet, in what shipment pattern?"

Cargo landing pad - Factorio Wiki

wiki.factorio.com

Version differences in recipes and specs—watch out

Rocket-related information mixes old and current specs easily. Searching old guides or outdated recipe screenshots will break your current designs.

The key point: rockets complete at 100 rocket parts, each worth 1% progress. This baseline from the Rocket part - Factorio Wiki is what you build your supply line around. Viewing one launch not as "one big event" but "100 steps of manufacturing progress tied to logistics" makes part supply blockages much more readable.

Meanwhile, the Rocket Control Unit (RCU) from older rocket info doesn't exist in Space Age's framework. Sticking to old assumptions causes confusion ("why isn't RCU production needed?"), but checking Upcoming features - Factorio Wiki and current rocket part pages, the difference is a version split: old vanilla rocket composition and 2.0 + Space Age rocket composition shouldn't be read as the same thing.

This version difference isn't just recipe changes—it affects design philosophy. Old thinking keeps "rockets are super-expensive endgame items" alive, but Space Age shifts to "integrate rockets into logistics early." So even when designing in-planet logistics, thinking about how to feed rocket silos upstream cuts waste. For example: steady high-volume intermediate materials on belts, long-distance ore and building materials on trains, fine-grained resupply to the silo on robots. This lineup has excellent compatibility. Beyond that, inter-planetary shipments board the rockets. Once this unification clicks, ground and space stop feeling like separate games.

Rocket part - Factorio Wiki

wiki.factorio.com

Three Facilities That Build Interplanetary Logistics: Their Roles

Rocket silo

The rocket silo is the clearest supply side of these three facilities. Its role: the dispatch point sending ground-produced goods into orbit. Once I started thinking of the silo as "a supply chest for space," the design around it became incredibly straightforward. Aggregate everything you want to send from the ground into the silo. It looks special, but mentally it's just ground logistics extended.

The rocket itself, per the Rocket part - Factorio Wiki, completes at 100 rocket parts. So the silo isn't just a cargo loading bay—it's dispatch infrastructure carrying per-launch manufacturing progress. This property means silo bottlenecks aren't only "cargo supplies shortage." Rocket part supply drying up, cargo sources scattered and delayed, small shipments facing heavy launch conditions—any of these stops operations.

In practice, positioning the silo at the factory's tail end works less well than treating it as a consolidation dispatch station for materials collected via trains or backbone belts. Pre-consolidating materials at the silo—construction supplies, repair stock, ammo, module ingredients—makes it clear "what planet is this equipment serving?" Conversely, ramming different lines directly into the silo makes ground bottlenecks cascade into space delays.

Once you commit the silo to the supply role, design decisions become crisp. Rather than expect the silo itself to make fine judgments, let ground logistics own the responsibility of building inventory and dispatching. I initially saw the silo as "the central command of space logistics," but it's actually just dispatch. Control comes from demand shaping—the supply side answers that demand. This structure makes troubleshooting much faster.

Cargo landing pad

The cargo landing pad is the receiving and demand-issuing hub on the planetary side. It's where goods from orbit touch down and simultaneously signals "what does this planet want?" to orbit above. Think of it as a demand chest on the ground, and interplanetary logistics instantly becomes far more visible. I finally got it through my head with this mapping.

The critical point from Cargo landing pad - Factorio Wiki: it accepts only one stack at a time. This is deceptively fundamental. Designers imagining bulk shipments often miss it—the receiver isn't infinite. Small frequent deliveries work fine, but concentrated arrivals bottleneck here easily.

This constraint makes the area around the pad critical: "material must flow away fast after landing." Whether you handle goods via robots, immediately convey them, or feed them to a train staging area drastically changes perceived congestion. In my view, the landing pad is less "a warehouse itself" and more "the planet's front door." Cargo piling at the door stops the next shipment, so think about downstream flow immediately after arrival as a unified piece.

The Space Science Pack receipt (1,000 units) when launching a satellite-equipped rocket is a mechanic, but for logistics design, "your planet's receiving window" understanding matters more. State demand there, collect space arrivals there, redistribute to ground logistics. Seeing this full loop makes deciding what to self-supply and what to import per planet much easier.

Space platform hub

The space platform hub is the operational hub on the orbital side. Per official pages, it holds inventory, has auto-request capability, and acts as the platform center. The mental model that works best: a demand chest that also supplies materials to platform operations simultaneously.

This "demand chest with supply-like behavior" framing isn't the official verbatim—it's a framework that makes hands-on operation vastly more intuitive. At first, this was my haziest spot. Thinking of the hub as just a warehouse left me confused about how it issues requests or why it supplies platform work. Flipped around—a place collecting what you need, simultaneously feeding platform operations—it clicks.

Especially on platforms, you can't simply line up chests like ground layouts allow, so how you understand the hub becomes your design axis. Wanting building materials or repairs represents demand-chest behavior; having inventory in the hub that feeds platform operations represents supply-side identity. So this facility alone isn't simply "receiver" or "sender"—it's the orbital demand and storage nexus.

This framework aligns the three facilities beautifully. Collecting on the ground and sending to space = rocket silo. Receiving on a planet with demand = cargo landing pad. Demanding in space while holding inventory = space platform hub. Honestly, once I understood this, "space logistics is complex machinery" became "logistics chests with roles split across locations"—much simpler.

Space platform hub - Factorio Wiki

wiki.factorio.com

Facility role comparison table

Text explanations work, but when building, a table cutting roles apart prevents hesitation. Particularly seeing "who supplies, who demands, where do jams occur" on one sheet speeds troubleshooting significantly.

What emerges: three facilities aren't similar boxes—they're dispatch, receipt, and orbital relay, clearly specialized. When stuck, asking "is dispatch failing, receipt choking, or orbital demand setup weak?" immediately narrows the cause. Once I cut issues this way, running planet-specific shipments alongside emergency repairs on the same network became much less messy.

Steps to Building Your First Automated Transport Line

Research: Rocket silo and space access

For minimal setup, start with rocket silo research. Without it, you have zero way to push goods from ground to orbit—obvious, but important. Since your goal here is "auto-run small replenishment shipments" from Nauvis to the space platform or another planet, not "move massive volumes," achieving one stable shipment first matters.

Rocket prep requires stacking rocket parts to completion per the Rocket part - Factorio Wiki. The common failure: placing the silo and feeling like "space logistics is unlocked." In reality, supplying parts to the silo and aggregating your desired cargo are separate problems. I felt like the world opened up post-research, but honestly the real work started after.

One thing to know at this stage: keep your first shipment to construction materials and minimal supplies. Adding more items immediately obscures where jams happen. The failure pattern: post-research, you enable "send everything," creating simultaneous silo supply shortfalls and request misconfigs. Start by prioritizing reproducibility; narrow the shipment role sharply upfront.

Reaching planets/platforms

Next, prepare receiving points. Destinations split two ways: resupply the space platform directly, or land on another planet's surface. Minimum viable setup favors starting with a space platform—easier to build and test. Space platforms are Space Age's core feature; while docked at a target planet's orbit, they handle ground transfers.

Critical: understand not just "what to send" but "where is it parked when we transfer?" If your platform orbits elsewhere, ground-to-space handoff stalls. It looks like a logistics problem but is actually a routing misconfiguration. This is subtly crucial. Staring at the silo while your platform is nowhere nearby doesn't work.

Same logic applies to direct planetary progress: confirm the receiving site is operational first. Setting up auto-resupply before the landing site exists means goods arrive but can't unload—next shipment jams. Check prerequisites early.

Placing the cargo landing pad

On-surface receiving hinges on the cargo landing pad. Without it, no planetary receiving window exists. As covered before, just "placing" matters less than connecting downstream flow immediately. Treat placement + outflow routing as one unit.

Per Cargo landing pad - Factorio Wiki, one-stack-at-a-time receiving is serious. Getting goods out fast is essential—delay is easy. Initially you might think "small shipments fit in any box," but small frequent shipments especially expose this bottleneck. One-stack-per-delivery with multiple item types means weak export handling chokes flow.

Positioning works best when the outflow—belt or robot—sits immediately adjacent. Handling via robot makes the 50x50-tile robot service area the natural gathering point. The failure: placing the pad in isolation, later daisy-chaining long export lines. That makes verifying arrival and spotting jams tedious.

Configuring space platform hub demand

If space-bound, the space platform hub is central. Demand issued here tells ground "what to send and how much." Start by requesting only minimum construction materials. Expanding items immediately obscures which unsatisfied request chokes flow. Manual requests tie to source planet assignment—not matching source with actual inventory creates silent undersupply.

Early focus: name this shipment explicitly ("construction launch batch"). Placeholder-ghost buildings on your platform pair well with auto-requests. Conversely, pinning exact source planets needs hand-written demand; auto-request is simpler but less controllable. The typical jam: setting demand too high, which conflicts with minimum load thresholds covered later, causing endless waiting.

Connecting ground supply

Demand alone doesn't move goods—ground-side supply to the silo matters. Minimal setup needs one reliable supply line reaching the silo, not sprawling dedicated stations. Belts or robots work; belts are more debuggable initially because you see flow.

Key insight: separate rocket parts supply from cargo supply mentally. Silo stalls differ: either "cargo is missing" or "the silo itself stalls on parts." Conflating these wastes troubleshooting time. Same error as finding cargo shortage when actually parts-production paused.

First auto-run works better with limited dedicated cargo fed to the silo, not random ground network surplus. If shipment makeup drifts each time, test results become unreadable.

Test-running small shipments and checking logs

Once wired and demand-ready, run a test small shipment—not full operation yet. What you want to verify: cargo arrives, it doesn't stall on full-load waiting, and the cargo landing pad's one-stack constraint doesn't choke output afterward.

Minimum load thresholds matter most. While official UI labeling and defaults aren't fully documented, real operation shows auto-launch holding for full load until thresholds drop—killing small shipment flow. My first attempt was exactly this: construction materials stuck waiting forever. Lowering the setting made shipments flow immediately. If you're running small-scale resupply, verifying this behavior is critical.

In logs/status, confirm this chain completes: silo gathers cargo, rocket launches, platform or landing site receives, landing pad exports. Any blockage points to bottleneck location. Cargo arriving but next shipment sluggish? Suspect insufficient pad-area export capacity.

This test phase defines success as one small cycle completes without jamming, not "arrives in bulk." Getting one cycle stable means expanding shipments later won't easily break it. Skipping cycle stability and expanding creates true visibility hell.

Design Keys: Full-Load Waiting, One-Stack Limits, Per-Planet Demand

Small-scale supply's biggest jam: "demand is set but it won't launch fast." The culprit is full-load-waiting behavior. Official docs don't give exact default values in plain language, but community observation shows "accumulates loadable material before launch" behavior; real operation stabilizes by lowering minimum load thresholds. Treat this as provisional knowledge; ideally check Factorio forums or community threads (like r/factorio, Factorio communities) for relevant discussion.

Conversely, bulk ore/construction material shipments don't want minimum thresholds too low—you'd get many small launches instead of few dense ones. Split small-resupply runs and bulk regular shipments into separate profiles for stability. Mental framework: two distinct patterns.

Small runs prioritize "arrive fast"; bulk prioritize "high per-shipment density" and "receiving capacity." Skipping this split means small items lag while bulk chokes receivers—lose-lose.

The one-stack receive limit creating bottleneck

Overlooked at the receiving end: Cargo landing pad - Factorio Wiki says only one stack accepted at a time. So even if launches work and goods arrive, if the pad-area export can't clear goods quickly, the next landing stalls.

Small runs hide this. It surfaces with bulk concentrated on one pad. I've seen silo production and launches humming, yet current location supplement felt mysteriously slow. Tracking it down, the bottleneck wasn't rocket or platform—it was the single pad's receive rate and surrounding export. Adding pads fixed it instantly. This detail carries major impact.

The error: adding pads without also strengthening surrounding flow. To raise receiving throughput, you need pad parallelization plus surrounding conveyor reinforcement. In-planet heavy transport favors trains; nearby, high/express belts; multi-item sorting favors robots. For robot receiving, fitting the 50x50-tile service zone per Logistic robot - Factorio Wiki keeps visibility clean.

Design mental model: small runs "one pad → immediate neighbor escape," bulk runs "multi-pad → multi-path distribution." Bulk especially needs pre-pad sorting buffers plus sturdy train/belt main lines downstream—otherwise pad-front clogs regardless.

Per-planet demand and shipment-source specification rules

Demand setup exposes another jam: shipment source can't be left blank. Space platform manual requests per the Space platform page assume one specified planet. So if you write one demand item assuming flexible multi-planet sourcing, it won't auto-satisfy.

Community knowledge on "space network details" helps here. Being cautious: source-planet specification isn't optional; if you want the same item from multiple planets, split demand per source planet. Example: want Nauvis-made building materials and a volume-produced duplicate from another planet? Don't write "one item demand"; write "planet A portion" and "planet B portion" separately.

Vague sourcing leaves shipments looking correct yet under-supplied. Multi-planet platforms especially hide this—"where's it supposed to arrive from?" gets buried in settings. I sidestepped this by reducing item count on small runs and simplifying source responsibility. Is it a Nauvis-from-space run or local supply? Splitting upfront aids troubleshooting.

Auto-requests work differently, accepting multi-planet flexible receiving. For precise priority control per planet, manual demand is more transparent. The supply-slowdown diagnosis also works better manually—you spot "demand quantity shortage" vs. "source assignment mismatch" clearly.

Config UI checklist

In settings, value what jam-type each setting prevents over raw numbers. This four-point check helps me dodge "small items wait while bulk floods receivers" classic disasters:

• Is this demand small-resupply or bulk regular?

Muddled roles mean unclear thresholds and pad allocation. Splitting ammo/repair supplies into small runs and building materials into bulk keeps config stable.

• Does minimum load match shipment role?

Small items stay low for frequency; bulk stays high for density. Mismatches cause waiting on small goods and pad saturation on bulk.

• Is source planet explicit?

Manual requests assume source, so vague specs become impossible to debug. Split multi-source demand into separate requests.

• Do landing pad count and surrounding transport align?

More pads mean nothing if export stays thin—lists jam downstream. Integrate train/belt/robot export planning with pad count.

Official UI term completeness in documentation has gaps, but these four points handle real-world logistics 100%. Here's the practical truth: most space logistics failures are "can't send" less often than "can send but it doesn't arrive, or arrives but doesn't flow." So in settings, look less at quantity size and more at whether full-load waiting, source assignment, and receiving capacity mesh.

Transport Mode Comparison: Belts, Trains, Robots, Rockets

In-planet steady flow

Viewing in-planet logistics as one design system: steady flow you never want to interrupt means belts lead. Items like plates or intermediate goods flowing "mine → smelt → process → assemble" map cleanly to belts. The Transport belt physics page shows basic belt speed at 1.875 tiles/second, fast belts 2x that, and express belts 3x that. Same route, just higher throughput ceilings by tier.

Belt strength is less "cheap" or "fast" than "continuous supply visibility." Jams and shortages show on the belt itself, making root-cause hunting easy. I often use belts from landing pads through initial sorting. Robot-only receiving looks clean but hides saturation points—later adjustments grow tedious.

Belts balloon in layout weight over distance. Running hundreds of tiles entirely on belts makes it hard to expand or branch. So concentrate belts on "high-volume steady sections" and shift at range.

Transport belts/Physics

wiki.factorio.com

Backbone long-distance

Long-distance ground transport heavily favors trains. At scale, this becomes starkly clear. When ore deposits distance themselves from base, belts work mechanically but correction cost and horizontal scaling balloon. Trains aggregate multiple resources via stations cleanly; scale by adding cars or routes. Rail design and signals add upfront complexity, but backbone-wise, trains dominate.

Especially for mass regular distant flow (ore, plates, building materials), trains star. Bridging space-to-ground works the same: place a staging buffer near the landing pad's station, redistribute from there. The receiving-moment smoothing buffers ripples. I often daisy-chain pad → nearby robot network → staging buffer → trains. Robots smooth one-stack landing bumps, then trains flow steadily downstream. Operations quiet down; jam spots become obvious.

Short-range flexibility

Flexibility priority over short distances → logistic robots. The 50x50-tile service area fits most layouts snugly. Robots bypass obstacles, handle complex routing, sort delicately, and shine in station frontage, malls, resupply depots, and landing-area fine-grained sorting. Convenience spikes dramatically.

But robots aren't magic. Bottleneck: charging. When demand jumps, robot charging-queue stalls before part count. Visually active but throughput drops, supply-lag grows silently. Robots work best at "complex layout, nearby, few items in quantity" spots.

Robots vs. belts/trains in one phrase: buying flexibility over volume. Crowded-but-nearby areas, complex multi-item sorting, local stocky depots love robots. Handing planetary backbone to robots means supporting massive charging infrastructure—heavy cost.

Interplanetary

Cross-planet only works via rockets. This is the defining boundary with ground logistics. Belts, trains, robots? Mighty within planets. But zero can deliver to other worlds. Ground infrastructure brilliance hits a hard stop at planetary borders—rockets become inevitable.

And interplanetary bottlenecks feel wholly different. Ground: thin links, slow belts, robot reach. Rockets: full-load waiting, payload architecture, receiving capacity. As covered, landings consume single stacks at a time; slim output easily jams despite working silo/launch.

Critical: don't view rockets as "train's long-distance cousin." Trains loop within planets, rerouting continuously. Rockets follow per-shipment design and receiving handling—both matter equally. Splitting into roles (building run, repair run, planetary resource run) with ground receiving predetermined (belt/train/robot past the pad) changes logistics from bewildering to intuitive.

Comparison summary:

Decision flowchart for mode selection

Real operation splits modes not competitively but by section. Decision logic is straightforward:

1. Target is another planet?

• Yes → Rocket
• No → continue

1. Volume continuous and heavy through same path?

• Yes → continue
• No → Logistic robots

1. Long distance, linking bases as backbone?

• Yes → Train
• No → Belt

1. Short distance but many items, lots of branching?

• Yes → Logistic robots
• No → Belt

This layout clarifies: steady-bulk = belt, long-bulk = train, short-flexible = robots, cross-world = rockets. Real design chains them: "rocket lands → robots smooth → trains backbone → belts steady-feed," mirroring how ground logistics thinks about space.

Common Failures and Fixes

Excess inventory and frequent launches

Beginners frequently set demand quantity and payload thresholds identically. Small-demand paired with high minimum load? Rockets don't launch. Then suddenly they do—massive quantity arrives, overwhelming receiving and storage. Result: "usually short, then oversupplied chaos"—worst state.

Insidious: it looks functional. Goods materialize after shortage—feels like improvement. Reality: landing waves are too jagged; downstream work destabilizes. Especially consumption-lumpy items (building materials, repair stock) suffer.

Fix: decouple demand quantity from minimum load. Ground wants X stocked; launch when Y accumulated. Add landing-area buffer to absorb shipment spikes. Once I separated them, rocket runs became actual scheduled logistics, not event delivery.

Planet-assignment blank stops delivery

Silent, time-sink jam: demand exists but goods don't arrive. Almost always: source-planet assignment is wrong. Space platform manual requests assume specific sourcing—item match alone won't cut it if planet designation points elsewhere.

I personally lost 3 hours here. Supply lines hummed, parts ready, yet zero launches. Debugging revealed: desired item sat on Nauvis, demand faced elsewhere. I had zero clue initially.

Prevention: template-ize demand setup. Building from scratch every time lets planets slip. Blueprint or template with planet name in title ("Nauvis build run," "Gleba repair run") makes recognition instant.

Small demand stuck on full-load waiting

Want little resupply; launches never happen. Small demand + bulk-profile config = classic jam. From earlier design talk, practical operation exposes this most.

Ammo, repair packs, building-material trickles collide hard with full-load waiting. Shortage time just grows. Volume is trivial; launch condition is heavy—outright gridlock. It's not rocket weakness but role confusion between shipment types.

Fix: split small and bulk profiles. Small runs: low min-load, frequent launches, sustain supply. Bulk: high min-load, fewer launches, dense payloads. Separated, troubleshooting logic isolates: stuck small run? Check small-run config alone. Bulk arrival bottleneck? Isolate bulk threads.

Landing pad saturation and arrival delays

Goods arrive; flow stalls afterward. Usually pad-area export design is thin. Pad takes one-stack-per-landing—output must be quick, or next arrivals queue. Rocket chugs along; ground receiving chokes.

Common mistake: one pad, call it done. Works for tiny runs; bulk multi-item floods it.

Advanced: Designing Supply, Construction, and Planet-Specific Shuttles

General Supply Shuttle

For mid-game stability, the first shuttle type to set up is the general supply shuttle. Its role is clear-cut: resupplying "staples" like ammo, repair packs, and construction bots to each planet or frontline outpost, topping off when inventory drops below a threshold. The goal isn't sending large quantities at once -- it's never running out.

This shuttle pairs well with the low-quantity shuttle profile mentioned earlier. Keep the minimum load low and favor small loads at high frequency over waiting for full capacity. Especially for defense lifelines like repair packs, walls, and ammo, a "replenish as soon as it drops" design causes fewer accidents than stuffing warehouses full. I used to skimp here, bundling supplies into consolidated shuttles, but the moment a frontline ran out of something, everything collapsed at once. Conversely, once I started running emergency repair shuttles with walls, turrets, ammo, and repair packs in small high-frequency loads, lines that were on the verge of collapse held together multiple times. This is quietly important.

The operational key is not overloading item variety. Supply shuttles are convenient, but piling on items blurs the line with construction shuttles and slows response. Keeping it to staples only makes it easier to trace stockout causes -- is ammo not arriving, are only repair packs stopped, or is construction bot replenishment slow?

On the receiving planet side, building around a roboport network is the smoothest approach and increases early stability. Since roboport logistics areas cover 50x50 tiles, consolidating the landing pad area as a small supply depot and distributing from there to wall repair stations or station-front warehouses works well. Trying to belt-distribute many small-quantity items gets wiring-heavy, so this type suits bots.

Construction Shuttle

Construction shuttles work better when separated from general supply. Targets are Assembling machines, inserters, power poles, Transport belts, underground belts, and splitters -- items needed in sudden bulk when construction starts. Mixing these with staples creates a mismatch in shuttle behavior. Demand spikes massively at construction start then drops to thin maintenance -- the wave pattern is large.

A two-stage approach is distinctly strong here. First, a bulk initial shipment crammed in before construction. Second, a replenishment shuttle for mid-construction consumption and follow-up work. The first shuttle delivers chunks like "one station-front module set," "one smelting block's worth," or "one defense line extension kit," then afterward only trickles back what's missing. Honestly, I had no idea at first and ran all construction materials on threshold-replenishment. But that made construction starts slow. Bots were placing ghosts while the critical Assembling machines and inserters hadn't arrived yet, causing idle waits on-site.

The constant-maintenance concept pairs well too. Setting baseline stock levels in on-site construction warehouses for Assembling machines, inserters, etc. means you don't need to organize massive initial shipments for every expansion or repair. Fill warehouses with the bulk initial shuttle, then maintain the level with replenishment shuttles.

Planet-Specific Shuttle

Planet-specific shuttles are even more role-focused than supply or construction shuttles. They run as dedicated lanes for items that are hard to make anywhere except a specific planet, or items that have outsized value when received on that planet. Fuel, ore, intermediate materials, and specialty product relays fall into this category.

The reason this type is needed is simple: to keep logistics priorities clear. Mixing supplies and specialty resources on the same request makes it hard to see which is delayed. Dedicated shuttles let you diagnose "this planet's fuel line is thin" or "only this ore relay has stopped." Especially when organizing planet-specific supply sources, dedicated runs debug better than routing through general shuttles.

On the receiving end, parallelizing landing pads becomes important. Specialty items tend to have high per-item flow rates, so consolidating on a single pad hits pad-adjacent unloading limits first. Lining up pads to distribute intake, with train stations or belt trunk lines behind for extraction, creates stability. For high-volume intra-planet movement use trains, for immediate post-pad sorting use belts, for short-range multi-item organization use bots -- roles become clear.

What to keep in mind: rather than shipping everything via space platforms, run processable work locally. Space platforms have storage and drop constraints, so rather than bouncing every intermediate product between planets, specialty shuttles work best when limited to "items with high delivery value to that planet." In my experience, designs that move even minor intermediates between planets get management-heavy later. Specialty shuttles are convenient, but precisely because they're convenient, limiting scope is the trick.

Perishable consumables and items needed in small high-frequency batches also suit planet-specific shuttles. For example, enhanced ammo variants for frontline planets or repair materials not produced locally. These could go on general supply, but if only one specific planet has high consumption, splitting into a dedicated shuttle makes inventory projections more accurate. Frontline planets often have a fundamentally different shuttle character, so not forcing uniformity here makes operations easier.

Blueprinting Units and Sharing Tips

Once shuttle designs solidify, what you Blueprint dramatically affects operational overhead. What I especially recommend Blueprinting isn't the item manifest itself but the logistics receiving unit first. Rebuilding landing pad surroundings from scratch every time causes recurring unloading shortfalls or roboport network gaps.

The go-to unit is the "landing pad + station-front roboport network module." This bundles the cargo landing pad, immediate unloading, roboports, supply chest clusters, and optionally the nearest train station into one block. Standardizing this first ensures receiving quality stays consistent whether it's a supply shuttle, construction shuttle, or planet-specific shuttle. In multiplayer this is especially effective -- when anyone can place it and get the same flow, expansion by others doesn't cause accidents.

On the space side, a "space platform request template" is also effective. Templating staple auto-requests, basic construction materials, and representative specialty shuttle items makes bootstrapping new platforms or planet routes fast. Space platform hubs have auto-request functionality that can automatically request items needed for construction, so the template should organize "what to keep in stock" and "where to manually branch off."

Community usage examples also show that templating space platform bootstraps to reduce accidents is a strong approach. Looking at Steam Community's "Space Platform Jump Start," the concept of locking down initial request organization and receiving infrastructure first is clear. In practice, these templates outperform fine-grained optimization. I've done the same with train networks -- great designs work not because of "one brilliant optimization session" but because "anyone placing them gets the same behavior."

For sharing tips, including shuttle purpose in Blueprint names aids management and ultimately improves efficiency. Labels like "Supply Shuttle Receiver," "Construction Shuttle Receiver," "Specialty Resource Shuttle Receiver" reduce placement mistakes on the planet side. Going one step further, making an independent emergency repair shuttle module for walls, turrets, ammo, and repair packs is also recommended. What frontlines need isn't a fancy base but a supply depot that spins up immediately, so cutting at this unit makes recovery genuinely fast.

Summary and Next Actions

These three facilities look different but conceptually map to supply/request/intermediate storage logistics chests. Starting from this mental model and assuming full-load waits, 1-stack receiving, and per-planet requests, shuttles are most natural when split into small/bulk/emergency categories. I also jammed everything together at first and got stuck, but just separating shuttle roles stabilized my first interplanetary supply run. Start by minimally connecting a silo and landing pad on Nauvis, create a small request on a space platform, verify the full-load wait, adjust minimum load to split shuttles, then organize the landing pad area with trains or bots. Just these four steps transform "stuck shipping" into "continuous supply."

Further expansion and detailed per-planet guides will be published on this site over time. At this point, related internal articles are not yet created, so internal links are not set. When related articles are added, insert "recommended next reads" here (editor note). This article is designed to stand alone, so follow the procedures in this guide to set up your environment first.