Factorio Blueprint Book Organization Guide | 3-Classification Template

In Factorio 2.0 and Space Age, keeping blueprints in a state where you can "recall them without confusion" has a much bigger impact on on-site comfort than "creating" them. This article is for players who want to know how to divide between hand-held inventory, construction planning books, and libraries, and what ordering will let you reach the design you need in 1-2 scrolls using Shift+wheel.

Construction planning books can be consolidated into 1 slot, so just getting your frequently-used planner tools and basic category books set up first makes cross-planet operations significantly less confusing. I noticed that after unlocking robots, when I concentrated related BPs into one book, switching between them became dramatically faster. This makes me feel that establishing organization rules early is the right call.

Prerequisites for Factorio Blueprint Book Organization

Terminology alignment

To make the organization techniques below easier to follow, let's first standardize our terms. In this article, I'll use construction planning = Blueprint (the design itself), construction planning book = Blueprint book (container for multiples), and construction planning library = Blueprint library (storage shared across all saves) consistently. Even with Factorio 2.0 and Space Age, this terminology prevents confusion.

When these terms stay vague, organization tends to break down. Early on, I just lined up design blueprints in my hand-held inventory directly, and "frequently-used BP" and "BP I happen to be carrying right now" got jumbled together. Then lost items, reordering, and swapping inventory slots gradually increase the workload. It looks convenient at first, honestly, but the moment your numbers grow, the system tends to fall apart.

The weak point of hand-held inventory operation is that storage depends entirely on inventory space. If you accidentally move things elsewhere or the arrangement breaks because you assumed hand-carrying, you won't find what you need when you want it. Regarding storage in regular chests, opinions differ on the safety aspect of long-term storage. Some players worry about losing the chest itself during base renovations or accidents, so it's recommended to move completed, standard BPs to books or libraries for safekeeping (based on experience and community advice).

By contrast, construction planning books are easier to use as your organizational hub. Despite using only 1 slot, they can contain not just construction plans, but deconstruction planners, upgrade planners, and even other construction planning books. This means you can "gather frequently-used items into one book," "create mini-books by category," and "keep a shared tools book separately" – organization becomes much easier. Managing a book-centric system costs significantly less than increasing individual items in hand-held inventory.

Another crucial thing is the blueprint library. Construction plans and books saved to the library are shared across all saves. It's easy to overlook with single-save play, but once you start touching repeat or testing saves, this difference becomes substantial. You don't have to re-carry completed standard BPs every time, so stability as a storage location is completely different.

One thing to note: blueprints and books placed on the quick bar look "available," but they're not the actual items. They're shortcuts; the real objects exist in their original storage location. If you mix this up, it's easy to wrongly assume "I have this safely available in my quick bar." It's an important point to lock down before organizing.

→ Reference

For official specs, checking out "Blueprint book – Factorio Wiki" and "Blueprint – Factorio Wiki" is sufficient. You can confirm that the blueprint book is an item for storage, organization, and sharing, uses 1 slot, and can hold other books inside. The 2.0 and Space Age premises are summarized in "Upcoming features – Factorio Wiki."

From a practical standpoint, I started by lining blueprints directly in my hand-held inventory, but as they multiplied, I just spent time asking "where did it go?" and rearranging. When I switched to bundling them into books and moving completed versions to the library, management effort dropped dramatically. Rather than the organization technique itself, deciding what to keep in hand-held, what to consolidate into books, and what to fix in the library is what actually works. This detail matters more than it seems.

Blueprint book – Factorio Wiki

wiki.factorio.com

3 Storage Locations to Decide First: Hand-held · Blueprint Book · Library

Drawbacks of hand-held operation and how to commit to temporary use

The strength of hand-held operation is that you can immediately use a blueprint right after creating it. When you want to re-place a test furnace array or a temporary defense line, you can move without bothering to put it in a book first. For just the early game, this responsiveness is quite comfortable.

However, the longer you continue, the easier it becomes cluttered. Managing where you placed what becomes management itself, and "regular-use BP" and "BP I happened to be working with" blur together. I've gotten lost many times this way. Especially once you start holding multiple outposts, mining blueprints, defense blueprints, railroad blueprints, and renovation planners accumulate in hand-held, making it impossible to pull out everything you need in a single go. Space Age makes this weakness even more apparent. Once planetary movement is involved, hand-held-focused operation suddenly becomes awkward. While normally convenient, the moment movement crosses planets, "where did I put this blueprint?" tends to happen easily. Better to treat hand-held as a temporary staging area for just-created items or a one-off workspace – this prevents breakdown.

A good rule of thumb is not to carry completed items around permanently. Move things you'll reuse into books; send standard items used across saves to the library. Just making this distinction can prevent organizational collapse significantly.

Strengths of book operation and how to set up your first book

The maximum advantage of a construction planning book is consolidating contents into 1 slot. Moreover, you can fit not just construction plans, but deconstruction planners, upgrade planners, and even other construction planning books inside. In everyday operation, this "ability to bring things into one book" is genuinely powerful. Searching narrows down from many single items to a single location.

Book operation is also easy to handle operationally. Active blueprints can be cycled through with Shift+mouse wheel, so if you keep frequently-used items nearby, you're quite fast in real play. Even with nested books, you can trace through them sequentially, making separate mini-books "shared tools book," "logistics book," "smelting book" easier to navigate than stuffing everything into one book.

Your first book succeeds best if you lock in what you use every time before crafting a detailed classification. I'd start with deconstruction planner, upgrade planner, electric poles, furnace rows, belt replenishment, and a short standard defense line. Basically, items you'd "always touch if confused" go at the front. Rather than building elaborate classifications from the start, fitting by usage frequency works better and doesn't collapse in real play.

Player approach compatibility can be roughly organized in the table below.

Looking at this table, it's clear that the operational center should be in books. Temporary hand-held placement, book for field use, library as asset storage – this role division makes organization quite stable.

Library operation: Sharing across saves and basic labeling

The value of library operation is that you can share across all saves. You don't have to re-carry standard blueprints each time, so it works best for people doing repeat plays, testing saves, or jumping between multi-outpost different saves. As a place to store completed shared assets, it's far more stable than hand-held or single-save storage.

In practice, placing commonly-used books in "My Blueprints" is the most straightforward approach. The community has firmly settled on opening the library with 'B' key to manage it. Since I started playing multiple saves, I switched to keeping a "shared planner book" permanently in the library. With this, that "I might have lost it" anxiety almost disappears. Small detail, but that peace of mind is quite big.

The library, convenient as it is, tends to bloat if left unchecked. Labeling helps here. You don't need rigid naming conventions – just dividing into "shared," "by planet," "prototype," "external imports" to that granularity drops search burden considerably. For Space Age-focused operations, separating shared tool groups into one book and planet-specific production/outpost designs into separate books works especially well.

Using the library as your storage location and books as portable field kits works increasingly better with longer save playtimes. Space Age tends to have longer play sessions and expanding outposts and planets, making it increasingly valuable to move finished items to the library.

Chest storage and the quick bar trap

Storing blueprints or books in regular chests for long-term storage has pros and cons. In practice, there's concern about loss during base renovations or accidents, and moving standard BPs to books or libraries for safekeeping is more secure. Including the point that the quick bar is a shortcut, not the actual item, prioritizing book or library storage is recommended (community advice/experience).

The quick bar is also an easy point to misunderstand. It looks like "the book is placed there," but it's just a shortcut, not the actual item. The real object is in its original storage location. In other words, arranging things on the quick bar doesn't constitute organization or storage itself. If you miss this understanding, you fall into thinking "it's on the quick bar so it won't disappear" – and management breaks down.

Mixing these up easily leads to keeping the actual item in a chest and seeing only the quick bar, feeling safe – honestly, this is the most dangerous scenario. Move storage toward books or libraries, treat chests as temporary fallback, and use the quick bar as an operation shortcut. Making this distinction creates a far more stable organizational foundation.

Recommended classification templates

Classification is less about "finding the right answer" and more about organizing things so you don't get lost on the job. Early on, I created just one book and threw everything in it, but as numbers grew, the step count to reaching what I wanted subtly increased. Especially after Space Age, outposts and roles scatter easily, so deciding reuse axis in advance prevents breakdown.

Looking at three commonly-used patterns first makes organization easier.

Of these, by-function is easiest to recommend to beginners. The reason is simple: you search by "what you want to do." Belt laying? Logistics. Furnace placement? Smelting. Power increase? Power – the mapping is intuitive. It's also easy to later migrate to by-stage or by-planet organization, making it a good foundational classification approach.

Template A: By-function

By-function is the most stable classification for everyday play. Category names immediately suggest contents, and external imports are easy to sort. Community distributions also often bundle by function – oil processing, main bus, power plant, rail station, mining station – making self-created and imported items mixable without collapse. That's a major strength.

Start by not getting greedy with expansion. I'd begin with this lineup.

• Shared planners
• Logistics
• Smelting
• Production
• Power
• Rail

From here, add defense or petrochemistry if needed. Six or so books is a good starting point – it's easy to mentally remember placements and "where did I put it?" becomes less likely. Starting with over 10 categories tends to feel organized while actually slowing searches, so be careful.

Settling contents in advance prevents hesitation. Something like this works well:

Shared planners get deconstruction planner, upgrade planner, electric poles, lamps, walkways, and basic roboport placement. Include items you touch at every outpost up front.

Logistics gets straight belts, branches, underground + crossing variants, simple balancers, transfer ports, and main bus base units. Logistics especially sees high frequency, so separating short standards from large structures helps visibility.

Smelting groups stone furnace arrays, electric furnace arrays, ore intake, and plate compression output. Separating early-game and post-electrification versions makes transitions easier.

Production contains gear, circuit, research pack, and module component assembly lines. This category multiplies easily, so "intermediate materials," "research," "late-game parts" sub-sorting helps.

Power houses boiler steam, solar, batteries, and basic nuclear units. Power needs rapid expansion frequently, so ordering by launch priority helps in real play.

Rail contains single-track, double-track, T-junction, crossing, siding, loading station, unloading station, and stacker designs. Train networks suddenly bulk this up alone, making later nested-book conversion compatible.

Template B: By-stage

By-stage helps a lot when there's much to remember. Organizing as early/mid/late keeps you seeing only what's usable with current technology. It especially works well with designs that change generation by generation – like oil processing split by stage in some distributions.

This classification suits the stage where "what can I use now" takes priority over "what goes where." The concept is switching furnaces and belts each tech generation, so for learning, it's quite straightforward.

Sample contents would be:

Early game contains stone furnace arrays, red/green research small setups, steam power, simple defense with ammunition belt, and main bus entrance that doesn't cause bottlenecks. Light materials, quick placement.

Mid game gets electric furnace arrays, developed oil processing, blue science surroundings, mid-scale circuit production, and basic rail stations. Furnace and power rewrites increase here, so swap-ready designs help.

Late game has beacon-dependent mass-production lines, large-scale power, stacker-equipped stations, module production, and end-game research lines. Ingredient demands and prerequisite research are heavy, so late-game books become more "storage to use after completion" than active.

However, by-stage tends to duplicate mid-game onward. For instance, smelting alone has early furnace array, mid electric furnace array, and late high-density variants – similar-purpose designs in parallel. Once experienced, "I want to choose within smelting" feeling strengthens, making long-term operation drift toward by-function. I started this way but eventually absorbed it into by-function.

Template C: By-planet/outpost

By-planet/outpost works especially well with Space Age. Once multi-planet or remote outposts start, the same "production" shifts in required equipment and placement constraints. Then "where will it be used" becomes faster to sort than function.

Key to this method: separating shared tools from location-specific designs. Since blueprint books nest, a "shared book" for tools and "planet book" for specifics separates cleanly. The "Blueprint book – Factorio Wiki" confirms that you can nest books within books.

Sample contents might look like:

Shared book houses deconstruction, upgrade, poles, robot network, paving, generic transfer ports, and generic defense lines. Center things you touch everywhere here.

Planet A book gathers frequently-used mining, smelting, power, and production standards for that planet. If the terrain and transport conditions suggest specialized station designs, they fit naturally in this book.

Outpost B book collects location-specific designs. Like mining outpost bundles, defense wall lines, supply stations, turret groups – things used "only at this site."

This method feels overly detailed for vanilla early game. However, once Space Age planet-movement starts, value appears immediately. Hand-held scatter before meant "my standard station is missing" or "my shared deconstruction isn't here now" happened often, but dividing shared and planet books cut those confusions significantly.

Nested book usage and naming conventions

Nested books feel most natural when you want category mini-books. Consolidating into one book is convenient, but practically, scroll volume and search time both rise. Single-book large capacity versus bundled category books – the latter achieves better search/management balance.

I separated into a 'Rail' mini-book when strengthening train networks. Intersections, stations, stackers, and fine signal-tuning patterns expanded so much that mixing with other categories slowed switching. Separating it made "open book → enter rail → pull desired station" flow quite natural – operationally, maybe one action shorter in feel. That small difference matters on items you place repeatedly.

Nested cut points happen when sub-bundles form meaningful clusters. Like rail into "track," "intersection," "station," "stacker," logistics into "base parts," "balancer," "transfer," production into "intermediate," "research," "late parts." Conversely, making separate books for categories holding only 2-3 items increases hand-opening cost instead.

Naming conventions don't have official standards, but practically, names where purpose shows first are strong. Just keeping them short and consistent changes list clarity dramatically. Something like:

• Shared_planner
• Logistics_base
• Smelting_early-mid
• Production_circuit
• Power_nuclear
• Rail_station
• Rail_intersection
• PlanetA_production
• Outpost_defense

Externally-sourced blueprints keep better when you add purpose, source, and version to the name – original gets lost when modified versions mix. Being able to tell "what this design does," "if it's self-made or imported," and "where to find the original" from the name alone is ideal.

For beginners, creating a by-function parent book, then nested mini-books only for needed categories, handles well. For instance, keeping "shared planner," "logistics," "smelting," "production," "power," "rail" at first-level, with only rail and production subdividing. This way, still-small categories grow naturally into that structure later.

JR West Japan Railway Company: Top Page

JR West Japan Railway Company's official site. Information on safety initiatives and service information, corporate and recruitment information, travel by rail, and lifestyle/living information. Rich content for railway enthusiasts.

www.westjr.co.jp

Designing order with Shift+mouse wheel in mind

"1st-string/2nd-string/archive" ordering template and examples

This looks minor but works significantly. Since active BP switching assumes Shift+wheel, putting frequently-used items at the front drops confusion dramatically. The "Blueprint book – Factorio Wiki" already notes books as organized-use tools – fitting unlimited contents makes arrangement method more practically important than the capacity.

I think of arrangement by sorting contents into "1st-string," "2nd-string," "archive" – intuitively, "use often → use sometimes → keep for history." 1st-string is designs you instinctively call during work; 2nd-string, items sometimes needed but not routine; archive, old versions you don't want deleted and special-case storage. This structure keeps front-side handling stable even as books grow.

Especially 1st-string should fit in the first few entries per mini-book (experience-based). Keep the front end lightweight with frequent → occasional → archive ordering, and Shift+wheel cycling stays fast.

In a defense book, I once ordered as [turret array][ammo belt][wall line] consecutively. That worked great – even mid-expansion fighting, "where is it?" didn't happen. Honestly, since combat's my favorite, I feel this difference strongly. During busy combat, ordering directly affects hand speed. Just having the main three defense items at the front kept replacement and repair tempo smooth.

Conversely, leaving archive items near the front makes reaching main-use BPs feel distant. Old improved-before layouts, terrain-specific variants, work-in-progress tweaks, unevaluated external imports shouldn't sit in instant-reach placement – confusion multiplies otherwise. Keeping matters, but you needn't place them where you can easily access them.

Nested-book cross-traversal scroll behavior and placement tips

With nested books, arranging for continuous scanning sensation is the secret. Rather than parent and child books as completely separate, thinking "as I Shift+wheel through, when do I touch my target?" works better in practice. Ignoring this makes categories neat while lookups slow – a book that looks organized but pulls slowly.

With this in mind, put 1st-string categories early in the parent book. Like shared planner, defense, logistics front-positioned, often-touched mini-books come first. And within each mini-book, put 1st-string up front again. So both book entrance and interior entrance lock 1st-string. Then the flow from entering parent book to your target doesn't break.

Placement feel treats parent as macro-sort, child as immediate-standard pull. Like defense sub-book opening with [turret array][ammo belt][wall line][repair pole][front-line cannon support] – you can trace the exact sequence needed for defense expansion. Really doing this feels great. When needed order and scroll order align, searching becomes more workflow.

What to avoid: placing rarely-touched mini-books at parent front. Like [old archive][experimental][late-game only] at entry means passing through every time. Nested books excel organizationally but punish poor entrance design – scroll overhead stacks. Mini-booking just for organizing doesn't unlock real value; deciding which books come first does. That's when nested books shine.

Preventing over-scrolling targets and stock-taking timing

Over-scrolling usually shows as the trouble surface: frequent scrolling to reach regular designs. When your 1st-string doesn't reach the front anymore, suspect ordering before classification. Books fit unlimited items, so they get easier to clutter than clean.

Signs to organize: when regular designs don't stay front-near every cycle. Especially when 1st-string items fall off the front – yellow flag (experience). When this shows, consider archive retirement or sub-division.

Timing stock-takes with game progress feels natural. Post-defense update, post-rail standard unification, post-planet-operation settlement – old BPs suddenly batch-retire to archive. Cleaning up 1st/2nd during these windows gets operations noticeably lighter. Mid-task fussy organizing stops progress, though, so bundled replacement per milestone works better than constant tweaks.

Preventing over-scrolling: moving before deleting matters. Designs maybe-future-used go to archive, not deletion. Meanwhile, keep 1st/2nd entry always light. This prevents "want to keep" fighting "need instant access." Blueprints naturally grow, so organizing aims at keeping front fast, not reduction. That framing makes design easier.

Organization rules especially effective in Space Age

Multi-planet movement possession issues and retreat operation

What subtly works in Space Age: not carrying blueprints and various planners casually as everyday items. Vanilla-brain holding deconstruction and upgrade planners scattered in hand-held suddenly becomes tedious across planetary moves. Landing somewhere and "I don't have that deconstruction condition variant" or "I left my upgrade setup behind" happens. Early on, I prioritized hand-held convenience and ended up forgetting my toolkit every move – it was rough.

What works: retiring frequently-used planners to books or blueprint libraries as baseline, then calling them from there. Hand-held = temporary work-space; standard forms = call from retreat location. This role split keeps operations stable even across planet-jumps. Since books can bundle deconstruction and upgrade planners too, items you touch most belong in books rather than hand-held for stability.

This applies before knowing Space Age details deeply. While Space Age is treated alongside Quality and Elevated Rails as major components, what matters is the premise of reusing tools across multiple locations strengthens. One outpost differs from multi-place-reuse-ready premise – "identical setup callable instantly everywhere" value rises considerably.

Practically, recreating planner setups on-site costs more than calling saved shared sets. Especially deconstruction conditions and upgrade targets show your habits directly, so recreating each time drifts slightly. Those drifts pile up, slowly breaking managed operations. Early setup → retirement workflow is faster.

Shared planner book contents and naming conventions

What I highly recommend: bundling deconstruction and upgrade planners into one "shared planner book" operation. Of course this isn't an official template name – just what I call it – but it's genuinely practical. Fixed naming, fixed internal order. Just that stabilizes operations across planets.

Contents can be simple. Basically, routine deconstruction planner, condition-varied deconstruction planner, routine upgrade planner, purpose-varied upgrade planner consolidation. What matters isn't impressiveness but identical-position identical-tool presence. Per the earlier ordering section, planner stuff particularly benefits from "it's where I remembered it," stopping hands from freezing.

Naming works best unadorned. Community-wide unified naming rules don't appear, but practically, post-import, showing what it does, its source, and version matters. I prioritize purpose reading clearly at first glance. Like "deconstruction_standard," "deconstruction_pole-preserve," "upgrade_standard" – clear effect-leading names let field work flow. Fancy abbreviations or random names become unreadable over time.

This single book works better focused-small than expanded-capacious. Isolating just planners makes front-placement easy and instant-opening natural – worth front-loading over logistics or defense actually. Shared planner house everyday tools everywhere; production BPs swap location, but planners sync all spots.

Multi-planet, multi-save "shared asset" management

Where Space Age differs from vanilla in clear asset-handling: organizing for multi-save seeing, not single-save viewing. Expanding planets splits "bring-everywhere items" from "location-specific designs" sharply. Add multi-save play, that gap grows bigger. Here, flattening production layouts to universal-shared becomes strained, but planner classes and foundational tools suit shared-asset handling well.

Conceptually, splitting shared-tool groups from location-BP organizes most clearly. Keep shared-tools in library or routine-book, planet-specific production/placement in separate books. This way "time finding universal items" nearly vanishes. We Love Factorio covers planet-specific design running and movement-span handling, and touching it confirms the value. Pre-loading shared assets beats current-site improvisation – stability is dramatically different.

Especially with Space Age's core components Space Age, Quality, and Elevated Rails bundled, design targets scatter naturally. Therefore not cramming everything into one book, instead isolating "tools wearing same face across every save" gains value. Personally, with this solid, moving locations doesn't break operation base. Train or defense – wherever base tools stay fixed, judgment quickens.

Long-run save expansion: this "shared assets" architecture gradually hits harder. Expanded mods set longer expected playtimes, and real play runs extended. Long hours shift shared-tools-first-arrangement value noticeably upward.

Common failures and avoidance

"3 mines" – direct placement, single-book stuffing, unmarked imports

Where organizing fails shows as patterns; honestly, three situations are most dangerous to see: keeping finished BP directly in inventory permanently, craming everything into one giant book, holding external BPs unnamed. These look minor but pile on impact later.

Most problematic: keeping completed blueprints permanent in hand-held. Post-creation use feels convenient, but permanent residency mixes "active shortcut" with "long-term stored asset." Earlier sections noted Space Age brings carrying-difficulty, so moving finished designs to books or libraries early works better. Quick bar stores shortcuts not storage location – cutting that confusion stabilizes management.

Next: single giant-book operations. Blueprint books fit unlimited content, so starting feels easy. Practically though, "fits" differs from "findable." Stuffing logistics, smelting, defense, rail, planet splits, plus test versions into one mega-book makes reaching needed sheets distant. I did this once and fully hit scroll-hell. Rebuilding overnight with naming rules + mini-book splits, operations instantly smoother. Just splitting into "defense book," "rail book," "planet book" drops search burden significantly.

Third: working with unmarked external imports. Community-shared stuff looks good working but loses what purpose, which version, whose creation after import – later you're stuck. Name blanks like "oil," "smelter," "good rail" hide information. Worse is saving maker-unknowns; wanting update-versions later or reviewing logic becomes impossible without original pages/credits – "what was this?" stops work. Names around external sources are lowest-hanging time-saver.

Old-version mixing in current environment is risky. Factorio 2.0 and Space Age (released 2024-10-21) make version-ignorant operation harder than before. Space Age wraps Space Age, Quality, Elevated Rails as core-mods, so mixing old-design BP without markers means finding and repairing both stall. Not knowing if it works or needs fixing from the name is most painful. Using things takes less time than judgment-delay.

Naming convention template: "Purpose_Scale_vX.Y_Source"

Official unified conventions don't exist, but fixing your personal rules stabilizes management. What I find workable is "Purpose_Scale_vX.Y_Source" form. Not official – just a template making review-later essential info front-readable.

Examples: defense context gets "wall-line_long_v2.0_self-made," external gets "oil-processing_medium_v2.0_FactorioPrints-author-name." Priority is name-reading showing purpose, version-difference, source-traceability – appearance takes backseat. Putting external BP through your naming rulesets before re-storing helps downstream massively. Multis especially – recipients read names before contents, so "purpose and version readability" from title shifts usability strongly.

Storing source-unknowns also dodges through this: importing → save strings separately as URL+date notes. Then "which site found-it" and "how-current" tracks. Later finding same-BP's updated version or splitting broke-reason by version becomes possible. String-only saving then leaves you searching with unknown history – saving as asset but not using it, frustratingly often.

Scale notation: doesn't need rigid precision. "Small," "medium," "long," "early-stage" suffices. Critical: consistent per-time naming. Today "medium," tomorrow "mid," another day blank – that's breakdown-fastest. Rules in names let search-by-sight narrow candidates, speeding field-work rhythm. Precise searching beats fussy definition-matching.

Version-mixed isolation operations

As external BP grows, unavoidable version-mixing happens. Better than forcing compatibility: isolating matching and mismatched versions up-front handles cleaner. I prefix remarks with "2.0-compatible," "Space Age-compatible," "old-version-check-needed," then push non-matching into archive sub-book. That's my most stable approach.

Key: not deleting mismatched BP – moving it off active shelves. Old defense, vintage smelting, legacy-version stations hold reference value. Keep them – just remove from working stock. "1st/2nd/archive" ordering