Running your own Satisfactory dedicated server is the difference between a factory that pauses the moment you log off and a persistent industrial world that keeps humming 24/7 for you and your friends. Coffee Stain Studios ships a free, standalone headless server tool that installs in minutes, supports full cross-play between Steam and Epic Games clients, and runs happily on a cheap Linux VPS or a spare Windows box. This tutorial walks through the entire process in twelve concrete steps that take roughly 30 minutes end to end.

By the end you will have a hardened, auto-restarting deployment: SteamCMD-installed binaries (app ID 1690800), firewall rules for the two ports the game now requires (7777 and 8888), a systemd service that survives reboots and crashes, a claimed and password-protected world, automated backups, and a safe update workflow. Everything here reflects the current game as of mid-2026, after Update 1.1 (stable since June 2025) reworked the networking model and Update 1.2 reached the stable branch. If you have ever stood up a Palworld dedicated server or a Valheim dedicated server, the shape of this guide will feel familiar – but the Satisfactory-specific details around ports, claiming, and cross-play are where most people get stuck.

We benchmarked this walkthrough against the thinner setup guides currently ranking for the keyword, then went further: a complete working project, real output examples, five common pitfalls, ten troubleshooting fixes, and an eight-question FAQ. Let’s build it.

What Is a Satisfactory Dedicated Server?

A Satisfactory dedicated server is a standalone, headless build of the game published by Coffee Stain Studios as a separate download on Steam (app 1690800) and the Epic Games Store. Unlike the default “host and play” mode – where one player’s client acts as the server and everyone disconnects the instant that player quits – the dedicated server runs as a background process with no graphics, no player character, and no window. It exists purely to simulate the world, tick your conveyor belts, and accept connections.

That distinction matters more in Satisfactory than in most co-op games. A mature save contains thousands of machines, belts, pipes, trains, and drones, all of which must keep simulating so that resource buffers fill and production lines advance. With a peer-hosted session, that simulation only happens while the host is online, and everyone else’s progress is gated on one person’s schedule. A dedicated server decouples the world from any single player: your megafactory keeps producing overnight, friends in other time zones can hop in whenever they like, and no single machine’s performance bottlenecks the whole group.

The server tool is genuinely free – you do not need to buy a second copy of the game to run it, and it uses SteamCMD’s anonymous login. You do need to own Satisfactory on at least one client to claim and administer the server, which we cover in Step 7. Because the server integrates the Epic Online Services SDK, cross-play works out of the box: a friend who bought the game on Epic and another who bought it on Steam can join the exact same server regardless of where you downloaded the server binaries. This is one of the biggest advantages Satisfactory has over games where the storefront fragments the player base.

Prerequisites and System Requirements

Before you touch a terminal, make sure your host machine clears the bar. The single most common reason a Satisfactory dedicated server crashes or stutters is insufficient RAM on a large save – this is not a game where you can cut corners on memory. The official minimum is 8 GB of RAM, but the moment you scale past a handful of players or a sprawling factory, you will want 16 GB.

ComponentMinimumRecommended
CPUIntel Core i5-3570 or AMD Ryzen 5 3600 (single-thread rating 2000+)Modern 4+ core CPU with high single-thread clock
RAM8 GB16 GB (for large saves or more than 4 players)
Storage (Windows)12.4 GB freeSSD/NVMe, 20 GB+ for saves & backups
Storage (Linux)8 GB freeSSD/NVMe, 20 GB+ for saves & backups
OSWindows 10/11, Server 2016/2019/2022, or Ubuntu/Debian 64-bitUbuntu 22.04/24.04 LTS or Windows Server 2022
Architecturex86-64 only (no 32-bit, no ARM)x86-64

Note the architecture line: there is no ARM build, so a Raspberry Pi or an ARM-based cloud instance will not work. You need genuine x86-64 hardware. CPU single-thread performance matters more than raw core count because Satisfactory’s simulation is heavily single-threaded; a high-clock quad-core will outperform a many-core server chip with a low base clock.

Here is your full prerequisites checklist before starting:

  • A 64-bit host running Ubuntu 22.04/24.04 LTS (this guide’s primary path) or Windows Server 2022, with sudo/administrator access.
  • At least 8 GB RAM free for the server process (16 GB recommended).
  • SteamCMD installed (Step 2 handles this).
  • Ability to open TCP/UDP 7777 and TCP 8888 on both the OS firewall and, for a home server, your router.
  • The full game (any storefront) installed on a PC you can use to claim the server.
  • Roughly 20 GB of free disk to hold binaries, saves, and a few backup generations.

Cloud users renting a VPS should pick a plan with dedicated (not burstable) vCPUs and at least 8 GB RAM. The official Satisfactory site and community wiki both stress that shared, oversubscribed hosts produce the tick-rate stutter players describe as “the belts are lagging.”

Understanding the Satisfactory Server Ports (7777 and 8888)

Networking is where the majority of failed setups die, so it is worth understanding before you open a firewall. If you followed an old guide, you may have seen ports like 15777 and 15000 – those belonged to the pre-1.0 Early Access server and are obsolete. The modern Satisfactory dedicated server uses a two-port model that was finalized in patch 1.1.0.0.

PortProtocolPurposeNotes
7777TCP + UDPPrimary game and server traffic (world state, player movement, server discovery in the Server Manager)Port redirection is not supported – the external and internal port numbers must match
8888TCPReliable messaging channel (handshake, API, connection setup)Required since patch 1.1.0.0; remappable with the -ExternalReliablePort= launch flag

The critical takeaway: both ports must be open. The number-one connection failure since Update 1.1 is opening 7777 (which everyone knows about) while forgetting 8888. Symptoms are misleading – the server may even appear in the Server Manager after you add it by IP, but players hang forever on “Connecting” because the reliable-messaging handshake on 8888 never completes.

Because port redirection is unsupported for 7777, you cannot run the server on an internal 7777 and expose it externally on, say, 7778. If you need multiple servers on one machine, change the actual listen port with the -Port= flag (and give each its own -ExternalReliablePort=), which we cover in the advanced section. For a single server, leave the defaults and simply open both ports.

Step 1: Prepare the Host and Create a Dedicated User

Start by updating the operating system and creating an unprivileged user that will own and run the server. Never run a game server as root. If the process is ever compromised, an unprivileged account contains the blast radius to that user’s home directory instead of your entire box.

# Update the OS
sudo apt update && sudo apt upgrade -y

# Create a locked-down service account with a home directory
sudo useradd -m -s /bin/bash satisfactory

# Switch into it for the rest of the setup
sudo -u satisfactory -i
whoami   # should print: satisfactory

The -m flag creates /home/satisfactory, which is where SteamCMD, the server binaries, and the save data will live. Everything from here until the systemd step runs as this satisfactory user. If you are on Windows Server, create a standard (non-administrator) local user for the same reason and log in as that account.

Step 2: Install SteamCMD and 32-bit Libraries

SteamCMD is Valve’s command-line tool for downloading dedicated server files. On a fresh Ubuntu install you first enable the multiverse repository and the i386 architecture, because SteamCMD ships as a 32-bit binary even when the game itself is 64-bit.

# Run these with sudo (exit back to your admin shell if needed)
sudo add-apt-repository multiverse -y
sudo dpkg --add-architecture i386
sudo apt update

# Accept the Steam license prompt when it appears
sudo apt install -y steamcmd lib32gcc-s1

If the steamcmd package is unavailable on your distro, download it manually into the service user’s home directory instead:

# As the satisfactory user
mkdir -p ~/steamcmd && cd ~/steamcmd
curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxvf -
./steamcmd.sh +quit   # first run self-updates, then exits

A successful first run ends with SteamCMD printing its version and dropping you back to the shell. If you see missing-library errors, install lib32gcc-s1 (older guides reference lib32gcc1, which was renamed).

Step 3: Download the Satisfactory Dedicated Server (App 1690800)

Now pull down the server binaries. This is the step where AI-generated guides get the command wrong – the app ID is 1690800 (the dedicated server tool), not 526870 (the retail game), and you must include both +login anonymous and the trailing validate keyword.

# As the satisfactory user, from ~/steamcmd (or use the packaged 'steamcmd')
./steamcmd.sh +force_install_dir ~/SatisfactoryDedicatedServer \
  +login anonymous \
  +app_update 1690800 validate \
  +quit

The download is a few gigabytes and takes a couple of minutes on a decent connection. On success you will see output resembling:

Update state (0x61) downloading, progress: 74.20 (2810312222 / 3787654012)
Update state (0x81) verifying update, progress: 96.11 (3640...)
Success! App '1690800' fully installed.

The validate keyword tells SteamCMD to checksum every file after download and re-fetch anything corrupt. Skipping it is a classic pitfall: a truncated download will produce a server that crashes on launch with no obvious error. To install the public test build instead, append -beta experimental to the +app_update line – but keep clients and server on the same branch, or connections will be refused for a version mismatch.

Step 4: Configure the Firewall for Ports 7777 and 8888

With binaries in place, open the two required ports. On Ubuntu, UFW (Uncomplicated Firewall) is the simplest tool. Remember: 7777 needs both TCP and UDP, while 8888 needs TCP only.

# Game/server traffic
sudo ufw allow 7777/tcp
sudo ufw allow 7777/udp

# Reliable messaging (required since patch 1.1.0.0)
sudo ufw allow 8888/tcp

# Enable and inspect
sudo ufw enable
sudo ufw status verbose

Expected output confirms all three rules are active:

To                         Action      From
--                         ------      ----
7777/tcp                   ALLOW       Anywhere
7777/udp                   ALLOW       Anywhere
8888/tcp                   ALLOW       Anywhere

If this is a home server behind a consumer router, you must also forward the same ports (7777 TCP/UDP and 8888 TCP) to your host’s LAN IP in the router’s port-forwarding page, and remember that redirection is not allowed for 7777 – the public and internal port numbers have to match. Cloud VPS users additionally need to open these ports in the provider’s security group or network firewall (AWS, Azure, GCP, Hetzner, and others all layer a firewall above the OS). This “double firewall” trips up a lot of first-time cloud hosts.

Step 5: First Launch to Generate the Server Files

Before wrapping the server in a service, launch it once by hand so it generates its configuration and save directories and you can confirm it boots cleanly. On Linux the launcher is FactoryServer.sh (on Windows it is FactoryServer.exe – do not mix these up; using the .exe name in a Linux service is a frequent copy-paste error).

cd ~/SatisfactoryDedicatedServer
./FactoryServer.sh -log -unattended

The -log flag streams the log to your console and -unattended suppresses interactive dialogs so it can run headless. A healthy startup ends with the server listening and waiting:

LogInit: Display: Starting Satisfactory Dedicated Server
LogNet: Created socket for bind address: 0.0.0.0:7777
LogSatisfactoryServer: Ready for connections. Waiting for a session...

In a second terminal, verify the process is actually listening on both ports:

ss -tulpn | grep -E '7777|8888'
# Expect lines showing the server bound to 7777 (tcp+udp) and 8888 (tcp)

Once you have confirmed a clean boot, press Ctrl+C to stop it. You are about to hand launch duties to systemd.

Step 6: Create a systemd Service for 24/7 Uptime

A dedicated server is only worth the effort if it restarts on crash and survives reboots. The correct way to do that on Linux is a systemd unit. The most important detail – and the one nearly every stale guide gets wrong – is KillSignal=SIGINT. Satisfactory needs a graceful shutdown to flush its save; the default SIGTERM kills the process instantly and can corrupt an in-progress autosave.

Create the unit file as your admin/root user:

sudo nano /etc/systemd/system/satisfactory.service
[Unit]
Description=Satisfactory Dedicated Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=satisfactory
Group=satisfactory
WorkingDirectory=/home/satisfactory/SatisfactoryDedicatedServer
ExecStart=/home/satisfactory/SatisfactoryDedicatedServer/FactoryServer.sh -log -unattended
Restart=on-failure
RestartSec=60
KillSignal=SIGINT
TimeoutStopSec=90

[Install]
WantedBy=multi-user.target

Reload systemd, enable the service so it starts at boot, and launch it now:

sudo systemctl daemon-reload
sudo systemctl enable satisfactory
sudo systemctl start satisfactory
sudo systemctl status satisfactory

A running service reports active (running):

● satisfactory.service - Satisfactory Dedicated Server
     Loaded: loaded (/etc/systemd/system/satisfactory.service; enabled)
     Active: active (running) since Tue 2026-06-02 14:07:11 UTC; 12s ago
   Main PID: 20418 (FactoryServer.s)

Stream live logs any time with journalctl -u satisfactory -f. On Windows, the equivalent is wrapping FactoryServer.exe -unattended with NSSM (the Non-Sucking Service Manager): nssm install SatisfactoryServer, point it at the executable, set the argument, and start the service.

Step 7: Claim Your Server in the In-Game Server Manager

The server is running but “unclaimed” – an empty shell with no world and no admin. You take ownership from a game client, not the command line. Launch Satisfactory on your PC, open the Server Manager from the main menu, and click Add Server.

  1. Enter your server’s address as IP:PORT, for example 203.0.113.10:7777 (use the LAN IP if you are on the same network, the public IP otherwise).
  2. The game connects and, because the server is unclaimed, prompts you to claim it.
  3. Give the server a display name and set a strong administrator password. This password gates all future admin actions, so treat it like any other credential – length beats complexity, and it should be unique to this server.
  4. Optionally set a separate player join password if you want the world invite-only. It is not enabled by default, so anyone who knows your IP and port can join until you set one.

Once claimed, the server appears in your Server Manager with a green status indicator. Password management here mirrors the advice in our Minecraft server setup guide: a weak admin password on an internet-facing game server is an open door.

Step 8: Create or Import a Save and Start the World

A claimed server still has no world running. From the Server Manager, open the Manage Sessions tab and either Create New Game (choose starting location and any advanced game rules) or Upload Save to migrate an existing single-player or peer-hosted world to the dedicated host.

Uploading is how most groups transition: you play solo for a while, then move that save onto the always-on server. Save files live under predictable paths, which is essential to know for backups (Step 10):

DataLinux pathWindows path
Save games~/.config/Epic/FactoryGame/Saved/SaveGames/server%LocalAppData%\FactoryGame\Saved\SaveGames\server
Server settings~/.config/Epic/FactoryGame/Saved/SaveGames/ServerSettings.<port>.sav%LocalAppData%\FactoryGame\Saved\SaveGames\ServerSettings.<port>.sav
Blueprints~/.config/Epic/FactoryGame/Saved/SaveGames/blueprints%LocalAppData%\FactoryGame\Saved\SaveGames\blueprints

When you run the server under systemd as the satisfactory user, ~ resolves to /home/satisfactory, so your live save sits at /home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server. Bookmark that path.

Step 9: Tune Advanced Server Settings (Players, Autosave, INI)

Most day-to-day configuration happens in the graphical Server Manager under Advanced Server Settings – you do not need to hand-edit files for the common options. The defaults are conservative; here are the settings worth reviewing on day one.

SettingWhat it doesRecommendation
Max PlayersConcurrent player cap (default up to 4)Raise only if you have the RAM – 16 GB+ for more than 4
Autosave IntervalMinutes between rolling autosavesKeep frequent; shorter interval = less lost progress on a crash
Auto PauseFreezes simulation when no players are connectedEnable to save CPU on an idle server; disable if you want overnight production
Auto Save on DisconnectWrites a save when the last player leavesEnable for safety
Restart on crashHandled by your systemd Restart=on-failureAlready covered in Step 6
Network QualityBandwidth/update fidelity to clientsUltra for LAN/strong links, lower it if players report rubber-banding

Decide the Auto Pause question deliberately. If your group’s whole point is a factory that runs overnight and fills storage while everyone sleeps, disable Auto Pause – otherwise the world freezes the moment the last player logs off and nothing is produced. If you just want a persistent world without the electricity bill of round-the-clock simulation, leave it on.

Editing INI files for advanced tweaks

For settings not exposed in the UI, Satisfactory reads standard Unreal Engine INI files (Engine.ini, Game.ini) from the server’s config directory. For example, you can pin the listen port there instead of on the command line:

[URL]
Port=7777

Only touch INI files when the server is stopped. Editing them live can be overwritten on the next save, and on Windows it is one of the triggers for the dreaded 0x606 file-lock error covered in troubleshooting.

Step 10: Automate Backups of Your Factory

A Satisfactory save represents dozens or hundreds of hours of work. The in-game autosave protects against crashes, but not against a corrupted disk, a bad update, or someone dismantling half the factory “by accident.” Add an off-server backup with a simple cron job that snapshots the save directory nightly and keeps a rolling window.

#!/usr/bin/env bash
# /home/satisfactory/backup.sh
set -euo pipefail
SRC="/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server"
DEST="/home/satisfactory/backups"
STAMP=$(date +%Y%m%d-%H%M%S)
mkdir -p "$DEST"
tar czf "$DEST/satisfactory-save-$STAMP.tar.gz" -C "$SRC" .
# Keep only the 14 most recent backups
ls -1t "$DEST"/satisfactory-save-*.tar.gz | tail -n +15 | xargs -r rm --
echo "Backup complete: satisfactory-save-$STAMP.tar.gz"

Make it executable and schedule it as the satisfactory user:

chmod +x /home/satisfactory/backup.sh
crontab -e
# Add this line to run the backup every night at 04:00
0 4 * * * /home/satisfactory/backup.sh >> /home/satisfactory/backup.log 2>&1

For real safety, periodically copy the backups folder off the machine entirely – to object storage, another host, or your desktop. A backup that lives only on the server it is protecting is not a backup. This is the same discipline we recommend for an ARK dedicated server, where world files are equally precious.

Step 11: Update the Server Safely

When Coffee Stain ships a patch, clients update automatically through Steam or Epic, but your dedicated server does not – you must re-run SteamCMD. If clients update to a new build and the server is behind, players get a version-mismatch rejection. The safe sequence is: stop the service, update, then start.

# 1. Stop the running server (graceful, thanks to KillSignal=SIGINT)
sudo systemctl stop satisfactory

# 2. Re-run the same install command to pull the latest build
sudo -u satisfactory ~/steamcmd/steamcmd.sh \
  +force_install_dir /home/satisfactory/SatisfactoryDedicatedServer \
  +login anonymous +app_update 1690800 validate +quit

# 3. Start it again
sudo systemctl start satisfactory

Always run validate on updates too – it repairs any partially written files. And never update while the server is running: SteamCMD cannot overwrite files the running process holds open, which produces the 0x606 error. Because you stopped the service first, that is a non-issue here. For extra caution before a major version jump, run your Step 10 backup script manually so you have a known-good snapshot to roll back to.

Step 12: Connect, Verify, and Play with Cross-Play Friends

Time to confirm the whole stack works end to end. From your game client’s Server Manager, your claimed server should show Online with the session running. Join it, and you should spawn into your world. Then have a friend connect – this is where cross-play shines.

  • A friend on Steam and a friend on Epic both add the same IP:7777 in their Server Manager and join the identical world – the storefront is irrelevant.
  • Everyone must be on the same game build (all stable, or all experimental). Mixed branches are the usual cause of “cannot join.”
  • Confirm the server is genuinely reachable from outside your network. From a machine off your LAN, a quick TCP check to port 7777 tells you whether your router/cloud firewall forwarding is correct.

Run this from any external Linux/macOS machine to prove the port is open to the internet:

# From OUTSIDE your network, replace with your public IP
nc -zv YOUR_PUBLIC_IP 7777
# Success looks like:
# Connection to YOUR_PUBLIC_IP 7777 port [tcp/*] succeeded!

If that succeeds and your friends can join, congratulations – you have a complete, production-grade Satisfactory dedicated server: SteamCMD-installed, firewalled, service-managed, claimed, backed up, and cross-play-ready.

Common Pitfalls to Avoid

These five mistakes account for the overwhelming majority of failed Satisfactory dedicated server setups. Reviewing them now will save you an evening of frustration.

  • Opening only port 7777. Since patch 1.1.0.0 you must also open 8888/TCP. The server can appear reachable while joins silently hang because the reliable-messaging handshake never completes. This is the single most common failure today.
  • Using the wrong app ID. The dedicated server is 1690800. If you install 526870 you get the full retail game, not the headless server, and it will not run correctly as a service.
  • Running as root and skipping validate. Root running is a security liability; omitting validate risks silent file corruption that manifests as a server that crashes instantly with no useful log line.
  • Under-provisioning RAM. 4 GB might boot an empty world but will crash on a mid-to-late-game factory. Honor the 8 GB minimum, and budget 16 GB for large saves or 4+ players.
  • Updating or editing config while the server runs. This causes the 0x606 file-lock error on Windows and can corrupt an autosave. Always systemctl stop first.

Troubleshooting: 10 Fixes for Common Errors

When something breaks, work through these in order. Most issues are networking or version mismatches, not the server software itself.

  • Server never appears in the Server Manager. Verify the process is listening (ss -tulpn | grep 7777), that 7777 is open on TCP and UDP, and that you entered the correct IP:7777 – use the LAN IP on the same network, the public IP off it.
  • Players hang forever on “Connecting.” Almost always port 8888/TCP is closed. Open it on the OS firewall, the router, and any cloud security group.
  • “Connection timed out” from outside only. Your OS firewall is fine but the router/cloud firewall is not forwarding. Remember 7777 cannot be redirected to a different external port.
  • SteamCMD error 0x606. You tried to update while the server was running and a file was locked. Run systemctl stop satisfactory, then re-run the update.
  • Server crashes immediately on launch. Re-run the install with validate to repair corrupt files, and confirm you have the 8 GB minimum RAM free.
  • Server crashes when loading a big save. This is memory pressure – move to 16 GB, and check for other processes eating RAM on the host.
  • Cross-play friend cannot join. You are on different branches. Put everyone on the same build (all stable or all experimental) and update the server if clients auto-updated.
  • “Failed to claim server.” Another client already claimed it, or you are pointing at the wrong instance. Check journalctl -u satisfactory and confirm the admin password.
  • Service does not start after reboot. You forgot systemctl enable satisfactory, or the ExecStart path is wrong (double-check it is FactoryServer.sh, not .exe, on Linux).
  • Belts lag or tick-rate stutters. The host CPU’s single-thread performance is too low, or it is an oversubscribed shared VPS. Move to a host with dedicated vCPUs and a high clock, and put saves on SSD/NVMe.

Advanced Tips and Optimization

Once the basics are solid, these techniques push your Satisfactory dedicated server further.

  • Run multiple servers on one box. Give each instance its own install directory, launch flags (-Port=7778 -ExternalReliablePort=8889 for the second, and so on), and its own systemd unit. Open the matching port pair for each.
  • Pin the branch explicitly. Scripting your updates with +app_update 1690800 -beta public validate (or -beta experimental) guarantees you never drift onto an unintended branch after a wipe or reinstall.
  • Watch resource usage. Pipe journalctl -u satisfactory -f to your monitoring, and track RAM with systemctl status or a lightweight agent. A steadily climbing memory curve on a growing factory is your cue to add RAM before the crash.
  • Mind mods. The Satisfactory Mod Manager and SML can run server-side, but every client must load the identical mod set and version. Mods also complicate updates – plan to disable them before a game patch and re-enable after the mod authors catch up.
  • Tune autosave vs. performance. A very short autosave interval on a huge factory causes a periodic frame-time hitch as the world serializes. Balance backup frequency against that momentary stutter; a moderate interval plus the nightly tarball from Step 10 is a good compromise.
  • Share blueprints server-side. Blueprints live in their own directory (see Step 8’s table). Dropping a teammate’s .sbp files there makes shared designs available to everyone on the server.

The Complete Working Setup at a Glance

Here is the entire deployment condensed into a copy-paste-ready sequence for a fresh Ubuntu host. It assumes you have already opened ports at the router/cloud layer, and it stops short of the in-game claim (Step 7), which must be done from a client.

# --- Host prep ---
sudo apt update && sudo apt upgrade -y
sudo useradd -m -s /bin/bash satisfactory
sudo add-apt-repository multiverse -y
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd lib32gcc-s1

# --- Install the server (as the service user) ---
sudo -u satisfactory bash -c 'mkdir -p ~/steamcmd && cd ~/steamcmd && \
  curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxvf - && \
  ./steamcmd.sh +force_install_dir ~/SatisfactoryDedicatedServer \
  +login anonymous +app_update 1690800 validate +quit'

# --- Firewall ---
sudo ufw allow 7777/tcp && sudo ufw allow 7777/udp && sudo ufw allow 8888/tcp
sudo ufw --force enable

# --- Service (unit file from Step 6 must exist) ---
sudo systemctl daemon-reload
sudo systemctl enable --now satisfactory
sudo systemctl status satisfactory --no-pager

# Now claim the server from the in-game Server Manager (Step 7).

That is a genuinely complete, reproducible project: run these commands, drop in the systemd unit, claim the world from your client, and you have an always-on factory. If you outgrow self-hosting, the same knowledge maps cleanly onto managed hosts – you will simply be pasting your IP and admin password into their control panel instead of a terminal.

Version History and What Changed for Servers

Because so much stale advice still circulates, it helps to know which release changed what. The networking model in particular has shifted, and following a pre-1.0 guide is how people end up opening the wrong ports.

ReleaseTimelineWhy it matters for servers
Update 1.0September 10, 2024Full launch; consolidated networking onto port 7777, retiring the old 15777/15000 scheme
Update 1.1 (Experimental)April 1, 2025Public test branch for the 1.1 changes
Update 1.1 (Stable)June 10, 2025Finalized the two-port model – 8888/TCP now required alongside 7777
Console launchNovember 2025Shipped on Update 1.1; broadened the player base joining dedicated servers
Update 1.2 (Experimental)March 17, 2026Public test branch for 1.2
Update 1.2 (Stable)Mid-2026Current stable branch; the server setup steps in this guide remain unchanged

The practical upshot: any guide that tells you to forward UDP 15777 or 15000 is describing Early Access and should be ignored. Today it is 7777 (TCP/UDP) plus 8888 (TCP), full stop.

Frequently Asked Questions

How much RAM does a Satisfactory dedicated server need?

The official minimum is 8 GB of RAM. That is fine for a small world and a couple of players, but memory use grows with your factory’s size. Budget 16 GB if you plan to host more than four players or expect a large, late-game save – running out of RAM is the leading cause of dedicated-server crashes.

What ports does a Satisfactory dedicated server use?

Two: port 7777 on both TCP and UDP for game and server traffic, and port 8888 on TCP for reliable messaging. Both have been required since patch 1.1.0.0. The older 15777 and 15000 ports from Early Access are no longer used. Port 7777 cannot be redirected – its external and internal numbers must match.

Is the Satisfactory dedicated server free?

Yes. The dedicated server tool (Steam app 1690800) is a free download and installs via SteamCMD’s anonymous login – you do not need to buy a second copy. You do need to own the full game on at least one client to claim and administer the server.

Can Steam and Epic players join the same server?

Yes. Thanks to the Epic Online Services integration, cross-play is fully supported. Clients from both the Steam and Epic Games stores can connect to the same dedicated server regardless of where the server binaries were downloaded. Everyone just needs to be on the same game build (all stable or all experimental).

How many players can a Satisfactory dedicated server hold?

By default the server supports up to four players, matching the game’s co-op design. You can raise the player cap in the Advanced Server Settings, but do so only if the host has the memory for it – the official guidance is 16 GB of RAM for hosting more than four players.

Can I run a Satisfactory dedicated server on Linux?

Absolutely – Linux is arguably the better choice. The server runs natively on 64-bit Debian and Ubuntu, uses less storage than the Windows build (about 8 GB vs 12.4 GB), and pairs cleanly with a systemd service for auto-restart. There is no ARM build, so you need x86-64 hardware; a Raspberry Pi will not work.

Do I need to own the game to run a dedicated server?

You do not need to own the game to download and run the server binaries – SteamCMD pulls them anonymously. However, you must own Satisfactory on a client to claim the server, set the admin password, and create or upload a world. In practice, at least one person in your group owns the game.

How do I update my Satisfactory dedicated server?

Stop the service, re-run the SteamCMD command with +app_update 1690800 validate, then start it again. The server does not auto-update like the client, so after a game patch you must update it manually or players will be rejected for a version mismatch. Never update while the server is running, or you will hit the 0x606 file-lock error.

Final Thoughts

Standing up a Satisfactory dedicated server is a genuinely approachable project: a dozen steps, a single free download, and about half an hour of work separate you from a persistent factory that never sleeps. The parts that trip people up are specific and avoidable – the two-port requirement, the exact app ID, running as an unprivileged user, and a graceful-shutdown systemd unit. Nail those, add automated backups, and keep the server on the same branch as your clients, and you will have a rock-solid foundation for hundreds of hours of automation.

From here, the same self-hosting muscles transfer to every other co-op title. If you are building out a home game-server stack, our companion tutorials cover the biggest names in the same step-by-step style.