# Satisfactory Server Hosting - everything RE:NODE has published > A Satisfactory server on RE:NODE: plans, how the panel runs it, and every tutorial RE:NODE has published about it. Generated from https://www.renode.space/game-servers/satisfactory, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers/satisfactory. Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant. ## What it is Satisfactory dedicated servers with room for a factory that keeps growing. - Genres: Adventure, Indie, Simulation, Strategy - Developer: Coffee Stain Studios - Released: 10 Sep, 2024 - Steam: https://store.steampowered.com/app/526870/ ### What comes with every Satisfactory server - Configured before you see it: The install runs, the configuration is written and the server starts. No first-boot checklist, and nothing left on a default password shared with every other Satisfactory server on the internet. - The real console: Live output, command input and the server's own logs - not a filtered summary. Web-server noise is folded behind a counter you can switch off. - Files and SFTP: A full file manager with an editor, plus SFTP credentials. Upload mods, edit configs, pull a world down to your machine. - 2-2 backup slots: Taken on demand or on a schedule, restored with a button. Deleting a server takes its backups with it, on purpose. - 2 ports allocated: Add and remove ports yourself from the Network tab, including the query and RCON ports where the game wants them. - People on the same server: Invite friends or staff with granular permissions - console only, files only, no billing - through subusers, roles and teams. ### Which Satisfactory plan do you need? Memory is what decides whether a server holds together, so start there. The Standard tier gives 8 GB and 2.5 vCPU, which suits a private group. The Pro tier at 12 GB is where most public servers sit, and Premium at 14 GB exists for the servers that stay full. Storage matters more than people expect once mods and backups are involved - plans here run from 40 GB to 80 GB of NVMe. Moving up or down a tier later does not rebuild your world; it changes the limits on the container you already have. If you are not sure, take the middle tier. It is cheaper to move up after a busy weekend than to spend one explaining lag to your players. More game servers: https://www.renode.space/ai/game-servers.md ### General questions ### Getting started **How quickly is my server ready?** Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours. **Do I need to configure anything before it works?** No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards. **Which games need a key from me?** Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in. **Can I try before buying?** There is no free tier. The entry plans start at $1.50 a month precisely so that trying something costs about as much as a coffee. **Can Claude or ChatGPT set my project up?** Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all. ### Running the server **Do I get full file access?** Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only. **Can I install mods and plugins?** Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run. **Can other people help me run it?** Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere. **What happens if my server runs out of memory?** New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops. **Is the CPU limit a hard limit?** Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it. ### Backups and safety **Are backups included?** Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket. **Where are backups stored?** Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing. **What happens to my backups if I cancel?** Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you. ### Billing **How do I pay?** PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid. **Can I pay in Georgian lari?** The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount. **What happens when my subscription is due?** An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one. **Can I upgrade or downgrade later?** Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are. **Do you offer refunds?** There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy. ### Support and the honest bits **How do I get help?** Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions. **Where are the servers?** Germany, on hardware we run. That is one location: if you need players in another region on a low ping, say so before buying rather than after. **Is there an uptime guarantee?** We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first. **Who actually runs this?** A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter. ## Plans and prices Read from the live catalogue at 2026-10-15 02:50 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers/satisfactory or in the panel shop at https://panel.renode.space before quoting one. | Plan | Price / month | Memory | CPU | NVMe disk | Databases | Backups | Ports | |---|---|---|---|---|---|---|---| | Standard | $21 | 8 GB | 2.5 vCPU | 40 GB | 1 | 2 | 2 | | Advanced | $27 | 10 GB | 3 vCPU | 50 GB | 1 | 2 | 2 | | Pro | $33 | 12 GB | 3.5 vCPU | 60 GB | 1 | 2 | 2 | | Premium | $40 | 14 GB | 3.5 vCPU | 80 GB | 1 | 2 | 2 | ## Panel how-to From the panel guides at https://www.renode.space/guides. ### Ordering a server Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console. - Takes: About a minute - Pay with: Card, PayPal or bank transfer - Billed for: 1, 3, 6, 12 or 24 months - Prices in: US dollars or Georgian lari Open the shop and find what you want to run: 1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases. 2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer. Compare the plans and pick one: 3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access. 4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world. Choose how long, then pay: 5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises. 6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes. Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day. 1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button. 2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it. After you pay: - The server appears under My Servers and installs itself. Open it to watch the install in the console. - Your orders, invoices and subscriptions are under Finances in the side menu. - Stuck at any step? Open Support in the side menu and raise a ticket. ### The console Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it. - Start, stop, restart and kill, with the current state always visible. - Command history with the arrow keys, and tab completion for common commands. - Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints. - Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable. ### Files and SFTP A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine. - Drag files in, or upload a folder. Archives can be unpacked in place. - Edit any text file with syntax highlighting and save without downloading it. - PDFs and images preview in the panel rather than downloading first. - SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode. ### Backups Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away. - Slots on every plan - two on the entry tiers, more further up. - Take one on demand, or on a schedule you set. - Download any backup to your own machine. > Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel. ### Subusers, roles and teams Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately. - A role holds permissions - what may be done. - A team holds people. - A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once. - Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people. - Access can be time-boxed, and expiry stops working immediately rather than overnight. ### Scheduled tasks Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action. - Send a console command - a warning to players, a save, a world flush. - Take a backup. - Power actions: start, stop, restart. ### Games that need a key from you A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers. > Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation. ## Tutorials 4 posts, newest first. Each one follows in full after the list. - [Satisfactory server mods: SML and Mod Manager](https://www.renode.space/blog/satisfactory-mods-ficsit-server) (2026-10-07): Install Satisfactory mods on a dedicated server: SML, ficsit.app, server targets, the Mod Manager over SFTP, keeping clients matched and surviving game updates. - [Satisfactory server lag in large factories](https://www.renode.space/blog/satisfactory-server-performance-and-large-factories) (2026-10-07): What makes a Satisfactory dedicated server slow as the factory grows: belts, vehicles, save size, replication and memory - and the build choices that keep it fast. - [Satisfactory server settings, saves and mods](https://www.renode.space/blog/satisfactory-server-settings-and-saves) (2026-09-21): Claiming a Satisfactory dedicated server, every setting in the Server Manager, where saves really live, autosave tuning, and installing SML mods server-side. - [Satisfactory dedicated server setup](https://www.renode.space/blog/satisfactory-dedicated-server) (2026-08-07): Install the server, claim it from the client, and keep a growing factory playable. Ports, autosaves, memory by factory size, mods and the hitches. --- ### Satisfactory server mods: SML and Mod Manager Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/satisfactory-mods-ficsit-server 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](https://www.renode.space/blog/satisfactory-dedicated-server) and the Server Manager settings in [Satisfactory server settings and saves](https://www.renode.space/blog/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. ```diagram title: How mods get onto a Satisfactory server repo = ficsit.app | mods and versions smm = Mod Manager | your PC, profiles server = Dedicated server | FactoryGame/Mods client = Each player | same profile repo -> smm : download, resolve deps smm -> server : SFTP install smm -> client : local install client -> server : join, mod check ``` 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: | Target | What it is | | --- | --- | | `Windows` | The game client on Windows | | `WindowsServer` | The dedicated server on Windows | | `LinuxServer` | The dedicated server on Linux | 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](https://www.renode.space/blog/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. ```text 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: | Kind of mod | Server | Clients | | --- | --- | --- | | Adds buildings, items, recipes or parts | Required | Required, same version | | Changes game rules or balance | Required | Usually required | | Client-only (UI, camera, quality-of-life) | Not needed | Each player's choice | 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. > [!WARNING] > Removing a mod that added buildings from an existing save is destructive. Everything built with it disappears when the save loads, and whatever was connected to it - belts, pipes, power - is left dangling. Choose the mod list before investing hundreds of hours, and back up before removing anything. #### 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](https://www.renode.space/blog/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. | Mod list | Extra RAM to allow | Start-up time | | --- | --- | --- | | A few quality-of-life mods | Little or none | Barely changes | | Several building or logistics mods | 1-2 GB | A little longer | | Large content packs or overhauls | 2-4 GB | Noticeably longer | 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](https://www.renode.space/blog/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. Every Satisfactory server on RE:NODE has its own SFTP credentials, so the Mod Manager can install SML and your mods straight into `FactoryGame/Mods`. The console shows the mod loader's log as the server starts, and backup slots on every plan cover the copy you take before each game or mod update. [See Satisfactory plans](https://www.renode.space/game-servers/satisfactory) --- ### Satisfactory server lag in large factories Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/satisfactory-server-performance-and-large-factories A Satisfactory dedicated server gets slower for three reasons, and none of them is the number of players. The factory simulation grows with every machine and every item on a belt; the save grows with it, so every autosave freezes the game for longer; and the server has to send each player the state of everything near them, which in a dense factory is a lot of state. Memory follows the save - 8 GB is comfortable for a new world, a mature megabase wants 12-16 GB. The fixes are mostly build choices: fewer, overclocked machines, trains and drones instead of trucks, storage in containers rather than on belts, and an autosave interval chosen on purpose. This post explains where the cost comes from, how to tell which kind of lag you have, and what to change. Installing and claiming a server is covered in the [Satisfactory dedicated server guide](https://www.renode.space/blog/satisfactory-dedicated-server), and the Server Manager settings in [Satisfactory server settings and saves](https://www.renode.space/blog/satisfactory-server-settings-and-saves). This post starts once the factory is big enough to hurt. #### Where a Satisfactory server spends its time The server runs the whole factory. Machines in a corner of the map nobody has visited for days are still producing, belts are still moving items and trains are still running their timetables. That is the point of a dedicated server, and it means the factory's cost does not depend on where the players are standing. The work divides into four parts: - **Factory simulation.** Every machine, belt, splitter, pipe, train and vehicle updates. This runs largely on one game thread, so clock speed decides the ceiling. - **Replication.** For each connected player, the server works out which nearby objects have changed and sends them. A player standing in the middle of a 300-machine block costs much more than one standing in a field. - **Saving.** The whole world is serialised into one `.sav` file on every autosave. The time this takes grows with the factory. - **Memory management.** The engine periodically cleans up memory. On a big world that cleanup is a short stall you can feel. ```diagram title: Where server time goes in a large factory factory = Factory tick | machines, belts, trains repl = Replication | per player, nearby save = Autosave | whole world to .sav players = Players | four or so disk = Save files | rotating autosaves factory -> repl repl -> players : state of nearby objects factory -> save : every interval save -> disk ``` Only the first of these is helped by a faster CPU core. The second is helped by fewer players in the densest areas and by network settings. The third is helped by fast storage and a smaller world. The fourth is helped by more memory headroom and by restarts. #### Telling the kinds of lag apart | Symptom | Likely cause | First check | | --- | --- | --- | | Everyone freezes for a second or more, on a regular timer | Autosave | Does it match the autosave interval? | | Production rates drop, everything feels sluggish | Factory tick is over budget | Server CPU graph pinned on one core | | Rubber-banding only in the main factory | Replication load near dense builds | Does it stop when you walk away? | | One player rubber-bands, others are fine | That player's connection | Their ping and packet loss | | Low frame rate in big factories, server fine | Client rendering | Each player's own FPS | | Hitches getting worse over days | Memory growth, cleanup stalls | Memory graph against the limit | The fourth and fifth rows are not the server at all. A player whose PC renders three thousand lights at 25 frames a second will call it lag; so will a player on a congested route. [Latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) covers telling a network problem from a server problem. The first row is the most common complaint on a mature server, and it is the one people most often misdiagnose as "the server needs more RAM". #### The autosave freeze Satisfactory has no incremental save. Every autosave writes the entire world - every building, every item on every belt, every vehicle and its path - into one file, and while that happens the game thread is busy. Save size grows with the factory: | Stage | Typical save size | Autosave feel | | --- | --- | --- | | Early game, Tiers 1-2 | 1-5 MB | Unnoticeable | | Mid game, trains and oil | 10-40 MB | A brief stutter | | Late game, several large sites | 50-150 MB | A noticeable freeze | | Megabase, hundreds of hours | 150-250 MB+ | A freeze people complain about | Three things reduce the freeze: 1. **Fast storage.** The write is large and sequential. NVMe turns a multi-second freeze into a short one; [what NVMe actually changes](https://www.renode.space/blog/what-nvme-actually-changes) is honest about the cases where it matters, and this is one. 2. **A smaller save.** Items on belts are saved individually. A factory with long belts running full and backed up into a dead end stores every one of those items. Emptying belts used as storage shrinks the file. 3. **A deliberate interval.** The Server Manager's autosave interval defaults to five minutes. Ten halves how often anyone notices, and doubles what a crash costs. Pick a number you can live with in both directions. There is a fourth thing that does not help: deleting old autosaves to save disk. The rotating autosaves are the cheapest protection you have, and each one is only the size of the save. #### Build choices that keep a factory cheap The biggest performance gains in Satisfactory come from how you build, not from server settings. A few principles apply to almost every large factory. **Fewer machines doing more.** Power Shards overclock a machine up to 250%, and Somersloops - in 1.0, production amplification - multiply output without more buildings. Ten overclocked constructors do the work of twenty-five at normal speed, and every one you do not build is a building the server does not tick, replicate or save. Power is the cost; power is cheaper than performance. **Containers instead of belts as storage.** Items on a belt are individually tracked objects. Items in a container are a count. A belt loop or a long backed-up belt acting as a buffer is one of the most expensive structures you can build. Feed into an Industrial Storage Container and out again. **Trains and drones, not trucks.** Automated trucks and tractors are the worst offenders on servers. Vehicles following a recorded path are physics-driven, they cost more the more there are, and on dedicated servers they have a long history of getting stuck, drifting off their path or stopping when nobody is nearby. Trains run on fixed tracks and are cheap. Drones are cheaper still for low-volume long-distance logistics. **Dimensional Depot uploads.** In 1.0 the Dimensional Depot lets you send items into central storage and build from it directly. Using it for construction materials removes whole networks of belts that existed only to bring concrete and steel beams to a build site. **Foundations are not the problem.** Since Update 8, foundations, walls and other simple building pieces are handled as lightweight buildables, which are far cheaper than they used to be. Big floors and walls cost memory and save size, but not much simulation. Machines and items moving are what costs. **Lights and signs cost frame rate, not server time.** Hundreds of lights in one area are rendered by each client. If a factory's frame rate is poor on everyone's PC but the server's graphs are calm, look at lights before anything else. > [!TIP] > Demolish abandoned starter factories. The smelters and constructors you built in hour three are probably still running, still ticking and still being saved, three hundred hours later, producing iron plates into a full container that nobody collects. #### Replication and the number of players Satisfactory is built and tested around four players. More can join with a configuration change described in [Satisfactory server settings and saves](https://www.renode.space/blog/satisfactory-server-settings-and-saves), and every extra player costs more than the last, because each has their own set of nearby objects to keep up to date. Replication cost depends on what is near each player, not on how big the factory is overall. Four players standing in the same dense manufacturing block share a lot of state. Four players in four different dense blocks multiply it. That is why rubber-banding in a big factory often stops when the player walks out into the open. Two things help: - **The Network Quality setting** in the Server Manager. It trades bandwidth and server work per client for smoothness. Raising it helps when vehicles and other players stutter while the factory is fine. On a server that is already CPU-bound, lowering it reduces per-player work. - **Engine bandwidth limits.** The community has long recommended raising the Unreal Engine network bandwidth caps in the server's `Engine.ini` and `Game.ini` for large factories, so that replication is not throttled. The keys are standard Unreal ones, such as `MaxClientRate` and `MaxInternetClientRate` under `[/Script/OnlineSubsystemUtils.IpNetDriver]`, and `TotalNetBandwidth` under `[/Script/Engine.GameNetworkManager]`. Coffee Stain does not document them as supported settings, the right values depend on your connection, and their effect has changed between game versions - check the Satisfactory wiki's dedicated server page for the current advice before editing, and keep a copy of the original files. FactoryGame/Saved/Config/LinuxServer/Engine.ini (example only): ```ini [/Script/OnlineSubsystemUtils.IpNetDriver] MaxClientRate=104857600 MaxInternetClientRate=104857600 ``` Players have their own Network Quality option in the client settings too; if one player stutters more than the others, check theirs. #### Memory: how much and why it grows Memory tracks the save. A bigger factory means more objects held in memory, and Unreal's memory use only ever grows during a session. | Stage | RAM | Notes | | --- | --- | --- | | New world, up to 4 players | 8 GB | Comfortable through the early tiers | | Mid game, trains, several sites | 10-12 GB | Where most groups spend their time | | Late game, mature factory | 12-14 GB | Plan for the peak during saving | | Megabase or heavy mods | 14-16 GB | Building mods add the most | Two things are worth understanding. **Saving needs extra memory.** Serialising the world briefly holds a copy of a lot of it. A server that runs at 90% of its limit is most likely to hit the limit exactly during an autosave - which is the worst possible time, because the save is interrupted. **Memory does not come back during a session.** A server that has run for a week uses more than the same world freshly started. Engine cleanup passes reclaim some, and on a large world those passes are the short hitches you feel between autosaves. A regular restart resets it. RE:NODE's Satisfactory plans run from 8 GB to 14 GB. A container that reaches its limit is stopped and restarted clean rather than left to swap, which protects the machine but costs everything since the last save; if the memory graph climbs close to the limit, move up a tier before it becomes a habit. Changing plan adjusts the limits on the existing server rather than rebuilding it, so the save stays where it is. [When to upgrade your plan](https://www.renode.space/blog/when-to-upgrade-your-plan) has the signals worth acting on. #### CPU and what a faster core buys The factory tick runs mostly on one thread. On a graph that looks like one core pinned and the rest idle, which on a multi-core allocation averages out to a figure that looks fine. [Reading a server load graph](https://www.renode.space/blog/reading-a-server-load-graph) covers why a single-threaded game can be saturated at 40% reported CPU. What extra cores do buy: saving, networking and engine housekeeping run off the game thread, so a second and third core stop those from competing with the factory. Beyond that, more cores do nothing for factory size. What more clock speed buys is a higher ceiling on how much factory can tick per second before production rates themselves fall behind. When the factory tick is over budget, the symptoms are subtle: machines produce slightly under their rated speed, trains arrive late, and the whole world feels slightly sticky. The response, in order: demolish what you do not need, consolidate with overclocking and Somersloops, replace trucks, empty belt buffers - and only then consider a bigger plan. #### Restarts and housekeeping A scheduled restart is the simplest performance measure for a large Satisfactory world. It clears accumulated memory, resets the engine's cleanup cost, and gives a clean save point. The Server Manager has a **Server Restart Time Slot** setting that lets the server restart itself at a chosen hour. On a panel host you can also use a schedule - on RE:NODE the Schedules tab runs a restart and a backup on a cron expression, so the nightly copy is taken just after a clean save. Make sure **Autosave on Player Disconnect** is on, so the last player leaving always writes the world. Weekly is enough for most groups; daily is reasonable for a megabase that climbs noticeably in memory. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) goes into timing. Before every game update, take a backup. Saves are forward-compatible only: a save opened by a newer version cannot go back to the older one, and an update that hurts performance cannot be undone without the copy. [Backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) explains why restoring one occasionally is part of the job. #### Troubleshooting **Freeze every five minutes.** The autosave. Check that the freezes match the interval, then shrink the save and lengthen the interval a little. **Freezes got worse after building a new site.** More items in transit and more machines in the save. Check for belts used as buffers in the new build. **Trucks stop or wander off their routes.** A known weakness of automated vehicles on dedicated servers. Replace the route with a train or drones. **Server restarted itself mid-session.** Probably the memory limit, possibly during a save. Look at the memory graph before the restart - [why your game server keeps restarting](https://www.renode.space/blog/why-your-game-server-keeps-restarting) has the patterns. **One CPU core pinned with nobody online.** Auto Pause is off, so the factory runs around the clock. That is a choice; turn Auto Pause on if you did not mean it. **Rubber-banding only in the main base.** Replication. Network Quality and fewer players in the densest area help; a bigger plan usually does not. #### FAQ ##### Does more RAM make a Satisfactory server faster? Only if it was short of memory. RAM lets the server hold a bigger factory without being stopped at its limit; it does not make the factory tick faster or the save shorter. Faster cores and a leaner factory do that. ##### How big can a Satisfactory factory get on a dedicated server? There is no hard limit. The practical one is when the autosave freeze and the factory tick become unpleasant. Groups that build with overclocking, trains and containers get far further than groups with truck routes and belt buffers. ##### Are trains bad for performance? No. Trains are one of the cheapest ways to move a lot of material. Large numbers of complicated junctions with heavy signalling add some cost, but trucks and belt loops are far worse. ##### Why does the game lag when everyone is in the same factory? The server sends each player the changing objects around them. Several players in the densest block multiply that work. Spreading out, or raising Network Quality if the server has CPU to spare, helps. ##### Should I turn off Auto Pause for a big factory? Only if you want production while nobody plays. With it off the factory runs, the save grows and one core stays busy all day. With it on, the world waits for you. Satisfactory plans on RE:NODE start at 8 GB and go to 14 GB, on NVMe storage that keeps the autosave freeze short, with CPU and memory graphs against the limit so you can see what is actually slow. Backup slots are on every plan, and changing tier keeps the server and its save where they are. [See Satisfactory plans](https://www.renode.space/game-servers/satisfactory) --- ### Satisfactory server settings, saves and mods Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/satisfactory-server-settings-and-saves A Satisfactory dedicated server has almost no configuration file. You install it, open one port, and then everything else happens from inside the game: you claim the server from the Server Manager tab, set a name and an admin password, create or upload a save, and change the handful of settings that exist from a panel in the client. That design is pleasant right up to the first problem, because when something fails there is nothing obvious to edit. This post covers the settings that exist and where they end up on disk, where saves actually live on a Linux server (not where you would guess), how the autosave produces the hitch your players complain about, and how mods work when the server needs its own build of every one of them. The wider argument about why a Satisfactory server gets heavier the longer it goes well is in [a Satisfactory dedicated server, and why it gets heavier](https://www.renode.space/blog/satisfactory-dedicated-server). #### Installing the server and the one port that matters The dedicated server is a free, separate download: Steam app id `1690800`, anonymous login, no game licence needed on the machine running it. ```bash $ steamcmd +force_install_dir /home/satisfactory +login anonymous \ +app_update 1690800 validate +quit $ cd /home/satisfactory $ ./FactoryServer.sh -Port=7777 ``` For the experimental branch, add `-beta experimental` before `validate`. The client and server must be on the same branch and the same build; an experimental client cannot join an early-access server or the reverse, and the error message does not say so clearly. [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers app ids and branch switching in general. Since Update 8 the server uses **one port for everything**, and it needs it on both protocols: | Port | Protocol | Purpose | | --- | --- | --- | | `7777` | UDP | Game traffic | | `7777` | TCP | The HTTPS API the Server Manager talks to | That is the single most common Satisfactory hosting problem. The old guides still floating about list `15777` for queries and `15000` for a beacon; those are gone. What people do instead is open `7777` UDP, because that is what game servers use, and then find the server sits at "Offline" in the Server Manager forever. Management, claiming, save uploads and mod installation all run over TCP on the same number. Open both. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) covers why a game has two channels at all. ```diagram title: Two protocols, one port number client = Satisfactory client | your PC manager = Server Manager | claim, settings, saves game = Game session | belts and trains server = FactoryServer | UDP and TCP 7777 saves = SaveGames/server | .sav files manager -> server : HTTPS over TCP game -> server : UDP client -> manager client -> game server -> saves : autosave ``` #### Claiming the server and the two passwords A freshly started server is unclaimed and will let the first person who finds it take it over. Do this immediately. 1. Open Satisfactory, go to **Server Manager** on the main menu, choose **Add Server**, and enter `address:7777`. 2. Accept the certificate warning. The server presents a self-signed certificate because there is no name to issue a real one against; this is expected, not a sign of interception. 3. The server reports itself as unclaimed. Set a **server name** and an **admin password**. That claims it. 4. Optionally set a **client password**, which is what other players type to join. The two passwords do different jobs. The admin password gives full control of the server: settings, saves, shutdown, mod installation. The client password only allows joining. Anyone who knows the admin password is an administrator - there is no per-player list and no role system, so it goes to the one or two people who actually run the server. With the server claimed, you either **Create Game** - session name, a starting location, and a checkbox for Advanced Game Settings - or **Manage Saves** and upload an existing one. The four starting locations are Grass Fields, Rocky Desert, Northern Forest and Dune Desert; they change where you land, not the map, and Grass Fields is the gentle one. #### The server settings and where they are written The Settings panel in the Server Manager is short. It is the whole of the server's gameplay-independent configuration: | Setting | Default | What it does | | --- | --- | --- | | Auto Pause | on | Pauses the world when nobody is connected | | Auto Save on Player Disconnect | on | Extra save when the last player leaves | | Autosave Interval | 5 minutes | How often the world is written | | Server Restart Time Slot | off | An hour of the day the server may restart itself | | Send Gameplay Data | on | Telemetry to Coffee Stain | | Network Quality | medium | Update rate per client | These are written to `ServerSettings.ini` in the server's config folder (`FactoryGame/Saved/Config/LinuxServer/` on Linux, `WindowsServer` on Windows) once you have changed them at least once. Read that file rather than trusting any published key list, including this table: Coffee Stain adds settings between updates and the file the server wrote is always current. **Auto Pause is the setting to think about first.** With it on, the factory stops the moment the last player disconnects, and starts again when someone returns. That is usually what a group actually wants - the world is there when you log in, and the server costs nothing in CPU overnight. If you want production to continue while nobody is online, turn it off, and understand what you have bought: the simulation runs 24 hours a day, the save grows around the clock, and the container's CPU allocation is in use continuously rather than for the three hours a night anyone plays. **Network Quality** trades bandwidth and server CPU for smoothness. Raising it helps when players see vehicles and other players stuttering while the factory itself is fine. Lowering it is worth trying on a server that is already CPU-bound, because it is the only knob that reduces per-player cost. The player cap is not in that panel. The dedicated server defaults to four players, matching the game's supported co-op size, and the community route to more is a `Game.ini` in the same config folder: FactoryGame/Saved/Config/LinuxServer/Game.ini: ```ini [/Script/Engine.GameSession] MaxPlayers=8 ``` This is unsupported by Coffee Stain and it is not free. Satisfactory's networking was tuned for four, and each extra player loading a different corner of a large factory costs more than the player count suggests. Eight works for most groups on a well-sized plan; sixteen is where people start reporting problems that no setting fixes. #### Advanced Game Settings Advanced Game Settings are per save, not per server. You enable them with the checkbox when creating the game, or from the pause menu on a save that already has them enabled. - No build cost, no power requirement - God mode and flight mode - Keep inventory on death - Unlock all research, schematics and tiers - Set the game phase directly - Give items Two things to know before ticking the box. Enabling Advanced Game Settings **permanently marks the save and disables achievements on it**, and there is no way back - copying the save does not clean it. And they are available to anyone on the server who opens the menu, not just the admin, so on a server with people you do not know well, "unlock all tiers" is one bored click away. For a group replaying the game together, leave them off. For a build server where the point is the factory and not the progression, turn them on at creation and never think about it again. #### Saves: where they live and how to move one This is where people lose an hour. The Linux dedicated server does not keep saves inside its installation directory. It writes them under the running user's home: ```text ~/.config/Epic/FactoryGame/Saved/SaveGames/server/ Longship.sav Longship_autosave_0.sav Longship_autosave_1.sav Longship_autosave_2.sav ~/.config/Epic/FactoryGame/Saved/SaveGames/blueprints/ ``` On a Windows server it is `%LOCALAPPDATA%\FactoryGame\Saved\SaveGames\server\`. On a client, your single-player and co-op saves are under `%LOCALAPPDATA%\FactoryGame\Saved\SaveGames\` in a folder named after your store account id. Moving a save onto the server has two routes. The supported one is **Manage Saves** then **Upload Save** in the Server Manager, which pushes the file over the HTTPS API. It is the right answer and it works, until the save is large and the upload times out, which starts happening on mature factories. The fallback is to copy the `.sav` straight into the `server` folder over SFTP or a file manager and restart the server, after which it appears in the save list like any other. [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) covers getting at that path on a panel. Two rules when you do it by hand. Copy only `.sav` files, and keep the session name consistent - the file name is what the Server Manager lists. And never overwrite a save the server is currently running; stop it first, because the next autosave will write over whatever you put there. Blueprints are separate. They are a pair of files per blueprint in the `blueprints` folder, and they do not travel with the save, which is why a blueprint built on a friend's single-player world does not show up on the server until someone copies it across. #### Autosaves, the hitch, and real backups Satisfactory writes the whole world to one file. There is no incremental save, so every autosave serialises the entire factory, and the time that takes grows with the factory. Five minutes into a new world it is imperceptible. Three hundred hours in it is the freeze your players report as lag, and they report it on a schedule because it happens on one. What actually helps, in order: 1. **Lengthen the interval.** Ten minutes instead of five halves how often anyone notices. It also doubles what a crash costs, so pick a number, do not just push it to the maximum. 2. **Fast storage.** The write is a large sequential one, and NVMe finishes it in a fraction of the time a spinning disk takes. This is one of the clearer cases in [what NVMe actually changes](https://www.renode.space/blog/what-nvme-actually-changes). 3. **More memory, if the machine is swapping.** A server writing a save while over its memory limit is a different and worse problem. What does not help is deleting autosaves to save disk. The three rotating files are the cheapest safety net you have. They are also not backups. They sit beside the live save on the same disk, they rotate, and a corrupt world is faithfully written into all three within fifteen minutes. A real backup is a copy somewhere the server cannot write, taken on a schedule, and restored occasionally to prove it works - [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) makes that case properly. Take one before every game update without exception: Satisfactory saves are forward-compatible only, and a save opened by a newer build cannot go back. On RE:NODE, backup slots are included on every Satisfactory plan, they are kept off the machine they protect, and restoring is a button rather than a ticket. The Schedules tab runs a nightly backup and, if you want one, a nightly restart on a cron expression - [restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) has the argument for and against that on a game that grows in memory. #### Mods with SML on a dedicated server Satisfactory's modding runs on **SML**, the Satisfactory Mod Loader, with mods distributed through ficsit.app and installed on clients by the Satisfactory Mod Manager. On a dedicated server, mods live in a `Mods` folder inside the server's `FactoryGame` directory, one folder per mod. The constraint that catches people is build targets. A mod is compiled per platform, and a mod that ships only a Windows client build cannot run on a Linux dedicated server no matter where you put the files. Check each mod's listing for a server target before planning a modpack around it. The Mod Manager can install directly to a claimed dedicated server using the admin password, which resolves the targets for you and is much less error-prone than copying folders. Everything else follows the usual rules for a modded server, and they are strict here: - **Client and server run the same mods at the same versions.** A mismatch usually fails at connect rather than degrading quietly. - **SML is tied to the game version.** After a game update, nothing loads until SML is updated, and then each mod after it. - **Removing a mod that added buildings breaks the save.** The world contains objects the game can no longer resolve. Decide a modlist before you commit two hundred hours to it, and back up before adding or removing anything. - **Mods increase memory use**, particularly ones adding buildings and recipes, and Satisfactory has no headroom to spare on a mature factory. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is the general procedure for the patch-day version of this. #### Sizing and troubleshooting Satisfactory's memory use tracks the size of the factory, not the number of players. A rough guide: | Stage | RAM | Notes | | --- | --- | --- | | New world, 2 players | 8 GB | Comfortable through the first phases | | Mid game, 4 players | 10-12 GB | Trains, several production sites | | Mature factory | 12-14 GB | It will use what you give it | | Modded | Top of that range | Building mods cost the most | **The server shows as Offline in the Server Manager but the port is open.** TCP on `7777` is not. The management channel is HTTPS over TCP on the same port number as the game's UDP traffic. **The client refuses the certificate.** Self-signed, expected, accept it. There is no way to install a real certificate for an IP address. **"Server is not claimed" after you claimed it.** You are looking at a different server, or the client has a stale entry. Remove it from the list and add it again. **The server will not accept a client of the same version.** Check the branch. Experimental and early access report similar version numbers and do not interoperate. **A save uploads and then fails to appear.** Usually a timeout on a large file. Copy it into the `server` save folder directly and restart. **One CPU core is pinned while nobody is online.** Auto Pause is off, so the factory is running. That is a choice, not a fault, but it is worth making deliberately. **Memory climbs all week and the server restarts on its own.** That is the container reaching its limit and being restarted clean rather than left to swap. On a growing factory it is a signal to move up a tier rather than to tune anything. #### FAQ ##### How many players can a Satisfactory dedicated server hold? Four by default, which is the supported number. Raising `MaxPlayers` in `Game.ini` works and is what most larger groups do, but it is unsupported and the networking was not designed for it. Eight is a reasonable stretch; beyond that expect problems no setting solves. ##### Does the factory keep running when nobody is online? Only if you turn Auto Pause off. By default the world is paused while empty, which means no overnight production and no CPU burned while nobody is playing. Whether that is a feature depends entirely on how your group likes to play. ##### Where are the saves on a Linux server? Under the running user's home directory, at `.config/Epic/FactoryGame/Saved/SaveGames/server/`, not inside the install folder. Blueprints are in a sibling `blueprints` folder. ##### Can I move a single-player save onto a dedicated server? Yes. Upload it from the Server Manager, or copy the `.sav` into the server's save folder and restart. The save format is the same; what does not come across are your blueprints, which are separate files. ##### Do I need a copy of the game to run the server? No. The dedicated server is a separate anonymous download on Steam, app id `1690800`, and needs no licence. You need the game to administer it, because the Server Manager is part of the client. ##### Why does the server freeze for a moment every few minutes? The autosave. The whole factory is serialised into one file, so the pause grows with the save. Lengthen the autosave interval, and make sure the storage underneath it is fast; nothing else changes it. Satisfactory plans on RE:NODE start at 8 GB and go to 14 GB, on NVMe throughout, which is what makes a large autosave a hitch rather than a stall. Two port allocations, backup slots on every tier stored off the machine they protect, and a Schedules tab for the nightly one. [See Satisfactory plans](https://www.renode.space/game-servers/satisfactory) --- ### Satisfactory dedicated server setup Published 2026-08-07, updated 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/satisfactory-dedicated-server Satisfactory is unusual in that the server gets measurably heavier the longer the game goes well. Every belt, every splitter and every stored item is state, and a factory that has been running for two hundred hours has a great deal of it. A server that was fine in month one and stutters in month three has not degraded - the save has grown. Plan for 8 GB at the start and 12 to 16 GB by the time the factory is worth showing people, open one port, and understand that almost everything you would expect to find in a config file is instead a panel inside the game client. This guide covers the install, the claim flow that catches everybody once, the settings that exist, saves and autosaves, mods, and the difference between a server problem and one player's route to it. #### How a Satisfactory dedicated server works The dedicated server is a free, separate download: **Satisfactory Dedicated Server**, Steam app id `1690800`, fetched anonymously with SteamCMD. It has no graphics, no console commands for gameplay, and - this is the part that surprises people coming from other games - no meaningful text configuration. Instead the server exposes a small HTTPS API, and the game client is the administration tool. You add the server's address in the client's Server Manager, claim it, name it, set an admin password and then either start a new game on it or upload a save. Every server setting after that is a control in that same panel. There is no `server.properties` to edit and no in-game chat command to kick somebody. Two consequences follow. The good one: administration works identically whether the server is on your own machine, on a VDS or on a panel host, because it is all done through the client. The bad one: if the management port is not reachable, the server can be running perfectly and be completely unmanageable, which is a failure mode worth recognising early. The server also runs the factory with nobody connected, unless Auto Pause is on. That single setting is the biggest gameplay decision you will make about hosting: a paused server costs nothing while you sleep, and a running one means the coal plants you left burning have produced something by morning. #### Requirements and resource usage Memory tracks the save, and the save tracks the factory. Player count barely moves it. | Stage | RAM | CPU | Disk | | --- | --- | --- | --- | | New game, 1-4 players, first few factories | 8 GB | 2 cores | 40 GB | | Mid game, several sites, trains running | 10-12 GB | 2-3 cores | 50 GB | | Late game, a mature megabase | 14-16 GB | 3+ cores | 60 GB | | Mods, especially ones adding buildings | add 2-4 GB | - | add 5 GB | - **CPU**: the factory tick is largely one thread, so clock speed decides how many belts and machines the server can keep honest. A second and third core do real work - networking, saving and asset streaming are not on the game thread - but they do not raise the ceiling on factory size. - **Disk**: the install is around 12-15 GB. A late-game save is 50-250 MB, and the server keeps several rotating autosaves plus whatever you have saved by hand, so the save folder alone can reach a couple of gigabytes. Fast storage is what turns an autosave from a visible freeze into a stutter - [what NVMe actually changes](https://www.renode.space/blog/what-nvme-actually-changes) has the honest version of that claim. - **Players**: Coffee Stain build and test around four. More will connect, but nothing above four is tuned, and each extra player adds both memory and game-thread cost. - **Network**: light. A few hundred kilobytes per second per player. If people rubber-band, look at the server tick before you look at the link. If you are unsure which resource you are short of, [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) is the shortest route to an answer, and [when to upgrade your plan](https://www.renode.space/blog/when-to-upgrade-your-plan) covers the signals worth acting on. #### Installing and starting the server ```bash $ steamcmd +force_install_dir /home/satisfactory/server +login anonymous \ +app_update 1690800 validate +quit $ cd /home/satisfactory/server $ ./FactoryServer.sh -Port=7777 -log -unattended ``` On Windows the binary is `FactoryServer.exe` and the arguments are the same. For the Experimental branch, add `-beta experimental` to the `app_update` line - and note that the client must be on the same branch, because an Experimental client cannot join a stable server or the reverse. That mismatch produces a server that simply does not appear, with no error explaining why. | Argument | What it does | | --- | --- | | `-Port=7777` | The single port the server uses | | `-log` | Send the log to the console instead of only a file | | `-unattended` | No crash dialog. Required for a headless run | | `-multihome=0.0.0.0` | Bind to a specific address on a multi-homed box | | `-beta experimental` | On the SteamCMD line, not the server line | [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers app ids, branches and update scripts if this is the first server you have installed this way. On a panel host you do not type any of it; the same values appear as fields on the Startup tab. #### Claiming the server, and the Server Manager The first start produces a server nobody owns. Claiming it is done from the game client, once: 1. Open Satisfactory, then the Server Manager, then Add Server. 2. Enter `address:7777`. The client contacts the HTTPS API, not the game port. 3. The server appears as unclaimed. Choose Claim, give it a name, and set the **Admin Password**. 4. Optionally set a **Client Password**, which is the join password. Leave it empty for an open server. 5. Create a new game, or go to Manage Saves and upload one. ```diagram title: How the client reaches and manages a server client = Game client | Server Manager api = HTTPS API | TCP 7777 game = Game traffic | UDP 7777 server = Dedicated server | FactoryServer saves = Save files | SaveGames/server client -> api : claim, settings client -> game : play api -> server game -> server server --> saves : autosave ``` The admin password is what any other machine needs to administer the server later, and there is no recovery flow for it - losing it means restoring control the hard way, from the filesystem. Write it down somewhere that is not the same machine. Uploading an existing single-player save is the usual way to start. Client saves live in `%LOCALAPPDATA%\FactoryGame\Saved\SaveGames\\` on Windows; pick the `.sav` in Manage Saves and the client pushes it to the server. The server keeps its own saves under `FactoryGame/Saved/SaveGames/server/`, which is also where you would drop a file directly over SFTP if the upload is too large to go through the client. #### The settings that exist, and where they live Server-level settings are in the Server Settings tab of the Server Manager. They apply to the server regardless of which save is loaded: - **Auto Pause** - pause the simulation when the last player leaves. Saves CPU, stops production. - **Auto Save on Disconnect** - write a save when a player leaves. Cheap insurance, one more write. - **Autosave Interval** - minutes between automatic saves. Five by default. - **Number of autosaves** - how many rotating copies to keep before overwriting the oldest. - **Network Quality** - how much bandwidth the server is allowed to spend on updates. Higher is smoother and costs more. - **Send Gameplay Data** - telemetry to Coffee Stain. Off is a valid answer. Save-level settings are Advanced Game Settings, and they belong to the save rather than the server: no build cost, unlock all research, set the game phase, disable arachnids and so on. > [!WARNING] > Enabling Advanced Game Settings flags the save permanently and disables achievements on it. There is no way back for that save. If you only want to turn off the spiders, note that the arachnid setting is a client-side display option and does not need Advanced Game Settings at all. Underneath, the server writes its configuration into `FactoryGame/Saved/Config/LinuxServer/` (or `WindowsServer/` on Windows). Change settings from the client rather than by editing those files: the running server holds its own copy and will write it back over yours. The one file worth touching directly is `Engine.ini`, where `NetServerMaxTickRate` under `[/Script/OnlineSubsystemUtils.IpNetDriver]` sets the server's network tick. Raising it can smooth movement for a small group with CPU headroom, and it is unsupported - if it makes things worse, put it back. #### Ports and connecting | Port | Protocol | Purpose | | --- | --- | --- | | `7777` | UDP | Game traffic | | `7777` | TCP | The HTTPS API the client manages the server through | Since the networking rewrite in Update 8, one port number does both jobs, and the older arrangement with a separate beacon and query port is gone. That is simpler, but it contains a trap: hosts and firewalls often allocate a game port as UDP only. With UDP alone the server is joinable by anyone who already has it configured and is completely invisible to the Server Manager, so you can neither claim it nor change a setting. If the client cannot see a server you know is running, that TCP side is the first thing to check. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) covers why games end up with this split in the first place. Players join through the Server Manager once the server is claimed and a session is loaded, or through a friend's session list. There is no public server browser, so the address is something you hand out. #### Saves, autosaves and backups The regular hitch that players report as lag is usually the autosave writing a large file. Every machine, every belt segment, every item in transit and every item in a container is serialised, and on a mature factory that is a real amount of work. - **Lengthen the interval as the save grows.** Five minutes is right for a new game and wrong for a two-hundred-hour one. Ten to fifteen minutes on a mature save trades a longer worst-case rollback for far fewer interruptions. - **Keep fewer rotating autosaves** if disk is tight, but keep at least three. Corruption tends to be discovered a session later, not immediately. - **Take a manual save before anything structural**: a game update, a mod change, a blueprint import, a big demolition. - **The autosaves are not backups.** They live on the same disk as the save they protect and they are overwritten on a timer. A backup is a copy somewhere else, on a schedule, that you have restored at least once - [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) is worth the five minutes. On RE:NODE, storage is NVMe throughout, which is what makes a large save write quickly rather than noticeably. Backup slots are included on every Satisfactory plan, taken on demand or on a schedule and stored off the machine they protect, and restoring one is a button. The Schedules tab can run the nightly backup and a weekly restart as ordered tasks, which is the whole maintenance routine for most groups - [restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers picking the hour. #### Why it gets heavier, and what to do about it Nothing about a Satisfactory server degrades. The save grows, and the cost of holding and writing it grows with it. Three things dominate: 1. **Item count in transit.** Belts hold items individually. A long belt network with everything running full is, to the server, a very large number of moving objects. Buffering into containers is cheaper than buffering on belts. 2. **Building count.** Every machine ticks. A thousand constructors cost a thousand ticks whether or not they have inputs. 3. **Save size.** Which is the first two, written to disk every autosave interval. The practical responses, in the order they are worth trying: lengthen the autosave interval, remove belt loops and long idle belts that exist only as storage, demolish abandoned starter factories rather than leaving them running, and only then buy memory. Changing plan on RE:NODE adjusts the limits on the server you already have rather than rebuilding it, so the save stays where it is if you do decide the factory has outgrown the tier. If everybody rubber-bands at the same moment, that is the server. If one player does and the others do not, that is their route to it - [latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) covers telling the three apart, and the distinction is worth making before anybody buys a plan they did not need. #### Mods with SML and the mod manager Satisfactory mods come from the mod repository at ficsit.app and load through SML, the Satisfactory Mod Loader. On a server, mods live in `FactoryGame/Mods/` next to the game files, and every client must run the same mods at the same versions. - **Satisfactory Mod Manager** can install to a remote server over SFTP or FTP, which is the least painful route if your host gives you those credentials. The command-line tool, `ficsit-cli`, does the same job in a script. - **Every game update breaks mods.** SML itself is version-locked to the game, and a server that auto-updates on patch day is a server that will not start until the mod authors catch up. Turn automatic updates off on a modded server and update deliberately. - **Removing a mod that added buildings is destructive.** Anything built with it disappears from the save, and what it was connected to may not survive the gap. Take a save you have tested first. - **Experimental and stable have different mod builds.** Pick a branch and stay on it. A modded server is also the usual answer to "why does it need four more gigabytes". Building mods raise the ceiling on what your factory can contain, and factories fill the space they are given. #### Troubleshooting **The Server Manager cannot see the server.** TCP on port `7777` is closed, or the address is wrong. Game traffic is UDP and management is TCP; having only one of them produces exactly this. **"Server is already claimed" and nobody knows the password.** The claim is stored in the server's config directory. Stopping the server and clearing that state is the only route back, and it means re-claiming and re-uploading, so keep the admin password somewhere safe. **The server does not appear after a game update.** The client updated and the server did not, or one of them is on Experimental. Versions must match exactly. **Everything freezes for several seconds on a schedule.** The autosave. Lengthen the interval; there is no setting that removes it. **The factory has not produced anything while we were away.** Auto Pause is on. That is a choice, not a fault, but it surprises people who expected a dedicated server to keep running. **The server stops and restarts by itself under load.** Memory. On RE:NODE, a container that reaches its limit is stopped and restarted clean rather than left to swap - which means you lose whatever happened since the last autosave, so a server running close to its ceiling should autosave more often, not less. **A save uploaded through the client fails or times out.** Large saves are better placed directly into `FactoryGame/Saved/SaveGames/server/` over SFTP, then picked from Manage Saves. #### FAQ ##### How much RAM does a Satisfactory server need? Eight gigabytes for a new game with a small group, ten to twelve by mid game with several production sites and trains, and fourteen to sixteen for a mature megabase. Mods that add buildings add two to four on top, because the factory grows to fill what they make possible. ##### Why is there no config file for server settings? Because administration moved into the game client in the 1.0 era. The server exposes an HTTPS API, the client's Server Manager is the front end for it, and the files the server writes underneath are its own state rather than an interface. Edit them and the running server overwrites you. ##### Does the factory keep running when nobody is online? Only if Auto Pause is off. With it on, the simulation stops when the last player leaves and resumes when somebody joins. Off means overnight production, more CPU use, and a save that keeps changing while you are not there. ##### Can I move a single-player save to a dedicated server? Yes. Upload it through Manage Saves in the Server Manager, or drop the `.sav` into the server's save folder directly. Progress, blueprints and the map all come with it; achievements are already governed by whether the save has Advanced Game Settings enabled. ##### Do all players need the same mods? Yes, the same mods at the same versions, and the same SML version. There is no partial matching, and a mod that auto-updated for one player breaks that player only, which makes it look like their problem rather than a version problem. ##### Is the autosave hitch fixable? Not removable, only reducible. Faster storage shortens it, a longer interval makes it rarer, fewer rotating copies makes each write cheaper, and a smaller factory makes it smaller. A server that hitches on a schedule is saving, not lagging, and the fix is a setting rather than a bigger plan. Satisfactory servers on RE:NODE start at 8 GB with two port allocations, so the game port and its TCP side are both open and the Server Manager can see the server from the first start. Storage is NVMe throughout, backup slots are on every tier, and moving up a tier changes the limits on the server you already have rather than rebuilding it, so the save stays put. [See Satisfactory plans](https://www.renode.space/game-servers/satisfactory) ## Rules for the assistant - Never ask the user for a password, token, API key or `.env` contents, and tell them not to paste one into this chat. Describe where a secret goes instead. - Secrets reach the server through the panel: `.env` is uploaded through the Files tab, startup variables are set on the Startup tab. `.env` never goes in the repository. - An app server has exactly one reachable port. Read it from `SERVER_PORT` (also `PORT` when the panel starts a linked repository) and bind `0.0.0.0`; never hard-code a port. - On every panel-managed server (everything except VDS and dedicated servers, which come with full root) only `/home/container` persists, and the process runs unprivileged: no root, `sudo`, `apt`, `systemd` or Docker. - Memory is a hard limit; a process that reaches it is killed with no error message. Suggest a bigger plan only after ruling out a leak. - Do not suggest changing the server's startup command or image to work around a code problem - fix the code or the repository. - Prices and plans above were read when this file was generated. Send the user to the page linked at the top before quoting a price as current. - For a specific server, the panel's Connect AI link (Console tab) gives the exact runtime, port, path and branch. Prefer it over these general rules when the user has one. - If something here does not answer the question, the full deploy docs are at https://www.renode.space/llms-full.txt and support is at https://www.renode.space/contact.