[Factorio] Space Platform Design & Operation: 3 Practical Patterns

For anyone heading to space for the first time, or who can fly but keeps getting stuck because resupply never quite syncs up — this guide focuses on reproducible design steps. Space platforms don't get stronger just by being bigger. Stability comes from layering the right functions at each stage.

What Is a Factorio Space Platform? Prerequisites and Version Scope

What Space Age Adds

The space platform is the centerpiece of Space Age, and it fundamentally changes what "endgame" means. Instead of treating a rocket launch as a finishing line, you're really just opening a door. Space Age is a paid expansion released October 21, 2024, adding space platforms alongside four new planets and a reworked tech tree designed around reaching them. As noted in the Space Age - Factorio Wiki and Upcoming features - Factorio Wiki, the DLC shifts your entire approach to production and logistics from the moment your first rocket goes up.

A space platform isn't just an off-world outpost. It's simultaneously a factory and a vehicle capable of traveling between planets. Your first platform starts from a starter pack launched by rocket — just a hub and a handful of floor tiles. From there you expand: more floor, power, production gear, defenses, thrusters. Unlike ground factories, floor placement is an operational constraint, and losing the hub means losing the entire platform. That full-loss risk shapes every design decision. Floor removal behavior and costs can vary by version, so I'd recommend checking Factoriopedia or the official Wiki for specifics before making assumptions.

I spent a while treating the rocket launch as an endpoint before I adjusted my thinking. In Space Age, it's actually the entrance. Even a small platform parked in Nauvis orbit can start collecting asteroids, processing them into resources, and producing Space Science Packs. The faster you stop seeing space as "flashy endgame content" and start seeing it as a new logistics layer and a new factory layer, the less time you waste.

Space Age/ja

wiki.factorio.com

Who This Guide Is For

This page is aimed primarily at players who've reached rocket launch in vanilla and are touching space platforms for the first time in Space Age. It's pitched at beginner-to-intermediate level — specifically the stage where you've built a platform but can't keep it stable, or where ground resupply and the platform's demands refuse to line up.

The assumed version is Factorio 2.0 + Space Age DLC. That distinction matters. If you carry over vanilla assumptions about rockets and old-school Space Science, things will feel off from the start. In Space Age, the platform is your logistics hub and production base, and research is structured around planetary expansion. Beacon efficiency scaling also changed in 2.0, so the old "just stack more" instinct can lead you to the wrong design choices.

Terminology Reference

A few terms that tend to blur together — let's align on them before moving forward.

Space platform is Space Age's dedicated off-world base type. The hub is the center; you expand floor outward and load it with equipment to build a factory. Set a destination and it becomes a transport vessel. The operational feel sits somewhere between a ground base and a train — even the destination UI borrows from the timetable concept.

Platform hub is the structural core of any space platform. It handles material transfers and is the anchor point for all construction. Lose it and the entire platform is gone. Think of it as a command center and central warehouse combined — always the first thing to protect.

Platform floor is the foundation for placing equipment in space. Expanding it feels similar to landfill on the ground, but the flexibility isn't the same. Planning to carve large gaps into it later is a recipe for rework. Floor tile removal mechanics and costs can differ between versions, so check Factoriopedia before assuming anything.

Asteroid collector captures incoming asteroids around the platform. In space, these replace ore patches as your primary resource input. Feeding what you collect into the next processing stage is the backbone of space production.

Crusher converts collected asteroids into usable resources. Unlike the ground, where iron ore just flows off a belt, space adds a "collect, then crush" step. Once you internalize that, it becomes obvious why you need both collection and processing equipment on any working platform.

Space Science Pack becomes central to Space Age progression. It shares a name with the vanilla item, but in Space Age you'll increasingly think of it as a production chain running on the platform itself. Treating them as the same thing causes you to lose the thread after your first rocket.

Auto-request is the system that lets a space platform request supplies from the ground and receive them via rocket. It won't work, though, unless the ground-side rocket silo has auto-request reception enabled, the logistics network holds enough stock, and the source planet is specified. "I'm requesting stuff but rockets aren't launching" almost always traces back to one of those three conditions.

Cargo landing pad is the receiving hub for orbital deliveries. It behaves like a requester chest, but it receives only one stack at a time. When space logistics mysteriously backs up, the bottleneck is often this receive cadence rather than throughput itself.

That covers the foundational terminology. From here we'll work through the space platform as a factory in two phases: getting it running while docked, then getting it to actually deliver things somewhere.

Building the Minimum Viable Starting Platform

Launching the Starter Pack and Initial Layout

The first goal isn't a ship that can fly — it's a docked base that runs reliably. You start by launching the space platform starter pack via rocket. What arrives is just the hub and a small amount of floor. It feels less like extending your ground factory into space and more like dropping a minimal machine room into orbit.

The critical thing here is not to spread that initial floor carelessly. Floor can be expanded later, but unlike the ground, you can't just dig channels for belts and wiring on a whim. Those first few dozen tiles determine how much layout freedom you'll have going forward. My first attempt, I spread wide like a plaza and then tried to slot in collectors and crushers — the belting got twisted and I had to start over. For a minimal build, pack transfers and production close to the hub, then run collection equipment out toward the edges.

The layout logic is simple: hub at center, connect "power," "collection," "crushing," and "science production" in four zones at the shortest possible distances. Since this is a stationary platform, thrusters and heavy defenses can wait. Nauvis orbit is forgiving as a starting location — the first milestone is processing asteroids into resources and getting Space Science Packs flowing.

For construction materials, the community commonly treats rocket payload capacity as roughly 1 ton, and batching small materials around that limit helps prevent early stalls. Official numbers can vary by version and source, so confirm the current figures in Factoriopedia or the official Wiki before committing to a plan.

Setting up separate receiving right from the start pays off too. Cargo landing pads accept one stack at a time. Running everything through a single pad creates a queue: floor tiles, then batteries, then inserters, all waiting in line. That's exactly what stalled my first launch. Splitting pads by item category fixed it immediately. Even just separating construction materials from consumables makes a meaningful difference in a minimal docked setup.

カーゴ降着パッド - Factorio Wiki

wiki.factorio.com

Power: Solar Panels and Accumulators

The standard power approach for an early platform is solar panels plus accumulators for full self-sufficiency. No fuel-based generation means a lighter logistics footprint — ideal for a docked startup. Solar panels produce a maximum of 60 kW and average 42 kW during daylight, with nothing generated at night. Each accumulator stores 5 MJ and can charge or discharge at up to 300 kW. The math works just like on the ground: charge during the day, discharge at night.

Running the numbers makes the layout obvious. For roughly 500 kW sustained, around 12 solar panels at 42 kW average each gets you in the right range. Pair them with accumulators — the community-tested 25:21 ratio suggests about 10 accumulators is a good starting point for the load of a minimal platform. Note that a single accumulator can output 300 kW instantaneously, but only holds 5 MJ total — so it handles transient spikes well but isn't a long-duration reserve. Keeping "peak output" and "overnight capacity" as separate mental buckets prevents sizing mistakes.

For placement, solar panels toward the edges and accumulators near the hub makes future expansion easier. Power poles don't need the same careful routing they do on the ground, so on a platform the floor layout itself is your design quality. Reserve a row for power infrastructure early and you can extend collection or assembly lines without scrambling to add power later. Scatter them through the center and every floor expansion disrupts the spatial relationships between things.

In Nauvis orbit, where combat and propulsion demands are minimal, getting power stable early accelerates everything else. Asteroid collectors and crushers both stop the moment power fails, which closes off your resource input. Every additional solar panel here isn't insurance — it's direct production capacity.

Asteroid Collector and Crusher Loop

Once power is up, the next step is the shortest possible loop from asteroid collector to crusher. In space, you capture incoming asteroids rather than mining ore veins. Just placing a collector doesn't make a factory, and just placing a crusher doesn't either. What matters is building a single continuous flow where collected material reaches the crusher without stalling, and then moves on to the next stage.

For a minimal build, position collectors facing the platform's outer edge, then place crushers immediately inward. The reason is straightforward: every extra tile between collection and processing increases how much starter material you need to bring up. Floor can be added later, but that first ~1 ton rocket payload is finite, so shorter routing is a direct savings on launch cost.

The real failure mode here isn't insufficient processing capacity — it's no place for the output to go. Drop crushers without deciding what comes next and they'll back up within a few cycles, which backs up the collectors too. I ignored this at first and spent time wondering why my collectors were running but resources weren't accumulating. The fix is simple: plan collector → crusher → buffer or next stage as a single connected thought, not three separate placements.

On a stationary platform, you don't need perfect sorting at this stage. The goal is reaching a flow capable of producing Space Science Packs. Rather than a beautifully distributed Main bus like on the ground, priority is one loop that doesn't jam. That focus also makes expansion decisions cleaner — when you add more floor, you can scale collection and parallelize crushers, but the initial value of "one working loop" is high.

Minimal Space Science Pack Line

The first real milestone is getting Space Science Packs flowing, even slowly, on self-sustaining production. In Space Age, a docked platform can serve as a science production base, so reaching this point sets you up for every subsequent planet push. The chain is: asteroid collectors for raw input → crushers for resource conversion → smelting if needed → Assembling machines for the packs.

At this stage, eliminating breaks in the line matters more than high throughput. You're not running a mass-production facility for rapid research — a stable single material supply lane beats a cluster of Assembling machines with shaky inputs. Ground-side shortfalls in construction materials and consumables come through cargo landing pads, but that one-stack-at-a-time limit applies. Splitting item types across separate pads makes a visible difference in early stability. In my own build, running everything through one pad created a one-stack waiting queue that made science startup feel sluggish. The moment I split by item, the first production run connected cleanly.

In practice, a good spatial arrangement for this phase is: Assembling machines and output near the hub, collection and crushing toward the outer edge, power somewhere between or at the back. Ground resupply stays hub-side; space-sourced resources flow inward from the edge. You'll be tempted to fine-tune ratios here, but for an early docked build the right call is a layout where science doesn't stop, on a single line. When you later convert toward a transport vessel or dedicated resupply ship, having that minimal line as a self-contained unit makes splitting responsibilities much easier.

When Space Science Packs start coming off the line, the platform has graduated from "scaffolding dropped in orbit" to "a factory that runs." From here, you have the foundation to move toward automated resupply and hull design for actual travel.

Core Design Philosophy: Hub-Centric, Vertical Layout, Role Separation

Protecting the Hub and Building Redundancy

The first principle to lock in for space platform design is this: hub survival beats production elegance. That's the biggest difference from ground factory thinking. When the hub goes, you don't lose some equipment — you lose everything. So before deciding what goes on the perimeter or what clusters near the center, settle on how you're protecting the hub.

Three fundamentals cover it: cover, distance, and redundancy. Cover means surrounding the hub with equipment that's expendable or easily replaced — nothing that lets threats get a clear line to it. Distance means keeping high-exposure areas (collectors, crushers, ammunition handling) a bit removed from the hub, so localized damage doesn't chain through to the core. Redundancy means not building single points of failure. This isn't about placing multiple hubs — it's about not routing all of any critical function along a single path toward it.

Floor management makes or breaks this. Space platforms let you add floor, but you can't conveniently punch channels through it later. Pack the center too tightly with equipment early on, and you'll find you have no room for corridors, belts, or pipes when you need them — especially around the hub, where you most want the option to adjust. My first serious platform had the center so densely filled that supply lines and fuel routing ended up fighting each other around the hub perimeter. It looked compact; operationally it was visibly fragile.

The minimal build from the earlier section prioritized getting a thin loop running. Looking further ahead, though, not filling all four sides of the hub pays off in both safety and expandability. Leave breathing room around the hub — that's the baseline for any serious platform design.

Why Vertical Layouts Win

A wide platform looks more spacious and easier to organize. Early on, going horizontal does make it simpler to line up collectors and generators. But once you're actually operating, wide designs consistently run into trouble in three areas: speed, piping, and hull protection. My initial wide build felt logical until I flew it — and then the speed stayed flat, the pipes looped around the outside, and the hub's forward face was left thin. Rebuilding it taller fixed most of the problems at once.

The core issue is that hull width degrades propulsion efficiency and zone separation simultaneously. When using the platform as a ship, keeping thrust, production, and resupply zones distinct from each other is critical. Wide layouts blur those boundaries — "where does the forward processing zone end and the aft propulsion zone begin?" becomes unclear, and before long fuel and oxidizer pipes are crossing ammo runs, making everything harder to revise.

The bigger constraint is that nothing can be built on the south side of thrusters. That rules out extending functional zones behind the propulsion section, which means the natural structure is "equipment forward, thrust aft." So the primary expansion axis isn't left-right — it's vertical, particularly extending toward the stern.

That shape makes zone assignments clean: forward for collection, defense, and receiving; center for the hub and production; aft for fuel handling and thrusters. Each zone has a clear scope, so damage assessment and containment become predictable. Piping works the same way — running a trunk line front-to-back with pumps inserted along the way is far easier to debug than a layout that zigzags side to side. The spatial constraints described in the Upcoming features - Factorio Wiki specs align with this: platforms work better as functional bands than as open plains you fill at random.

Vertical layout also meshes with how floor expansion works. You can add floor outward, but you can't retrofit passages under existing equipment. Starting with the skeleton established — trunk down the center, branches left and right, propulsion at the rear — means each expansion fits without breaking what's already there. Going wide feels convenient and quietly eats the routing space you'll need later. That alone makes vertical the better call for long-term builds.

Upcoming features/ja

wiki.factorio.com

Designing Differently for Docked vs. Transit Use

One more thing that matters: don't design a docked platform and a traveling platform with the same set of priorities. They look identical from the outside, but what they need to do is completely different. A docked platform barely needs to think about propulsion — stability and production throughput are the whole game. That's what the Space Science setup from earlier was. Without any movement requirement, you don't need fuel piping or thruster banks, so floor goes entirely toward protecting the hub and running production loops cleanly.

A transit ship, by contrast, has to hold together through propulsion, defense, resupply, and damage tolerance — all simultaneously. The question shifts from "can I place this?" to "will this keep running while I'm flying?" A wide layout that looks fine in dock often reveals three or four weaknesses the instant you launch: thruster density too low, defense not weighted toward the bow, fuel lines too long. That transition is where I make the most mistakes — building a transport by extending a docked platform almost always leaves something critically thin.

Separating the two designs also means the margins you preserve can be different. A docked platform benefits from room to expand assembly and power. A transit ship benefits from keeping ammo routing, fluid trunk lines, and forward armor bands clear. Forcing both requirements into one hull leaves you with a mediocre version of each. In direct comparison, docked platforms are lower logistical complexity with readable failure modes; general-purpose transports and large resupply ships have more propulsion equipment and longer supply chains, which multiplies the ways things can break.

In practice, optimize the docked platform as a running factory; optimize the transit ship as a flying piece of kit. Docked builds produce science and intermediates; transit ships carry specific loads on defined routes. That division is what makes hub protection, vertical layout, and fore-aft separation all reinforce each other. One ship trying to do everything looks more efficient, but the accident rate is higher and revisions are harder.

Propulsion and Speed: Thruster Count, Hull Width, and Fuel Supply

Hull Width and the Thruster Band

When a transit platform underperforms on speed, the first place to look is the relationship between hull width and the thruster band. Space platforms are easy to build wide, so first-time designs tend to drift that way. But actual cruise performance is driven less by how many functions you've packed in and more by how cleanly you've reserved room for propulsion. My early wide builds had thrusters across the entire back row and still felt sluggish.

Part of why is that a wider hull means the thruster band also runs wider. Community experience suggests the disadvantage tends to show up around width 30+, though the exact threshold shifts with your specific design and play environment. The practical recommendation: start narrower and vertical, then test and adjust the threshold in-game if needed.

The design principle is to keep the thruster band short and dense. Rather than spreading across a wide hull, keep the hull itself narrow and concentrate the required number of thrusters at the stern as a single block. That keeps the fuel trunk line short and lets you treat propulsion as one self-contained functional zone. It pairs naturally with the vertical layout — production in the center, thrust at the rear, clearly divided.

A wide layout looks like it should carry more, but that intuition breaks down in flight. A transport ship isn't a warehouse; it's a vessel that earns its cargo capacity by first making propulsion work. Speed deficits that prevent clearing hostile zones, round-trip delays from slow transit times — these often improve by cleaning up hull width before touching weapons or production.

Fuel and Oxidizer Supply Ratios

Another commonly missed point in thruster design: the question isn't just how much fuel and oxidizer you can deliver, it's how you distribute that flow across multiple thrusters. This is where intuition and actual efficiency diverge. My first instinct was to concentrate everything into one thruster for maximum output per unit. Looking at the numbers that seems logical, but thruster thrust doesn't scale linearly with fill rate.

Per the space network mechanics, thrusters treat a maximum feed of 120/s as 200% output. The efficiency curve is steeper at lower fill rates, which means distributing a given supply across multiple thrusters yields more total thrust than concentrating it into one.

A concrete example makes this clear. One Chemical plant produces 37.5/s of fuel and oxidizer. Feed that into a single thruster: thrust sits at roughly 52%. Split the same 37.5/s evenly across two thrusters: each runs at around 29%, for a combined 58% — actually more total thrust. In many situations, distributed supply outperforms single-thruster concentration.

Given that, a practical balance for early-to-mid transit ships is roughly one Chemical plant per four thrusters. Four thrusters tolerate supply imbalance without the whole system losing speed, and you can scale incrementally. Rather than chasing theoretical maximums, staying in this range avoids the stranded-in-transit accidents caused by running out of fuel or hitting an acceleration floor. The reference docs reinforce it — "operate in the efficient band" beats "optimize for peak theoretical output."

Speed Control: Using Pumps and Circuits to Throttle

Having propulsion equipment installed isn't the same as having stable propulsion. What actually matters is flowing fuel only when needed and only in the amount needed. Running full throttle continuously burns through fuel before arrival, or blows past a destination still accelerating. Many drifting accidents aren't caused by production shortfalls — they're caused by uncontrolled flow running constantly.

The practical tool here is pump + circuit network for on/off control. Pumps can be gated by circuit conditions, so you can throttle supply based on tank levels or destination flags. For example: cut cruise pumps when fuel tank reserves fall below a threshold; enable only certain thrusters when an arrival flag is active for a braking profile. This lets you run different flow rates for acceleration, cruise, and standby.

In practice, switching between discrete output modes is more manageable than trying to continuously modulate speed. Think of it as full power, cruise, economy, and stopped — with pump routing changing per mode. Individual pump throughput goes up to 1,200 units per second, so the bottleneck is almost never pump capacity; it's the logic of when to open them. Adding control noticeably extends effective range on the same fuel production.

In speed design, chasing theoretical maximums usually produces a worse outcome. Thruster efficiency is nonlinear, so a tightly calculated approach has less margin for error. A fuel system with a modest buffer, built around distributed supply and output throttling, is far more reliable for round-trip operations. On a first interplanetary run especially, "fuel doesn't run out and the ship completes the requested round trip" is worth more than hitting top speed.

Logistics: Making Auto-Requests and Rocket Launches Actually Work

Enabling Auto-Requests and the Fill Condition

The most common resupply deadlock with space platforms is "I have requests configured but not a single rocket has launched." The cause is almost always that the auto-request is active on the platform side, but the ground-side logistics network doesn't have enough stock to satisfy the fill condition. Despite what the name implies, it doesn't send things a little at a time as they run low. Supplies only flow once the ground has accumulated enough inventory for a full launch — not before.

Getting this wrong early breaks a lot of designs. I spent the beginning treating it like a requester chest, expecting constant small replenishments. In reality, the ground needs a standing surplus buffer before any launch can trigger at all. For high-consumption, predictable items like iron plates or belts, it's workable. But construction materials, ammo, and miscellaneous maintenance supplies tend to have scattered stock that drops below the fill condition without warning.

The 宇宙ネットワーク - jp Wiki and its detailed spec confirm this: resupply only flows when both "request" and "available stock" conditions are both met. When rockets are silent, check the ground logistics network first — verify the required quantity is actually accumulated there — rather than going straight to launch settings. That's where the answer usually is.

宇宙ネットワーク (要 Space Age) - factorio@jp Wiki*

factorio@jp Wiki*

wikiwiki.jp

Small-Quantity Items and Minimum Cargo Settings

Another logistics trap: small-quantity items often don't fly on their own. Platform requests for a handful of something — fine construction components, spare equipment — may be configured correctly but still stall because of the minimum cargo threshold. Auto-request is convenient for bulk resupply; it's not well-suited to small deliveries.

What makes this sneaky is that primary materials can flow normally while small-quantity items quietly go unfilled. You notice it when you go to expand the hull or make an emergency repair: "why isn't that one thing arriving?" The automatic systems look healthy, but the actual problem is that the quantity is too small to meet the launch threshold. It's a launch condition granularity issue, not a production capacity issue.

The fix is straightforward: supplement small-quantity items either with manual launches or by using circuit logic to cut separate small-batch shipments. Rather than relying entirely on auto-request, high-volume primary materials go automatic while construction supplies and spares use a separate system. Trying to run large-volume and small-volume logistics under the same rules is asking for problems. Tightening automation conditions to be stricter often means the small items you most need in a pinch are the first things to stop.

Specifying the Source Planet and Orbital Drop Slots

Resupply also requires specifying where materials come from. Auto-requests that don't name a source planet will fail to pull from where you expect, leaving you with stock sitting on the wrong planet and nothing arriving. Once you're managing multiple planets, assuming "connected to the network means something will send it" breaks down. Source planet assignment is required, and managing requests per source is the cleaner approach.

In practice, even for the same item — say, iron — supplies you want from Planet A and supplies you want from Planet B are easier to manage as separate requests per planet. Combining them into one request blurs "which stock gets consumed," and tracking resupply paths becomes difficult. Logistics design isn't just organizing item types — defining the source responsibility boundary is just as important, and skipping that causes late-stage stalls. The same principle applies in real supply chains: any system where the origin of inputs is ambiguous will eventually jam.

On the receiving end, orbital drop slots are a useful receiving option, especially when you want to consolidate receiving infrastructure on the planet side and simplify ground intake. That said, routing everything through the same drop point creates backup at the next cargo landing pad in the chain. When the orbital settings look correct but things "ship but don't arrive," the landing pad queue is usually the actual bottleneck.

Using Cargo Landing Pads Effectively

On the ground receiving side, the one-stack-at-a-time limit of cargo landing pads is the most consequential constraint. The Cargo landing pad - official Wiki documents this behavior explicitly. When resupply feels slow, the limiting factor is often not how many rockets are landing but how fine-grained each receive action is. Piling more mixed cargo on top of that constraint makes the processing queue longer.

The specific failure mode is mixing items with different consumption rates and stack sizes into the same receiving flow. Under one-stack-per-receive rules, high-turnover ammo and rarely-used construction materials sitting in the same queue create waits. Since deliveries are actually happening, it reads as resupply running normally — but the real issue is queuing at the receive point, not insufficient shipping capacity. The misdiagnosis of "I need more rockets" is common when the answer is "I need more pads."

The practical approach is to separate pads by item category. Construction materials, ammo, bulk production inputs — split by role and the mixed-cargo stall disappears. My early instinct was to centralize receiving for a cleaner footprint, but running it that way was worse. Aesthetically tidy doesn't mean operationally effective. Having the items you can't afford to wait on get processed first, in their own queue, is what actually keeps things running.

Space platform resupply only stays working if you've connected: under what conditions rockets launch, in what sequence things land on the ground, and where they're received. The stall points aren't usually production volume — they're the joints between systems: fill conditions, minimum cargo settings, source planet assignments, and that one-stack landing pad limit. Treating each as a distinct failure mode makes diagnosis much faster.

Defense and Maintenance: Asteroid Threats, Ammo, and Realistic Repair Operations

Threat Differences Between Nauvis Orbit and Transit Routes

How much defense a space platform needs depends heavily on where it is and where it's going. In my experience, Nauvis orbit is forgiving — a small docked platform can get by with minimal interception and still run cleanly. But step into another planet's orbit or enter an interplanetary transit route and asteroid damage becomes a real operational problem. A platform that survives docked is no guarantee once you start moving. When flight begins, damage to hull, belts, or power infrastructure can cascade quickly.

Underestimating this leads to the worst early expedition disasters. A ship built tight on propulsion and logistics has almost no tolerance for losing a belt run to asteroid impact — ammo supply stops, turrets go dark, and the bow takes more damage than you can recover. My first expedition ran on "just make it there" logic. The few minutes of running undefended when ammo ran out took apart the whole forward section. After that, I stopped thinking about turret counts and started prioritizing ammo flowing even under fire and the ability to patch damage in place.

That means you can't safely take a design that works in Nauvis orbit and send it on an interplanetary run without modification. Transit ships need to be built from the start with defense equipment and repair materials included in the loadout.

Turret and Ammo Selection

For early asteroid defense, gun turrets are the reliable baseline. The reason is something the community has established through experience: asteroids have meaningful resistance to lasers, fire, and electric damage. The ground instinct of "I have spare power, so laser turrets" doesn't transfer. Energy weapons look effective but underperform on asteroids, extending exposure time without proportionally increasing throughput.

What does work is producing yellow ammo (basic ammo) onboard. The recommendation comes up repeatedly across community discussions — in space, not running out of ammo matters more than having advanced weaponry. Even a basic onboard ammo production loop dramatically improves staying power. The value in space platform defense isn't peak damage; it's being able to keep shooting as long as the belt is connected.

What finally stabilized my platform was double-routing ammo belts and adding backup ammo chests to the forward turret cluster. When one path breaks, the other keeps interception running at minimum viable capacity. "One break equals total loss" accidents dropped sharply. This is the same principle as factory design — redundant supply paths beat simply adding more guns.

Turret placement isn't just "pile them at the bow." What breaks under asteroid fire isn't only the forward armor — it's also ammo belts, power infrastructure, and collectors, the equipment that causes cascading failures if it goes down. A forward-heavy defense is the right baseline, but putting interception points beside and slightly behind critical lines means penetrations don't immediately translate into full shutdowns. "Stop everything" is harder to achieve than "stop the specific important things." Design for that.

Repair, Spare Parts, and Foundation Equipment

Repair kits are worth having but worth not over-relying on. The community consensus, framed as operational experience rather than a hard-coded mechanic, is that in-flight repair in space can't cover everything that happens. "Break it then fix it" as a philosophy runs out of headroom. Under heavy fire, repair can fall behind damage rates, and once floor, belts, and equipment start failing in sequence, resupply and interception both collapse.

That's exactly why you want spare equipment, structural components (foundations), and repair kits loaded. Spare equipment means more than just turrets and Transport belt sections — it includes power and logistics gear, because losing those stops the whole platform more reliably than losing a turret. Foundations matter specifically because a floor gap eliminates all equipment placement options in that zone. Since platforms expand through floor tiles, foundations double as emergency repair material.

My instinct was always to trim repair supplies to carry more cargo. On expedition ships, that's backwards. What actually worked was carrying a somewhat generous stock of floor tiles, spare turrets, Transport belt segments, power system spares, wiring components, and repair kits. The failure mode that costs you isn't usually the broken equipment itself — it's "there's no floor to place the replacement" or "power isn't reaching the rebuilt section." Tools alone aren't enough.

On a first expedition especially, aim to stop the bleeding and maintain the ability to navigate, not to achieve full combat repairs. Getting one turret back online, reconnecting a severed ammo run, patching a floor gap, restoring a power feed — running through that sequence quickly is what actually determines whether you recover after taking fire. Defense and maintenance aren't separate concerns; they're the same design challenge: keep the ship able to keep shooting.

Comparing Design Patterns by Use Case

Docked Type: For Space Science Production

The easiest starting point is a docked platform built without any intent to move. The mission is clear: collect asteroids, crush them, and maintain stable Space Science Pack production. No movement means no propulsion equipment needed, and defense can be kept light compared to a transit ship. The lower design complexity makes this an excellent environment for learning platform fundamentals.

The main strength is narrowly bounded failure modes. Transit ships involve fuel, ammo, propulsion, and resupply timing all interacting simultaneously. Docked builds mostly fail from construction material shortages or power deficits. Power sizing is also readable: solar panels average 42 kW each, so sustaining roughly 1 MW calls for about 24 panels. Accumulators store 5 MJ each at up to 300 kW, making them clean buffers for minor power fluctuations. I built this type first and stabilized space production before touching transport ships — that ordering made design concepts click much faster.

Layout-wise, a docked platform works even when built wide. Speed efficiency isn't a concern, so running collectors, crushers, manufacturing, and power in horizontal rows is perfectly viable. That said, if you're planning to evolve it into a transport later, starting with a vertical-leaning design extending functions aft of the hub makes renovation easier. Wide is more immediately convenient; in practice the value of "shapes that let you keep extending toward the stern" compounds over time.

General-Purpose Transport: For Early Three-Planet Operations

The most manageable first transit ship is a general-purpose transport that handles ammo, fuel, and basic cargo from a single hull. It's positioned as a step up from the docked type while staying simple enough to be an approachable "first real ship." Rather than fine-grained role separation, the goal is just completing round trips reliably.

The defining priority for this type is survivability over cargo capacity. On a first expedition, the instinct to maximize cargo space is strong, but the things that actually prevent accidents are fuel margin, continuous ammo supply, and minimal repair materials — not more hold space. General-purpose ships are vulnerable specifically because they're carrying a bit of everything, which means one thin system can bring the whole thing down. The typical failure pattern isn't overloading — it's ammo shortage and fuel shortage. Cutting corners on either means not making it there.

From a layout perspective, this is the class where vertical design becomes noticeably powerful. The reason is direct: thrusters consolidate naturally at the stern, which creates a clean division of forward defense and collection, central logistics and manufacturing, and aft fuel handling. Wide designs are easy to build but tend to bulk outward, creating speed disadvantages in a ship that actually needs to move. I defaulted to wide early on, and "placeable" versus "flyable" became very distinct concepts quickly.

Resupply compatibility is good with this type. Auto-request covers routine bulk items with minimal management overhead; manual launches handle one-off small-quantity items when needed. Early general-purpose ships carry few enough item types that circuit-controlled resupply isn't necessary to keep things running. The logistics failure modes and resupply specifics tie into the interplanetary shipping deep-dive, but at this stage the right lens is simple: "can this single ship carry everything it needs with reasonable margin?"

Large Resupply Ships and Specialist Vessels: Mid-Game and Beyond

Once operations are more established, the step up is running dedicated specialist ships with role separation. A resupply ship moves materials; an ammo ship sustains combat capability; a fuel ship keeps propulsion stable. Each ship's design goal becomes unambiguous, and the repeatability of scheduled runs improves. Compared to loading everything onto a general-purpose hull, narrowing each ship's scope makes failure diagnosis faster when something goes wrong.

The key advantage is partial failures staying partial. When ammo runs short, fuel transport isn't dragged into it. If a resupply run loads the wrong thing, the combat ship's staying power is unaffected. This is where operations genuinely stabilize — the accident rate across the whole round-trip cycle drops visibly compared to the one-ship-for-everything phase. The moment I shifted to large dedicated ships, "adding ships is simpler, not harder" finally felt true.

The cost is higher construction and design complexity. Large ships need more propulsion, more defense, and more internal logistics. The failure modes move past simple fuel depletion toward overloading and logistics complexity. Without clear answers to "how much do we process onboard versus split to another ship," the scale itself becomes the vulnerability.

At this stage role-separation layout earns its value. Wide builds are easy to place; vertical builds favor speed and expandability; but large resupply ships need both, plus functional zone boundaries on top. Forward defense and receiving, central cargo, aft propulsion, side auxiliary systems — making those divisions visible and coherent makes expansion and repair tractable. In the mid-game and beyond, the best ships aren't the biggest ones. They're the ones where you can tell what it does just by looking at it.

Common Failure Modes and How to Fix Them

Auto-Requests Aren't Triggering

When auto-requests go silent, the fastest path to an answer is checking whether the ground side actually has enough stock to meet the fill condition — before touching launch settings. The platform's resupply only flows when supply is available and accumulated, not as a reaction to need being expressed. The most common version of this failure is having stock that looks sufficient but falls just short of the fill threshold. It looks fine visually; launches never happen.

The next suspect is minimum cargo set too high for the item. If a small-quantity material is configured with a large minimum, the system perpetually decides it doesn't have enough to send. Auto-request works well for bulk items and poorly for small ones. Repair materials, floor tiles, and spare equipment — fine-grained items — tend to be stopped by this setting.

The third thing to check is whether the source planet is unspecified or pointing at the wrong logistics network. Configuring requests without specifying origin means the system may not pull from where you intend. This comes up consistently in community discussions about logistics. When I'm debugging a stalled auto-request, I work through "inventory," "minimum cargo," and "source planet" in that order — the cause is almost always in that sequence.

Running Out of Ammo or Fuel

The general-purpose transport failure pattern is usually ammo shortage or fuel depletion. Both tend to show up as gradual thinning at some point mid-trip rather than an obvious cutoff, which means watching onboard stock levels alone can leave you slow to respond. Since defense runs on continuous supply, just connecting the ammo belt isn't enough — backup supply via a second chest path provides meaningful staying power.

For ammo specifically, mixing in some onboard production makes a large difference. Relying entirely on ground-sourced ammo means one missed resupply run thins out defense across the board. Being able to top up ammo at destination or in flight absorbs the variance in resupply timing. My early logic was "shipping it all is simpler," but even partial onboard production reliably lowered incident rates.

Fuel needs the same watchfulness — not just checking tank levels but making sure the supply lane itself isn't thinning. A common failure is one of fuel or oxidizer depleting ahead of the other due to an asymmetric setup. Adding indicator lights or circuit signals on tank levels gives you a warning before full stop. Catching the warning before it becomes a slowdown — rather than noticing when the ship has already decelerated — is what separates reliable round trips from chaotic ones.

Low Speed or Width as the Cause

A slow ship is often caused not by insufficient thrusters but by too much hull width. Space platforms drift wide when you prioritize ease of placement, which produces a sluggish vessel. General-purpose transport builds especially tend to grow horizontally as you add functions — looks organized, clearly underperforms when flying.

The fix is simple: trim width and go more vertical. Keeping the flow of forward defense, central logistics, and aft propulsion intact while reducing lateral spread is often enough for a noticeable speed improvement. I rebuilt my initial wide ship by compressing the sides and extending aft, and the same ship became more manageable without touching any of the core systems.

Propulsion construction also matters here. Thruster banks should be dense and compact rather than strung out in a long thin row. Trailing piping and engines back along the hull rather than massing them near the stern creates longer fuel trunks and worse visibility into the propulsion zone. A slow ship is usually suffering from "width," "placement," and "supply routing" — not raw thrust quantity.

Over-Sending Supplies

If supplies keep arriving and piling up, the issue is almost always a mismatch between minimum cargo settings and the stock cap. Automation built around "send when below threshold" without a corresponding cap will send a large batch every time stock dips slightly. This shows up most with low-volume items — construction materials, maintenance supplies — where you only need a little but keep getting a lot.

The first fix is lowering the minimum cargo per item for anything that doesn't need to arrive in bulk. A high minimum on a low-consumption item means every delivery overshoots the actual need. Add a loose stock cap on top and launches continue even when you're already overstocked. I went through a stretch of producing unnecessary waste by applying the same settings to construction supplies and spare materials as I did to primary bulk goods.

For more precision, combining circuit conditions with launch requirements is the stronger approach. Rather than relying on quantity thresholds alone, gating launches on "stock below X" as a circuit condition prevents over-sending. The jp Wiki detailed spec supports this approach — run raw logistics broadly and use circuits to set the precise cutoff point. Resupply's harder problem isn't "getting things there" — it's "stopping at the right quantity."

宇宙ネットワークの詳細 (要 Space Age) - factorio@jp Wiki*

factorio@jp Wiki*

wikiwiki.jp

No Way to Get Back

Among all space platform incidents, arriving at the destination and being unable to return is uniquely memorable. Ammo shortages and speed problems tend to reveal themselves mid-trip. Missing return capability only surfaces after you've landed, when it's hardest to fix. Designing fuel and oxidizer for the outbound leg only makes this failure likely.

The materials you'll need aren't just fuel. A functional return requires spare fuel, oxidizer, floor tiles, and spare thruster components — enough to repair the stern if needed. Prioritizing cargo and cutting return margins is a risky trade. Once you've gotten stuck with no way back, you don't forget it. After that happened to me, I switched to always reserving a fixed loadout slot for return equipment.

The most reproducible approach is treating return supplies not as a judgment call per voyage but as permanent standard kit. Treat it as a "return package" included in the ship's base loadout. Including that reserved cargo slot in the Blueprint prevents you from having to think about it each time. Ships that can only be evaluated on the outbound leg will eventually strand you. Transport ship quality should be measured on round-trip capability, not just departure.

Next Steps: Planet-Specific Optimization, Quality, and Beacon Efficiency

Asteroid Distribution per Planet and Mining Efficiency

Sustaining mid-game and beyond means moving past "one mining ship fits every planet." Space Age differentiates asteroid distribution across planets, which changes the optimal choices for collector orientation and count, forward defense weight, and crusher line layout. The expansion's four new planets are catalogued in the Space Age/ja wiki, but in practice, memorizing the list matters less than reading what's actually flying at you on a given route and tuning from there.

The tool for this is checking the local conditions in Factoriopedia before designing a dedicated ship. Routes with heavily skewed asteroid types benefit from specializing collection targets and dedicating the crusher-and-beyond portion of the line to that type. Routes with scattered distributions can run generalist setups, though those will see more junk processing and higher ammo consumption. Harvest efficiency varies more with how well local distribution matches the downstream line than with collector count alone.

Defense follows the same logic. On dense-asteroid routes, widening the collection face to capture more increases the defended perimeter proportionally, which quickly gets hard to manage. My experience at this stage was that a narrow forward section, with collection coverage concentrated where it's needed, was more stable than trying to intercept everything across a broad surface. Wide coverage sounds stronger; it actually multiplies the places that need repair materials and ammo.

Quality and Space Platforms

Quality is powerful throughout the game, but space platforms are where it shows most clearly. The reason is direct: in space, floor area, resupply volume, and defense headroom are all perpetually constrained. Per-unit performance improvements translate directly into design compression. On the ground, you can solve problems by adding equipment; in space, transport and construction costs are intertwined, so Quality's return is more visible.

The most palpable gains come from upgrading defense equipment and mission-critical machinery. Rather than adding units, upgrading key components to maintain a smaller ship keeps resupply and maintenance cleaner. It creates breathing room in propulsion and power, and the fuel efficiency benefits compound over time. Space doesn't let you "just make it bigger" as a solution, so Quality's "more per unit" approach aligns well with how constraints actually work there.

My own approach isn't to start everything at max quality, but to prioritize quality in the order of what stops the ship if it fails. For a transit ship, that means starting with propulsion, defense, and resupply core systems. Quality as a luxury is the wrong frame; in space, it's better understood as a logistics compression tool.

Beacon Efficiency Under the New Rules

In 2.0 and Space Age, Beacon stacking doesn't optimize the way it used to. As the Upcoming features/ja page details, Beacon effects now scale on a square root curve, with the transition point at eight Beacons. Below eight, the returns feel stronger than in the old system; above nine, adding more Beacons yields diminishing returns faster.

This hits hardest where floor space is expensive — exactly the case on a space platform. Saturating a machine with Beacons now consumes floor and modules for smaller incremental gains than before. I carried over megabase habits and kept packing the outer rings with Beacons; rebuilding around the eight-Beacon transition point made a noticeable difference in both UPS and material consumption.

The practical design rule is: cap Beacon connections at around eight per machine first, then add machines if you need more throughput. On a platform, every Beacon brings along the Module inputs to fill it, additional power draw, and the floor area plus defense coverage that comes with it. Total cost — space, supply, protection — is the right unit of measurement, not theoretical maximum output.

Dedicated Resupply Ships and Role Specialization

As resupply volume grows, one ship doing everything becomes hard to manage. The high-leverage move here is building dedicated ships and assigning each a single role. An ammo ship, a fuel ship, a construction materials ship — splitting this way makes each ship's requirements and inventory management clean and distinct, and makes it obvious which ship is causing a stall when something goes wrong.

This works because different materials have different safety margins. Ammo running out causes immediate accidents. Construction materials being a bit late is often recoverable. Fuel needs both quantity and supply continuity to stay stable. Running all of these through one ship means the tightest constraint in the mix governs the whole flow. Role separation means shortfalls become visible at the ship level.

Specialist ships don't need to be large. In the mid-game, taking a general-purpose transport and deciding "this one is ammo only, this one is fuel only" produces more reliable results than trying to redesign a larger hull. The contrast to docked platforms is real — logistics complexity is higher, but scheduled operations are more stable. Once I was running multiple planets, role-separation layout made handling unexpected failures straightforwardly easier than the all-in-one era.

The more planets you're servicing, the more this pays off. Cargo landing pads receive one stack at a time, so fine-grained mixed cargo gets backed up faster as the destination count grows. Routing construction materials to a dedicated ship keeps the main ship's ammo and fuel flows unobstructed. As a mid-game development direction, the framing that works is: don't reduce the number of main transport ships — reduce what each one has to do.

Summary and Next Steps