Satisfactory server mods: SML and Mod Manager

Satisfactory mods run on a dedicated server through SML, the Satisfactory Mod Loader, and come from ficsit.app. The practical route is the Satisfactory Mod Manager on your own PC: add the server to it over SFTP, pick a mod profile, and let it install SML and the mods into the server's FactoryGame/Mods folder with the right Linux server builds. Every player then runs the same profile. Three things decide whether it works: each mod must have a build for the server's platform, SML must match the game version exactly, and nobody updates the game until the mods are ready for it. This post covers the install, the folder layout, which mods belong where, keeping a group in sync, and what to do on patch day.

Setting up the server itself is covered in the Satisfactory dedicated server guide and the Server Manager settings in Satisfactory server settings and saves. This post is about the mods.

How Satisfactory modding fits together#

Satisfactory has no official mod support built into the game. The community built it, and it has three parts:

• SML, the Satisfactory Mod Loader, is itself installed as a mod. It loads every other mod and provides the shared systems they rely on - configuration, compatibility checks, the in-game mod list. Every modded install, client or server, needs it.
• ficsit.app is the mod repository. Each mod has a page listing its versions, its dependencies, the game versions it supports and the platforms it has been built for.
• The Satisfactory Mod Manager (SMM) is a desktop app that installs SML and mods from ficsit.app into a game install, resolves dependencies, and keeps named profiles. Its engine is also available as a command-line tool, ficsit-cli, for people who want to script installs.

The design choice that matters most: mods are compiled code, built separately for each platform. A Windows client build of a mod is not the same file as a Linux server build of the same mod. That one fact explains most failed server installs.

Server targets: the check before anything else#

Each mod version on ficsit.app lists the targets it was built for. You will typically see some combination of:

Hosted dedicated servers almost always run Linux. A mod without a LinuxServer build cannot run on them - not because something is misconfigured, but because the file the server needs does not exist. Copying the Windows client files into the server's folder does not work.

Before you plan a modded playthrough, check every mod on your list for a server target, and check its dependencies too. One required library without a Linux server build blocks every mod that depends on it. The Mod Manager does this check for you when installing to a server and refuses mods it cannot place, which is one of the best reasons to use it rather than copy files by hand.

Installing with the Mod Manager over SFTP#

SMM can manage a dedicated server's mods remotely, as long as it can reach the server's files. A local path, FTP and SFTP are supported; on a hosted server SFTP is the one you want.

1. Back up the server - the save and the whole FactoryGame/Mods folder if one exists. On RE:NODE that is a backup slot and a button.
2. Stop the server. Mods should never be installed while it runs.
3. Get the SFTP details for the server: host, port, username and password. Every RE:NODE server has SFTP with credentials of its own; SFTP and the file manager shows where they are.
4. In SMM, add the server as a remote installation using those details, and point it at the server's root folder - the one that contains FactoryGame.
5. Choose a profile - the same one you and your players will use on your clients - and let SMM apply it. It installs SML, every mod in the profile and their dependencies, using the server builds.
6. Start the server and read the log as it loads.

When SML loads it writes its own lines to the log under a LogSatisfactoryModLoader category, including the SML version and each mod it found. If a mod is missing a dependency or was built for a different game version, this is where it says so. Read it before telling the group the server is ready.

If you prefer to script it, ficsit-cli does the same job from a terminal and can target a remote installation. The commands have changed between releases, so use its built-in help for the version you have.

What the files look like on the server#

You do not need to edit anything here by hand, but knowing the layout makes troubleshooting much easier.

FactoryGame/  Mods/    SML/      SML.uplugin      Binaries/LinuxServer/      Content/Paks/LinuxServer/    SomeMod/      SomeMod.uplugin      Binaries/LinuxServer/      Content/Paks/LinuxServer/  Configs/    SomeMod.cfg  Saved/    Config/LinuxServer/    SaveGames/

Each mod is a folder named after its mod reference - the short internal name on ficsit.app, not its display name. The .uplugin file describes it; the Binaries and Paks folders hold the platform-specific builds. A mod folder with only Windows subfolders is the Windows client build, put there by mistake, and the server will ignore or fail on it.

Mod settings that use SML's configuration system are written as files in FactoryGame/Configs/, one per mod. Some mods have server-wide settings there; others store options in the save or only on the client. Edit config files with the server stopped, and keep a copy before you change one.

Which mods belong where#

Not every mod has to be on both sides. Each mod declares whether it must also be present on the other end of a connection, and broadly they fall into three groups:

Content mods are almost always required on both. The server needs them to simulate and save the new buildings; clients need them to see and use them. Client-only mods, such as interface helpers or camera tools, live on each player's PC, and the server neither knows nor cares. Some mods work with a dedicated server only in part - the ficsit.app page and the mod's own description are where authors say so.

A practical rule: put on the server only what has to be there. Every extra mod is another thing that must have a server build, must update on patch day and must be matched by every client.

Keeping every player on the same mods#

Version matching is strict. When a player joins, SML compares their mods with the server's. A missing mod, an extra required mod or a different version fails the connection, usually with a message listing what differs.

The cleanest way to keep a group in step is to treat one SMM profile as the source of truth:

1. One person builds the profile in SMM and installs it to the server.
2. They export the profile from SMM and share the file with the group.
3. Each player imports it and applies it to their own game.
4. When the list changes, repeat - and change the server and the shared profile at the same time.

Players should turn off automatic mod updates in SMM for this profile, or at least not update until the server has been. A player whose Mod Manager quietly pulled a new version of one mod at the weekend is the most common reason a working modded server stops accepting someone.

Client-only mods are fine to differ between players. Only mods required on both sides have to match.

Game updates: patch day for a modded server#

SML is built against a specific game version. When Coffee Stain releases an update, SML usually needs a new release before any mod loads, and then each mod may need its own update after that. For a large update this can take days or weeks; for a small patch it can be hours.

The routine that keeps a modded server alive:

• Do not update the server automatically. On a modded server, an update on start is an update that will stop the server loading until the mods catch up. Update deliberately.
• Back up before every update. Satisfactory saves are forward-compatible only - a save opened by a newer version cannot be opened by the older one. The backup from before the update is your only way back.
• Update in order. Game, then SML, then mods, all on the server; then the same on every client.
• Watch the log on the first start. Mods that have not been updated say so in the SML log lines.
• Expect some mods to lag. If a mod you depend on has not been updated, you either wait or remove it - and removal has the cost described above.

The experimental branch makes all of this harder. Mods are generally built for the stable release; an experimental server with mods is a server that breaks more often. Keep a modded server on the default branch unless every mod you use explicitly supports experimental. What to do when a mod update breaks has the general recovery drill.

Mods and server resources#

Mods that add buildings and recipes increase memory use, both from loading the extra content and from the bigger factories they make possible. Add 2-4 GB to the figure you would use for a vanilla factory of the same size if your list includes several content mods.

RE:NODE's Satisfactory plans run from 8 GB to 14 GB; a heavily modded late-game factory belongs near the top of that range, and the memory graph against the limit in the panel tells you when you are getting close. The same rules from Satisfactory server performance and large factories apply: more machines and more items in transit cost more, whether they come from vanilla or a mod.

Troubleshooting#

SMM refuses to install a mod to the server. It has no server build for the server's platform, or one of its dependencies does not. Check the targets on ficsit.app.

The server starts but no mods load. SML is missing or does not match the game version. Check the LogSatisfactoryModLoader lines at the start of the log.

Players are refused with a mod mismatch. Their profile differs from the server's. Re-import the shared profile and apply it.

Mods stopped loading after the server updated. SML and the mods do not support the new game version yet. Restore the pre-update backup or wait for updates.

The server crashes on load after adding a mod. Look at the end of the log for the mod named in the error, remove that one mod's folder, and try again. Never remove a content mod from a long-running save without a backup.

The save is missing buildings after a mod was removed. That is what removing a content mod does. Restore the backup from before the removal and reinstall the mod.

FAQ#

Can I install Satisfactory mods on a server without the Mod Manager?

Yes. Download the server builds from ficsit.app and upload them into FactoryGame/Mods over SFTP, with SML and every dependency. The Mod Manager does the same while checking targets and dependencies, so it is the safer route.

Do my players need the same mods as the server?

For any mod that is required on both sides - which is almost every content mod - yes, at the same version. Client-only mods can differ between players.

Why does a mod work on my PC but not on the server?

Because a client build is not a server build. The mod needs a LinuxServer target on a Linux dedicated server. If it does not have one, it cannot run there.

Can I add mods to a save we already started?

Usually, yes - adding content to an existing save is generally safe. Removing a content mod later is not. Back up before either.

Is it safe to turn on automatic updates on a modded server?

No. A game update arrives before the mods support it, and the server stops loading them. Update by hand, after SML and your mods have caught up.