Tutoriales de VPS
Montar un servidor dedicado de Satisfactory en un VPS (2026): SteamCMD, nuevos puertos, copias de seguridad y actualizaciones automáticas
Monta un servidor dedicado de Satisfactory en un VPS Ubuntu 24.04 x86_64 con SteamCMD, cubriendo el App ID 1690800, los nuevos puertos, el reclamo en Server Manager, systemd, la copia y restauración y las actualizaciones automáticas.
Si quieres jugar a Satisfactory con amigos a largo plazo, abrir una partida temporal en el ordenador de un jugador plantea un problema muy real: cuando el anfitrión se desconecta, la fábrica se detiene; cuando el anfitrión cambia de ordenador, hay que trasladar la partida guardada; las actualizaciones, las copias de seguridad y las contraseñas de administración se acumulan en un ordenador personal. Una vez que despliegas un servidor dedicado en un VPS, el mundo puede funcionar las 24 horas, los jugadores pueden conectarse y construir en cualquier momento, y los administradores pueden organizar de forma independiente ventanas de mantenimiento, copias de seguridad y actualizaciones.
Este artículo toma como ejemplo un VPS Ubuntu 24.04 x86_64, usa el servidor Linux nativo oficial, SteamCMD y systemd, y recorre por completo la instalación, el reclamo del servidor, la apertura de los nuevos puertos, las copias de seguridad, la restauración y las actualizaciones automáticas. Primero, un aviso sobre el cambio que más fácilmente pilla a quien copia tutoriales antiguos: desde Satisfactory 1.0 ya no se usan los antiguos 15000/UDP y 15777/UDP; los valores predeterminados actuales requieren 7777/TCP, 7777/UDP y 8888/TCP.
La documentación oficial del servidor dedicado en la Wiki de la comunidad de Satisfactory indica que el Steam App ID del servidor es 1690800. Es compatible con Windows y Linux nativos de 64 bits, pero solo con x86-64, no con ARM.
A fecha de agosto de 2026, la plantilla de versión actual de la Wiki oficial muestra la rama predeterminada como 1.2.3.1. Este artículo no incluye el número de parche en el comando de instalación, porque SteamCMD descarga la versión estable actual desde la rama predeterminada; el comando seguirá funcionando para futuras actualizaciones menores.
| Elemento | Valor usado en este artículo |
|---|---|
| SteamCMD App ID | 1690800 |
| Sistema | Ubuntu 24.04 LTS x86_64 |
| Programa del servidor | FactoryServer.sh |
| Juego y consulta | 7777/UDP |
| API HTTPS | 7777/TCP |
| Mensajería fiable | 8888/TCP |
Antes de comprar un VPS, confirma la arquitectura en la consola:
uname -m
lscpu | grep -E 'Architecture|Model name|Virtualization'
uname -m debería mostrar x86_64. Si es aarch64 o arm64, aunque el sistema pueda instalar SteamCMD, no podrá ejecutar el servidor oficial directamente. La documentación oficial también señala específicamente que el modelo de CPU genérico kvm64 que exponen algunos VPS KVM puede impedir que el servidor arranque; en ese caso, pide al proveedor que cambie a host-passthrough, a un modelo de CPU x86-64 más reciente, o cambia directamente a una instancia que admita conjuntos de instrucciones modernos, en lugar de reinstalar el sistema una y otra vez.
La escala de las fábricas en Satisfactory crece continuamente, y las cintas transportadoras, los trenes, los drones y una gran cantidad de edificios aumentan la presión sobre la CPU y la memoria. La documentación oficial indica un mínimo de 8 GB de memoria y recomienda 16 GB para partidas guardadas grandes o más de 4 jugadores. Al comprar, también hay que dejar margen para Ubuntu, SteamCMD, la caché de archivos y las operaciones de mantenimiento.
| Caso de uso | Configuración inicial recomendada | Disco NVMe | Notas |
|---|---|---|---|
| 2–4 jugadores, partida nueva | 4 vCPU de alta frecuencia, 8 GB de memoria | 50 GB | Puede abrir el servidor, pero hay que vigilar la memoria antes de las fábricas grandes |
| 4–8 jugadores, partida a largo plazo | 4–6 vCPU de alta frecuencia, 16 GB de memoria | 80 GB | Más adecuado para funcionamiento a largo plazo y copias de seguridad en línea |
| Más de 8 jugadores o fábricas muy grandes | 6–8 vCPU de alta frecuencia, 16–32 GB de memoria | 100 GB+ | Requiere ampliar según los datos de monitorización |
Estos son puntos de partida prácticos, no garantías de número de jugadores ni de rendimiento. El servidor de Satisfactory valora mucho el rendimiento de un solo núcleo, así que no compares solo cifras de marketing como "8 núcleos" o "16 núcleos". Cuando la CPU compartida está muy sobrevendida, la carga total de la máquina puede parecer baja y el juego aun así mostrar rubber-banding, retrasos al construir y tirones en el autoguardado.
El centro de datos debe estar lo más cerca posible de los jugadores principales, y hay que confirmar que el proveedor permite servidores de juegos, admite UDP, tiene suficiente tráfico mensual y reglas claras de gestión de DDoS. Si aún no has elegido máquina, puedes consultar primero la configuración de VPS para servidores de juegos y selección de líneas de red.
Primero inicia sesión en el VPS por SSH, actualiza el sistema e instala las dependencias:
sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates tar lib32gcc-s1 lib32stdc++6 ufw
No ejecutes el servidor de juego como root a largo plazo. Crea un usuario de sistema sin privilegios de administrador y prepara los directorios de instalación y copias de seguridad:
sudo adduser --system --group \
--home /home/satisfactory \
--shell /bin/bash satisfactory
sudo install -d -o satisfactory -g satisfactory /opt/steamcmd
sudo install -d -o satisfactory -g satisfactory /opt/satisfactory
sudo install -d -m 750 -o root -g satisfactory /var/backups/satisfactory
Comprueba los directorios y el espacio en disco:
id satisfactory
df -h /opt /home /var/backups
sudo -u satisfactory test -w /opt/satisfactory && echo 'install dir writable'
Si /opt y /home están en el mismo disco de sistema pequeño, guardar las copias de seguridad en ese disco no te protegerá de que se elimine el VPS o de que falle el disco. Este artículo primero crea un punto de recuperación local, pero después hay que sincronizar las copias críticas a otra máquina o a almacenamiento de objetos.
Descarga la versión Linux de SteamCMD desde la CDN oficial de Valve:
sudo -u satisfactory curl -fsSL \
https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz \
-o /opt/steamcmd/steamcmd_linux.tar.gz
sudo -u satisfactory tar -xzf \
/opt/steamcmd/steamcmd_linux.tar.gz \
-C /opt/steamcmd
sudo -u satisfactory /opt/steamcmd/steamcmd.sh +quit
La primera ejecución actualiza el propio SteamCMD. Cuando termine, confirma la propiedad del script y del directorio:
ls -l /opt/steamcmd/steamcmd.sh
sudo -u satisfactory test -x /opt/steamcmd/steamcmd.sh \
&& echo 'steamcmd ready'
No descargues servidores empaquetados desde adjuntos de foros, discos en la nube o réplicas desconocidas. SteamCMD puede obtener directamente los archivos oficiales del servidor dedicado de forma anónima, así que no hay necesidad de poner una cuenta y contraseña personal de Steam en el VPS.
Usa el App ID 1690800 para instalar la rama predeterminada actual:
sudo -u satisfactory /opt/steamcmd/steamcmd.sh \
+force_install_dir /opt/satisfactory \
+login anonymous \
+app_update 1690800 validate \
+quit
Cuando termine la descarga, comprueba los archivos clave:
sudo -u satisfactory test -x /opt/satisfactory/FactoryServer.sh \
&& echo 'FactoryServer ready'
du -sh /opt/satisfactory
ls -l /opt/satisfactory/FactoryServer.sh
Si SteamCMD informa de espacio en disco insuficiente, no te limites a limpiar la caché de descarga y forzar la instalación. Las partidas guardadas, los registros y las futuras actualizaciones necesitan espacio adicional; primero amplía el disco y asegúrate de que tampoco se agoten los inodos:
df -h
df -i
Antes de configurar systemd formalmente, arráncalo una vez en primer plano para ver los errores directamente:
sudo -u satisfactory env HOME=/home/satisfactory \
/opt/satisfactory/FactoryServer.sh \
-Port=7777 \
-ReliablePort=8888
El primer arranque necesita generar el directorio de configuración e inicializar el servicio, lo que puede tardar unos minutos. No lo fuerces a terminar solo porque la terminal no muestra nueva salida temporalmente. En otra ventana SSH, comprueba el proceso y los puertos a la escucha:
pgrep -af FactoryServer
sudo ss -lntup | grep -E ':7777|:8888'
curl -k https://127.0.0.1:7777
Deberían aparecer TCP y UDP de 7777, y TCP de 8888. Que curl devuelva que no encuentra la ruta de API correspondiente, un error HTTP o un error JSON no significa necesariamente un fallo; siempre que se complete la conexión TLS y se reciba una respuesta del servidor, la API HTTPS local está escuchando.
Cuando confirmes que el arranque fue correcto, pulsa Ctrl+C en la terminal que ejecuta el servidor. La versión Linux recibe SIGINT y sale normalmente. La documentación oficial advierte: una salida normal no equivale a un autoguardado; antes de futuros mantenimientos, guarda primero en el juego o en Server Manager y luego detén el servidor.
Los puertos predeterminados actuales de Satisfactory son los siguientes:
| Puerto | Protocolo | Uso | Entrada pública |
|---|---|---|---|
7777 | UDP | Tráfico de juego y consulta | Obligatorio |
7777 | TCP | API HTTPS | Obligatorio |
8888 | TCP | Canal de mensajería fiable | Obligatorio |
Primero asegúrate de que existe la regla SSH y luego habilita UFW:
sudo ufw allow OpenSSH
sudo ufw allow 7777/udp comment 'Satisfactory game and query'
sudo ufw allow 7777/tcp comment 'Satisfactory HTTPS API'
sudo ufw allow 8888/tcp comment 'Satisfactory reliable messaging'
sudo ufw enable
sudo ufw status numbered
Después ve al grupo de seguridad o firewall en la nube de la consola del proveedor del VPS y añade exactamente las mismas tres reglas de entrada. El UFW del sistema y el grupo de seguridad en la nube son dos capas de filtrado; si falta cualquiera de las dos, puede ocurrir que "el proceso esté bien pero el exterior no pueda conectarse". Puedes revisarlo capa por capa con la lista de comprobación de puertos, firewall y grupos de seguridad.
No sigas copiando las reglas 15000/UDP y 15777/UDP anteriores a 1.0; ya no se usan. Tampoco abras todos los puertos TCP/UDP para ahorrarte trabajo.
Si un VPS ejecuta varias instancias de Satisfactory, puedes cambiar los puertos, por ejemplo:
/opt/satisfactory/FactoryServer.sh \
-Port=7778 \
-ReliablePort=8889
El puerto público del Port estándar debe coincidir con el puerto de escucha del servidor; no puedes limitarte a usar NAT normal para redirigir el 7778 externo al 7777 interno a voluntad. Si realmente necesitas mapear externamente el puerto de mensajería fiable, usa entonces -ExternalReliablePort según la documentación oficial y actualiza el firewall en consecuencia.
Después de que el servidor se ejecute correctamente por primera vez, abre el cliente de Satisfactory y entra en Server Manager desde el menú principal:
- Elige añadir un servidor e introduce la IP pública del VPS y el puerto predeterminado
7777. - La primera conexión te pedirá reclamar el servidor; establece el nombre del servidor y la contraseña de administrador.
- La contraseña de administrador debe ser aleatoria y única; no reutilices la contraseña de SSH, correo o Steam.
- Crea una partida nueva o importa una partida guardada
.savexistente. - En la configuración del servidor, confirma el intervalo de autoguardado, el guardado al desconectarse y la carga automática de la sesión.
- Si quieres un servidor privado, establece también una contraseña de conexión para jugadores y compártela solo por canales privados.
La configuración de administración del servidor se guarda en una ubicación similar a la siguiente, donde PORT se sustituye por el puerto que realmente usa la instancia:
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/ServerSettings.PORT.sav
El directorio de partidas guardadas del servidor Linux es:
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
Al importar una partida antigua, detén primero el servidor y luego copia el archivo .sav como el usuario satisfactory, para evitar que la propiedad de root impida que el juego lo lea:
sudo systemctl stop satisfactory 2>/dev/null || true
sudo install -d -o satisfactory -g satisfactory \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
sudo cp /path/to/your-save.sav \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server/
sudo chown satisfactory:satisfactory \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server/your-save.sav
Sustituye /path/to/your-save.sav por la ruta real del archivo. Después de arrancar, elige cargar esa partida en Server Manager; no edites directamente los binarios .sav o ServerSettings.PORT.sav.
Cuando el arranque en primer plano, los puertos y el reclamo estén confirmados como correctos, crea /etc/systemd/system/satisfactory.service:
[Unit]
Description=Satisfactory dedicated server
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=satisfactory
Group=satisfactory
Environment=HOME=/home/satisfactory
WorkingDirectory=/opt/satisfactory
ExecStartPre=/opt/steamcmd/steamcmd.sh +force_install_dir /opt/satisfactory +login anonymous +app_update 1690800 validate +quit
ExecStart=/opt/satisfactory/FactoryServer.sh -Port=7777 -ReliablePort=8888
Restart=on-failure
RestartSec=60
KillSignal=SIGINT
TimeoutStopSec=180
[Install]
WantedBy=multi-user.target
Esta configuración se basa en la guía de la Wiki oficial para ejecutar como servicio systemd y establece explícitamente HOME para garantizar que las partidas guardadas queden en el directorio esperado del usuario del servicio.
Recarga systemd e inicia:
sudo systemctl daemon-reload
sudo systemctl enable --now satisfactory
sudo systemctl status satisfactory --no-pager
sudo journalctl -u satisfactory -n 100 --no-pager
ExecStartPre ejecuta SteamCMD antes de cada arranque del servicio, por lo que al reiniciar el servicio se comprueban primero las actualizaciones. Esto es cómodo para el mantenimiento, pero si el servicio se bloquea repetidamente por un error, la comprobación de actualizaciones también se ejecutará de nuevo antes de cada reinicio. No cambies RestartSec a unos segundos, y no uses un bucle rápido infinito para ocultar un fallo real.
Ver registros en tiempo real:
sudo journalctl -u satisfactory -f
Los registros propios del juego suelen estar en:
/opt/satisfactory/FactoryGame/Saved/Logs
Si systemd muestra active (running) pero los jugadores siguen sin poder unirse, revisa primero en los registros si se completó la carga del mundo y luego comprueba si los tres puertos están escuchando a la vez. No juzgues que el mundo del juego es conectable solo por el estado del proceso.
No ejecutes app_update directamente mientras el proceso del servidor está en ejecución. El error de actualización 0x606 que aparece en la documentación oficial suele deberse a que un FactoryServer en ejecución ocupa los archivos que se van a reemplazar.
El proceso de actualización seguro es:
- Guarda manualmente en Server Manager o en el juego, por ejemplo como
before-update. - Avisa a los jugadores para que se desconecten y espera a que termine el guardado.
- Detén el servicio.
- Ejecuta la actualización de SteamCMD y valida.
- Reinicia y comprueba los registros y la versión.
Los comandos son los siguientes:
sudo systemctl stop satisfactory
sudo -u satisfactory env HOME=/home/satisfactory \
/opt/steamcmd/steamcmd.sh \
+force_install_dir /opt/satisfactory \
+login anonymous \
+app_update 1690800 validate \
+quit
sudo systemctl start satisfactory
sudo journalctl -u satisfactory -n 100 --no-pager
Como la unidad systemd de este artículo ya incluye ExecStartPre, después de ejecutar SteamCMD manualmente, systemctl start volverá a comprobar una vez, lo que normalmente termina rápido. También puedes, tras guardar, ejecutar directamente sudo systemctl restart satisfactory y dejar que systemd actualice automáticamente después de detener el servicio.
Antes de una actualización de versión mayor, no dependas de una sola copia de seguridad local. Consulta primero las notas de parche oficiales y los problemas conocidos de la comunidad, conserva una copia de la partida que permita revertir y luego programa una ventana de mantenimiento.
El directorio principal que hay que respaldar no es el de instalación, sino Saved dentro del HOME del usuario del servicio:
sudo -u satisfactory find \
/home/satisfactory/.config/Epic/FactoryGame/Saved \
-maxdepth 3 -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n' \
| tail -n 30
Antes del mantenimiento, guarda primero en el juego, luego detén el servidor y crea un archivo comprimido con marca de tiempo:
sudo systemctl stop satisfactory
backup_stamp=$(date +%Y%m%d-%H%M%S)
sudo tar \
-C /home/satisfactory/.config/Epic/FactoryGame \
-czf "/var/backups/satisfactory/satisfactory-${backup_stamp}.tar.gz" \
Saved
sudo systemctl start satisfactory
sudo ls -lh /var/backups/satisfactory
Comprueba por muestreo que el archivo comprimido se puede leer:
latest_backup=$(sudo find /var/backups/satisfactory \
-maxdepth 1 -type f -name 'satisfactory-*.tar.gz' \
-print | sort | tail -n 1)
sudo tar -tzf "$latest_backup" | head -n 30
Se recomienda conservar al menos "las últimas 7 copias diarias y las últimas 4 copias semanales", y sincronizar copias a un dominio de fallo distinto del VPS. Para scripts de copia de seguridad, almacenamiento de objetos y simulacros de restauración, consulta la guía de estrategia de copias de seguridad de VPS.
La restauración reemplaza el Saved actual, así que primero haz otra instantánea del estado actual:
sudo systemctl stop satisfactory
restore_stamp=$(date +%Y%m%d-%H%M%S)
sudo mv \
/home/satisfactory/.config/Epic/FactoryGame/Saved \
"/home/satisfactory/.config/Epic/FactoryGame/Saved.before-restore-${restore_stamp}"
sudo -u satisfactory tar \
-C /home/satisfactory/.config/Epic/FactoryGame \
-xzf /var/backups/satisfactory/satisfactory-YYYYMMDD-HHMMSS.tar.gz
sudo chown -R satisfactory:satisfactory \
/home/satisfactory/.config/Epic/FactoryGame/Saved
sudo systemctl start satisfactory
sudo journalctl -u satisfactory -n 100 --no-pager
Sustituye el nombre del archivo por la copia de seguridad real que quieras restaurar. Después de arrancar, que el administrador entre primero en Server Manager para confirmar la sesión, la hora del guardado y la configuración del servidor, y luego deja que se unan los demás jugadores.
Revisa primero los registros completos, en lugar de ejecutar systemctl restart repetidamente:
sudo systemctl status satisfactory --no-pager -l
sudo journalctl -u satisfactory -b --no-pager
find /opt/satisfactory/FactoryGame/Saved/Logs \
-maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n' \
| sort | tail
Confirma que el sistema es x86_64, que el OOM Killer no ha matado la memoria, que la propiedad de los directorios es correcta, y comprueba si el VPS usa un modelo de CPU kvm64 con problemas de compatibilidad:
uname -m
lscpu | grep 'Model name'
sudo journalctl -k | grep -i -E 'out of memory|killed process|oom'
sudo chown -R satisfactory:satisfactory \
/opt/satisfactory /home/satisfactory
Primero confirma la escucha local:
sudo ss -lntup | grep -E ':7777|:8888'
sudo ufw status numbered
curl -k https://127.0.0.1:7777
Luego comprueba si están las tres reglas del grupo de seguridad en la nube. El error más común es abrir solo 7777/UDP y omitir 7777/TCP o 8888/TCP; otro error común es seguir tutoriales antiguos y abrir solo 15777/UDP y 15000/UDP.
Primero confirma que el servicio se ha detenido realmente:
sudo systemctl stop satisfactory
pgrep -af FactoryServer || echo 'server stopped'
sudo -u satisfactory /opt/steamcmd/steamcmd.sh \
+force_install_dir /opt/satisfactory \
+login anonymous \
+app_update 1690800 validate \
+quit
Si todavía ves el proceso FactoryServer, no ejecutes kill -9 directamente. Averigua primero si lo inició otra terminal, un script o una unidad systemd duplicada, y envía SIGINT de la forma correspondiente para terminarlo normalmente.
Comprueba si el archivo está en el directorio correcto del servidor Linux, si la extensión es .sav y si el propietario es satisfactory:
sudo -u satisfactory find \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server \
-maxdepth 1 -type f -name '*.sav' -ls
Si el archivo pertenece a root, corrige la propiedad, reinicia el servicio y luego elige cargarlo en Server Manager. No sobrescribas la partida guardada activa mientras el servidor está en ejecución.
Registra datos antes de ampliar el plan:
free -h
uptime
vmstat 1 10
pid=$(pgrep -n FactoryServer-Linux-Shipping || pgrep -n FactoryServer)
ps -p "$pid" -o pid,%cpu,%mem,rss,etime,cmd
Si un solo vCPU está cerca de la carga máxima durante mucho tiempo, prioriza cambiar a una instancia con mayor rendimiento de un solo núcleo; si la memoria disponible es muy baja y hay swapping continuo, añade memoria. Cuando la espera de disco sea alta, comprueba el rendimiento del NVMe y si las tareas de copia de seguridad se solapan con los autoguardados. Los servidores a largo plazo pueden integrar monitorización de VPS con Prometheus y Grafana para observar las tendencias de CPU, memoria, disco y red.
uname -mesx86_64, y la CPU no es un modelo antiguokvm64con riesgos de compatibilidad.- SteamCMD usa el App ID del servidor dedicado
1690800, no el App ID del cliente del juego. - El servicio se ejecuta con un usuario
satisfactoryindependiente, no con root. 7777/TCP,7777/UDPy8888/TCPestán permitidos tanto en UFW como en el grupo de seguridad en la nube.- El servidor se ha reclamado en Server Manager y se ha establecido una contraseña de administrador única.
- El autoguardado, el guardado al desconectarse y la carga automática de la sesión están configurados según las necesidades.
- systemd puede arrancar al inicio,
KillSignal=SIGINT, y los registros no muestran un bucle de bloqueos persistente. - Antes de actualizar se guarda y se detiene el servicio, y no se ejecuta SteamCMD con FactoryServer en ejecución.
- Se ha completado una prueba de lectura de copia de seguridad y se ha copiado al menos una copia fuera del sitio.
- Se ha probado realmente a unirse, salir y reconectar desde un cliente externo, y se ha confirmado que el progreso más reciente sigue existiendo.
Solo después de completar estas comprobaciones este VPS pasa de "puede arrancar" a "mantenible a largo plazo". Para un servidor de juego como Satisfactory, cuyas partidas guardadas no dejan de crecer, una CPU estable, los nuevos puertos correctos, copias de seguridad verificables y un mantenimiento con ritmo importan mucho más que conseguir que el programa se ejecute una vez.