Copy reusable blueprints into the dedicated server's active session directory, then reload and test them in the game. Uploading the factory's .sav file is not the same operation: the world can contain buildings placed from a blueprint while the reusable design files are missing.
This covers PC dedicated servers and file-based blueprint transfer. Console storage differs. You need the server owner's permission, access to its persistent files, and a compatible game/mod environment.
Distinguish a design from the factory save#
A reusable module is a .sbp file. Its optional matching .sbpcfg stores metadata such as description and icon information. Keep the pair together when supplied, but do not reject a shared module solely because its optional config is absent.
The maintained blueprint format documentation distinguishes module data from its config and records version-dependent fields. Renaming a world .sav to .sbp or changing a filename extension does not convert its contents.
Preserve both the world and separate blueprint library. A world upload alone does not preserve the reusable designs.
Find the server account and the actual session folder#
The server's files belong to the machine and account running the dedicated process. A copy in the player's profile does not establish server access.
The dedicated-server blueprint path reference gives these typical direct-install locations:
| Platform | Session blueprint directory |
|---|---|
| Linux | ~/.config/Epic/FactoryGame/Saved/SaveGames/blueprints/{SESSION NAME} |
| Windows user account | %LOCALAPPDATA%\FactoryGame\Saved\SaveGames\blueprints\{SESSION NAME} |
Resolve ~ or %LOCALAPPDATA% using the server process account. Windows services can use a service profile. In a container, trace the persistent mount and wrapper documentation instead of copying into the disposable image layer. For example, the robtme community container keeps persistent game data under its mounted /config structure; that is not a universal path for other images.
Use the active session name, not an autosave filename or the server's display name. To identify the directory, save a small, harmless blueprint in that session with a distinctive name such as TransferProbe. The game must have blueprints unlocked. Locate the files it actually created and record the path. A maintainer explanation of session folders recommends this method; it avoids guessing capitalization, punctuation, or which old folder is active.
Prepare a small import with no silent overwrite#
Record the source game's build and any mods required by the design. Ask the creator about dependencies rather than assuming a vanilla-looking layout contains only vanilla objects. Match supported server/client mod requirements before testing. A blueprint saved by a newer game or a different mod version is not guaranteed to work in an older environment.
Start with one design. Inventory its filenames and sizes and back up any destination files with the same names. Keep the module and supplied config names paired. Do not silently replace an existing design.
Create a completed world checkpoint, stop the server through its normal manager, and copy the library to an independent backup. Then transfer the chosen module and optional config directly into the verified session directory. Avoid an extra archive-extraction subfolder. Ensure the game process can read the copied files and can write new designs in that directory; do not broadly change permissions on a shared parent directory.
Check the deployment's startup update policy before restarting so this import does not also change the game build. Start the same instance and session, wait for loading, and reconnect. A controlled reload is part of the file-transfer procedure; do not assume files copied during play will appear immediately.
Verify the design beyond its menu entry#
Find the imported module in the blueprint menu, including uncategorized entries if necessary. Categories and subcategories are stored in the world save, so the standalone module/config pair does not carry the source session's category organization. Use the current game's category controls after confirming the design itself exists.
Place it in a safe test area with the required materials and appropriate progression. Check its intended buildings, recipes, connections, and mod-dependent parts. Ask another connected player to inspect the same placement. Complete a save, reload in a controlled window, and check both the library entry and the placed result again.
These checks separate three failures: a missing menu entry suggests a directory, reload, or loading problem; a visible design that will not place needs its specific in-game message and requirements checked; a placed result seen differently by clients needs a multiplayer investigation. Recopying the same file does not diagnose all three.
Coffee Stain's 1.2.4.0 notes include fixes for blueprint categories and invalid session-name characters. Compare the exact build and symptom before treating a failure as a known game bug. Do not rename the live session or strip mods from its only save as a speculative repair.
Back up a recoverable combination#
Keep the world checkpoint, entire session blueprint directory, build/mod inventory, and persistence mapping together in the backup record. Retain copies outside the server host. Test restoration into a separate directory and instance before replacing the live library.
If an import fails, stop the affected instance, retain the failed files for diagnosis, and restore only the backed-up library files you intended to replace. Restore the world checkpoint too only if gameplay changes require an agreed rollback; identify the progress that would be lost.
For administration of your own infrastructure, Nexardo's product overview describes a central management approach. A useful backup procedure still needs to identify the separate world and blueprint data for the actual running instance.
