Come creare un server Factorio: guida completa alla

Q: Come rendo pubblico il mio server Factorio?

Devi impostare public su true in server-settings.json e fornire un token generato dal tuo account Factorio, oltre ad aprire la porta UDP 34197 sul firewall.

Scopri come creare un server Factorio perfetto con la nostra guida completa. Configura, gestisci e inizia a giocare con amici! Molto semplice.

Per mettere online un server Factorio headless funzionante scarica il pacchetto ufficiale da factorio.com, crea o riusa un save .zip con l’opzione --create, configura server-settings.json con i parametri essenziali, apri la porta UDP 34197 sul firewall e avvia il binario direttamente o tramite un servizio systemd per la gestione automatica.

In breve:

Per un server di 2-4 giocatori sono sufficienti 2-4 GB di RAM e un processore con alto clock su singolo core.

La porta UDP 34197 deve essere aperta sul firewall e inoltrata correttamente per consentire connessioni esterne, verificando con strumenti come nmap.

La sincronizzazione tra mod client e server è essenziale; eventuali versioni diverse causano il rifiuto della connessione.

La gestione automatica tramite systemd garantisce riavvii e monitoraggio continuo, riducendo i rischi di crash o interruzioni non pianificate.

Un backup regolare, con autosave e rotazione esterna, evita perdita di progressi in caso di malfunzionamenti o aggiornamenti.

Indice

Requisiti minimi e consigliati per creare server Factorio
Scaricare e installare il server headless su Linux
Configurare server-settings.json e le impostazioni della mappa
Avviare e gestire il server: script e systemd
Come aprire la porta 34197 e gestire il firewall
RCON, adminlist e sicurezza del server
Gestire mod e salvataggi senza rompere la partita
Backup, aggiornamenti e manutenzione periodica
UPS basso e crash: come diagnosticare e risolvere
Come proteggere il server da accessi non autorizzati
Latenza e connessione tra client e server
Ruoli, permessi e gestione avanzata degli utenti
Il punto di vista: quando conviene il fai da te e quando no
Configurare un server Factorio con AtomSync senza toccare Linux
Fonti
Domande frequenti

Requisiti minimi e consigliati per creare server Factorio

La scelta tra una macchina fisica in casa e un VPS dipende quasi sempre da quanti giocatori vuoi ospitare e da quanto grande diventerà la fabbrica nel tempo. Un server per 2-4 amici ha esigenze completamente diverse da uno pubblico con 20 persone e una megabase da centinaia di migliaia di entità.

Prima di tutto serve un account Factorio valido: il download della build headless per Linux richiede l’autenticazione, e se vuoi rendere il server visibile pubblicamente nella lista server ufficiale ti servirà anche un token generato dall’account.

Sul fronte hardware, la community consiglia di partire con una configurazione conservativa e scalare solo se necessario, secondo le indicazioni raccolte sui forum ufficiali:

RAM: 2-4 GB per partite fino a 4 giocatori, 4-6 GB per gruppi da 5 a 20 persone, una quantità maggiore di RAM per megabase di grandi dimensioni con molte entità attive.
CPU: privilegia un processore con elevato clock su singolo core in quanto la simulazione principale è single-threaded.
Storage: preferibile un’unità SSD per migliorare i tempi di salvataggio soprattutto per mappe di grandi dimensioni.
Sistema operativo: Debian o Ubuntu restano le scelte più testate dalla community per l’headless Linux.
Dipendenze software: curl o wget per il download, tar e xz-utils per l’estrazione, jq se vuoi manipolare i file JSON da script.

Un consiglio pratico: il motore di simulazione di Factorio gira su un singolo thread. Significa che una CPU con clock a 4,5 GHz supera quasi sempre, in termini di prestazioni reali (misurate in UPS, update per second), un processore con più core ma clock più basso, come confermano le linee guida tecniche sul dimensionamento delle risorse.

Il numero di giocatori simultanei pesa meno sulle risorse rispetto alla complessità della fabbrica stessa: una base con migliaia di inserter e circuiti attivi consuma più CPU di venti giocatori che si limitano a costruire senza automazione spinta.

Scaricare e installare il server headless su Linux

Il pacchetto headless si scarica dal sito ufficiale e va estratto in una struttura di cartelle ordinata prima di procedere con qualsiasi configurazione. Ecco i passaggi concreti.

Scarica l’archivio ufficiale. Da terminale, usa il comando wget https://factorio.com/get-download/stable/headless/linux64 per ottenere l’ultima build stabile, come indicato nella documentazione ufficiale per l’installazione headless su Linux. Se preferisci curl, aggiungi il flag -L per seguire i redirect.
Estrai l’archivio tar.xz. Il file scaricato è compresso in formato .tar.xz, quindi serve il pacchetto xz-utils installato sul sistema. Il comando tar -xJf factorio_headless_x64_2.0.tar.xz crea automaticamente una cartella factorio/ con i binari e le risorse di gioco.
Organizza la struttura delle cartelle. Dentro factorio/ troverai già bin/, data/ e una cartella vuota saves/. Crea manualmente anche config/ per i file di impostazioni e logs/ se vuoi separare l’output degli errori dal terminale. Verifica i permessi con chmod +x bin/x64/factorio per rendere eseguibile il binario.
Controlla la versione installata. Esegui ./bin/x64/factorio --version per confermare che l’estrazione sia andata a buon fine e che la build corrisponda a quella desiderata. Questo passaggio evita sorprese quando client e server devono avere versioni identiche per connettersi.
Crea il primo salvataggio se non ne hai già uno. Il server headless non parte senza un file .zip di salvataggio nella cartella saves/: usa ./bin/x64/factorio --create saves/mondo.zip per generare una mappa nuova con i parametri di default, oppure specifica un file map-gen-settings.json personalizzato, come previsto dalla documentazione ufficiale sul multiplayer.

Su Windows la procedura cambia poco nella sostanza: scarichi l’archivio .zip invece del .tar.xz, lo estrai con Esplora Risorse o 7-Zip, e lanci factorio.exe dal prompt dei comandi con gli stessi argomenti (--create, --start-server). La differenza principale riguarda il firewall di Windows, che richiede un’eccezione manuale per la porta UDP, e l’assenza nativa di systemd, che su Windows va sostituito con Task Scheduler o con un servizio NSSM se vuoi l’avvio automatico.

Configurare server-settings.json e le impostazioni della mappa

Il file server-settings.json controlla il comportamento del server a livello di rete e community, mentre map-gen-settings.json e map-settings.json definiscono come nasce e si comporta il mondo di gioco. Sono tre file distinti, spesso confusi tra loro, e ognuno merita attenzione separata.

I campi più importanti di server-settings.json includono:

name: il nome visibile nella lista server pubblica, se scegli quella modalità.
description: una breve presentazione visibile ai giocatori prima di connettersi.
visibility: un oggetto con le chiavi public, lan e la possibilità di renderlo invisibile impostando entrambe su false per un server privato raggiungibile solo via IP diretto.
token o username/password: credenziali dell’account Factorio necessarie solo se public è impostato su true.
admins: un array con i nomi utente che avranno permessi amministrativi in gioco.
autosave_interval: la frequenza in minuti tra un salvataggio automatico e il successivo.
autosave_slots: quanti file di autosave mantenere prima che i più vecchi vengano sovrascritti.
max_players: il tetto massimo di giocatori simultanei, utile per contenere il carico sulla CPU.

Un consiglio pratico: se non ti serve la visibilità pubblica, lascia public su false e condividi semplicemente l’IP con il tuo gruppo. Eviti il passaggio del token e riduci la superficie di attacco esposta, perché il server non compare nella lista ufficiale consultabile da chiunque.

Sul fronte della generazione del mondo, map-gen-settings.json gestisce il seed (il numero che determina la mappa generata), la frequency e size delle risorse minerarie, la richness che ne definisce la quantità per singolo giacimento, e la distribuzione di acqua e terreno. Un seed fisso permette di rigenerare esattamente la stessa mappa su un altro server, utile per test o migrazioni.

Mani che modificano le impostazioni di generazione della mappa

map-settings.json, invece, controlla parametri di gameplay come l’aggressività degli enemy (la curva di evoluzione dei biter) e i livelli di pollution che influenzano quanto velocemente il tuo inquinamento attira attacchi. Per un server cooperativo tranquillo, molti gruppi riducono l’aggressività dei nemici modificando enemy_evolution.time_factor.

Tutti questi file vanno collocati nella cartella config/ creata in precedenza, e vanno richiamati esplicitamente al momento dell’avvio con il flag --server-settings. Il pacchetto headless include anche file d’esempio (server-settings.example.json) che puoi copiare e modificare invece di scrivere tutto da zero.

Avviare e gestire il server: script e systemd

Una volta pronti i file di configurazione, il server si avvia con un comando diretto che richiama sia il salvataggio sia le impostazioni.

Avvio manuale con --start-server. Il comando base è ./bin/x64/factorio --start-server saves/mondo.zip --server-settings config/server-settings.json, come indicato nella guida pratica per l’installazione Linux. Puoi aggiungere --map-gen-settings e --map-settings se vuoi passare file separati invece di quelli embedded nel save.
Testa con screen o tmux per sessioni temporanee. Se non vuoi ancora configurare systemd, screen -S factorio seguito dal comando di avvio ti permette di scollegare il terminale senza chiudere il processo. È comodo per test rapidi, meno adatto a un server che deve restare online settimane intere.
Scrivi uno script wrapper. Un file start.sh con permessi eseguibili (chmod +x start.sh) che richiama il binario con tutti i parametri evita errori di digitazione e rende più semplice l’integrazione con systemd.
Configura un unit file systemd. Per l’automazione vera, systemd offre vantaggi concreti in termini di riavvio automatico e gestione dei log rispetto a una sessione screen lasciata aperta manualmente. Un file tipico in /etc/systemd/system/factorio.service contiene:

[Unit]
Description=Factorio headless server
After=network.target

[Service]
Type=simple
User=factorio
WorkingDirectory=/home/factorio/factorio
ExecStart=/home/factorio/factorio/bin/x64/factorio --start-server /home/factorio/factorio/saves/mondo.zip --server-settings /home/factorio/factorio/config/server-settings.json
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Attiva e avvia il servizio. I comandi sudo systemctl enable factorio e sudo systemctl start factorio registrano il server per l’avvio automatico al boot e lo mettono online subito. Per controllare i log in tempo reale usa journalctl -u factorio -f, molto più pratico che scorrere un terminale screen.

Restart=on-failure è la riga che fa davvero la differenza: se il processo crasha per un mod incompatibile o una memoria insufficiente, systemd lo rialza da solo senza che tu debba intervenire manualmente nel cuore della notte.

Come aprire la porta 34197 e gestire il firewall

Factorio comunica di default sulla porta UDP 34197, e senza aprirla correttamente nessun giocatore esterno alla tua rete locale potrà connettersi, come specificato nella documentazione ufficiale sull’installazione headless.

Verifica prima che il server stia effettivamente ascoltando su quella porta con ss -ulnp | grep 34197 (o netstat -ulnp su sistemi più vecchi). Se non compare nulla, il problema è nel server prima ancora che nella rete.

Sul firewall della macchina, i comandi cambiano leggermente in base allo strumento:

UFW (Ubuntu/Debian): apri la porta UDP 34197 sul firewall per permettere le connessioni esterne al server. Questa apertura è permanente.
iptables: sudo iptables -A INPUT -p udp --dport 34197 -j ACCEPT fa lo stesso lavoro su distribuzioni senza UFW.
Router domestico: se il server gira su una macchina in casa, serve anche il port forwarding sul router, indirizzando il traffico UDP 34197 verso l’IP locale della macchina.
Verifica esterna: uno strumento come nmap -sU -p 34197 il-tuo-ip-pubblico da un’altra rete confirma se la porta è realmente raggiungibile da fuori.

Quando il port forwarding non è un’opzione, per esempio dietro un CGNAT del provider internet o su una rete aziendale bloccata, restano due strade praticabili: una VPN che assegna un IP pubblico dedicato al server, oppure un hosting professionale che gestisce la rete a monte senza che tu debba toccare configurazioni di router. Alcuni gruppi con più server preferiscono anche pubblicare un record DNS SRV per associare un dominio leggibile all’IP e alla porta, evitando di condividere numeri IP grezzi con la community.

RCON, adminlist e sicurezza del server

RCON è la console remota che permette di inviare comandi al server senza essere connessi come giocatore in partita, utile per bannare qualcuno, cambiare impostazioni al volo o riavviare in sicurezza.

Si attiva con i flag --rcon-port e --rcon-password all’avvio del server: la password va scelta lunga e casuale, non riciclata da altri account, perché un RCON esposto senza protezione equivale a lasciare le chiavi del server a chiunque scansioni la porta.

La gestione dei permessi passa da tre file JSON distinti nella cartella principale del server:

adminlist.json: un array di nomi utente con privilegi amministrativi, che possono usare comandi speciali in chat e gestire altri giocatori.
whitelist.json: se popolato, solo i nomi presenti possono connettersi, utile per server privati chiusi a una community specifica.
ban-list.json: nomi o identificativi bloccati permanentemente dal server.

Tra le impostazioni di sicurezza consigliate in server-settings.json, require_user_verification impedisce a client con account Factorio non verificato di connettersi, riducendo il rischio di account fake usati per disturbare la partita. only_admins_can_pause_the_game evita che un singolo giocatore blocchi l’intera sessione per errore o per dispetto.

Un consiglio pratico: ruota la password RCON periodicamente, soprattutto se l’hai condivisa con collaboratori che potrebbero non servire più il server. Controlla anche i log regolarmente: un pattern di tentativi di connessione RCON falliti ripetuti da IP sconosciuti è il primo segnale di uno scan automatizzato contro la tua porta.

Gestire mod e salvataggi senza rompere la partita

Le mod si scaricano da mods.factorio.com e vanno posizionate nella cartella mods/ della directory principale del server, insieme al file mod-list.json che elenca quali sono attive.

Il punto critico riguarda la sincronizzazione tra client e server: se un giocatore ha una versione diversa della stessa mod rispetto al server, la connessione viene rifiutata. Prima di installare mod in produzione conviene testarle su una copia del mondo, evitando di rischiare corruzioni sul salvataggio principale usato dalla community, secondo le indicazioni della documentazione ufficiale.

Una routine solida prevede questi passaggi:

Copia il file .zip del save corrente in una cartella di backup prima di qualsiasi modifica.
Installa la mod nuova solo sul server, poi verifica che il manifest della versione coincida con quello che i giocatori dovranno scaricare.
Avvia il server con la mod attiva su un save di test, non su quello principale, per controllare crash o incompatibilità.
Solo dopo aver confermato la stabilità, applica la stessa mod al save di produzione e comunica ai giocatori quale versione scaricare.
Se qualcosa va storto, il rollback consiste semplicemente nel ripristinare il backup fatto al primo passaggio.

Questa disciplina richiede pochi minuti in più ma evita ore perse a recuperare un mondo corrotto da una mod che modificava la struttura dei dati salvati in modo incompatibile con la versione precedente.

Backup, aggiornamenti e manutenzione periodica

Un server che gira per mesi senza backup automatizzati è una scommessa che prima o poi si perde: un crash, un aggiornamento andato male o una mod difettosa possono cancellare centinaia di ore di progressi in pochi secondi.

Configura gli autosave nativi. In server-settings.json, autosave_interval definisce ogni quanti minuti il gioco salva automaticamente, mentre autosave_slots controlla quante copie mantenere in rotazione prima di sovrascrivere le più vecchie.
Aggiungi un backup esterno via cron. Un job cron con rsync che copia periodicamente la cartella saves/ e config/ verso un’altra macchina o uno storage remoto protegge anche da un guasto hardware totale sulla macchina principale.
Usa gli snapshot del provider prima di aggiornamenti importanti. Se il server gira su un VPS, uno snapshot completo della macchina prima di un aggiornamento di versione o di una mod importante permette un rollback immediato in caso di problemi, come raccomandato nelle linee guida per il deploy su VPS.
Testa periodicamente l’integrità dei backup. Un backup che non hai mai provato a ripristinare non è garanzia di nulla: prova a caricare un vecchio save su un’istanza separata almeno una volta ogni tanto per verificare che il file non sia corrotto.

Molti gruppi sottovalutano quanto tempo richieda ricreare a mano una fabbrica complessa, e proprio per questo un backup esterno alla macchina di gioco è la parte più trascurata dell’intera manutenzione. Trovi esempi pratici di script di backup e rotazione anche nella guida al backup dei mondi Minecraft, che segue una logica applicabile con pochi adattamenti anche a Factorio.

UPS basso e crash: come diagnosticare e risolvere

L’UPS (update per second) è l’equivalente Factorio del framerate: il gioco punta a 60 UPS, e quando scende sotto quella soglia la simulazione rallenta visibilmente per tutti i giocatori connessi.

Il motivo principale dietro un UPS basso è quasi sempre la CPU, non la RAM: dato che la simulazione principale gira su singolo thread, la soluzione più efficace è quasi sempre una CPU con clock più alto piuttosto che più core, come emerge dalle analisi tecniche sul dimensionamento delle risorse.

Per diagnosticare un calo di prestazioni:

Controlla htop mentre il server è sotto carico: se un singolo core è al 100% e gli altri sono quasi inattivi, hai la conferma che il collo di bottiglia è il clock, non il numero di core.
Guarda i log del server per errori ripetuti legati a mod specifiche, spesso la causa di crash improvvisi più che di semplice lag.
Osserva la mappa in gioco: una densità altissima di inserter, circuiti logici o treni può far crollare l’UPS anche su hardware potente.

Gli interventi pratici includono ridurre il numero di entità attive nelle zone più dense, disattivare temporaneamente mod pesanti per isolare la causa, o dividere logicamente la produzione in settori più semplici da gestire dal motore di gioco. Se dopo questi passaggi l’UPS resta basso in modo costante, il problema è quasi sempre hardware: serve una CPU più veloce, non necessariamente più RAM.

Un consiglio pratico: se stai valutando se aumentare le risorse della tua macchina attuale o migrare del tutto verso un hosting professionale, guarda quante ore a settimana dedichi già a diagnosticare problemi come questo. Spesso il tempo perso vale più del costo di un piano gestito.

Come proteggere il server da accessi non autorizzati

La sicurezza di un server Factorio si gioca soprattutto su due fronti: chi può connettersi e chi può controllare il server da remoto. Un server pubblico senza require_user_verification attivo accetta chiunque affermi di avere un certo nome utente, anche senza un account Factorio reale dietro.

Oltre alla verifica dell’account, limitare max_players evita che il server venga sommerso da connessioni indesiderate durante picchi di traffico o tentativi di disturbo coordinato. Combinare whitelist e adminlist resta la protezione più solida per community private: solo chi è già nell’elenco può entrare, e solo gli admin possono modificare impostazioni critiche in gioco.

Sul fronte della cifratura, il traffico di gioco tra client e server Factorio non è cifrato allo stesso modo di un canale HTTPS: la protezione principale riguarda l’accesso alla macchina stessa, non il traffico di gioco in sé. Questo significa che la sicurezza vera si costruisce a livello di sistema operativo: aggiornamenti regolari del server Linux, chiavi SSH invece di password per l’accesso alla macchina, e un firewall che espone solo le porte strettamente necessarie (34197 per il gioco, la porta RCON solo se davvero serve accesso remoto).

Anche la password RCON merita lo stesso livello di attenzione di una password di accesso SSH: lunga, generata casualmente, mai condivisa in chat pubbliche o salvata in file non protetti. Un server che gira su una macchina con altri servizi esposti (siti web, altri giochi) va isolato quando possibile, per evitare che una vulnerabilità altrove comprometta anche il mondo di Factorio.

Latenza e connessione tra client e server

La qualità della connessione tra client e server Factorio dipende da tre fattori principali: la distanza geografica tra giocatori e server, la stabilità della banda disponibile, e il carico della simulazione stessa sul lato server.

A differenza di molti giochi multiplayer, Factorio è relativamente tollerante alla latenza perché il motore usa un sistema di sincronizzazione deterministico: tutti i client calcolano la stessa simulazione partendo dagli stessi input, non riceve semplicemente uno stream di posizioni come in un FPS. Questo significa che una latenza di 100-150 millisecondi resta giocabile, mentre un UPS basso sul server danneggia l’esperienza per tutti contemporaneamente, indipendentemente dalla loro connessione individuale.

Per minimizzare i problemi di connessione, scegli un server geograficamente vicino alla maggioranza dei giocatori: un gruppo tutto europeo su un server negli Stati Uniti sentirà una latenza costante che un hosting più vicino eliminerebbe alla radice. Anche la qualità della connessione internet del server conta: un VPS con una rete instabile causa desync percepibili come scatti improvvisi nel movimento, anche con hardware potente.

Se un singolo giocatore ha problemi di connessione ricorrenti mentre gli altri no, il problema è quasi sempre locale al suo client o alla sua rete, non al server. Verifica separatamente la connessione di quel giocatore prima di intervenire su impostazioni server che funzionano bene per tutti gli altri: cambiare configurazioni globali per un problema individuale spesso peggiora l’esperienza di chi non aveva difficoltà.

Latenza e connessione tra client e server — overview diagram

Ruoli, permessi e gestione avanzata degli utenti

Oltre alla distinzione base tra admin e giocatori normali, Factorio permette una gestione dei permessi più granulare attraverso il sistema di gruppi di permessi integrato nel gioco, configurabile direttamente dalla console in partita o via comandi RCON.

I gruppi di permessi funzionano come ruoli personalizzabili: puoi creare un gruppo “moderatore” che può bannare giocatori e modificare alcune impostazioni ma non può cambiare la configurazione server, distinto dal gruppo “admin” con controllo completo. Questo livello intermedio è utile per community più grandi dove non vuoi dare accesso amministrativo pieno a tutti i collaboratori di fiducia.

La combinazione pratica più comune per server con più di dieci giocatori attivi prevede tre livelli: giocatori normali senza restrizioni particolari sul gameplay, un gruppo con permessi limitati per moderare la chat e gestire ban temporanei, e gli admin veri con accesso completo a adminlist.json e ai comandi di sistema via RCON.

Per community numerose, vale la pena documentare chi ha quale ruolo in un posto visibile, magari un canale Discord dedicato, così da evitare confusione su chi può intervenire in caso di problemi mentre il responsabile principale non è online. Un turnover regolare dei permessi, rimuovendo admin che non sono più attivi nella community, riduce anche il rischio di credenziali dimenticate che restano valide più a lungo del necessario.

Il punto di vista: quando conviene il fai da te e quando no

Gestire un server Factorio da soli insegna moltissimo su reti, systemd e gestione dei processi Linux, ed è un’esperienza che consiglio a chiunque abbia tempo e curiosità tecnica. Ma c’è una differenza enorme tra “far funzionare il server una volta” e “mantenerlo stabile per mesi con giocatori che si aspettano zero interruzioni”.

Il vero costo del fai da te non è il tempo di setup iniziale, è la manutenzione ricorrente: monitorare l’UPS, applicare aggiornamenti senza rompere le mod, gestire backup che funzionino davvero al momento del ripristino. Un VPS autogestito resta la scelta giusta se vuoi controllo totale e hai già dimestichezza con Linux. Ma per un gruppo che vuole semplicemente giocare, un pannello come Pterodactyl con attivazione sotto i 60 secondi, backup automatici e supporto in italiano elimina esattamente la parte noiosa senza toccare la parte divertente, che resta costruire fabbriche assurde con gli amici.

— Fabio Turi

Configurare un server Factorio con AtomSync senza toccare Linux

AtomSync è l’alternativa diretta a montare un VPS da zero quando l’obiettivo è giocare, non amministrare sistemi: attivazione del server in meno di 60 secondi, senza dover mai aprire un terminale per compilare comandi tar o scrivere unit file systemd a mano.

AtomSync

Il pannello Pterodactyl personalizzato di AtomSync gestisce file, mod, backup e riavvii da un’interfaccia grafica, con moduli sviluppati internamente pensati proprio per semplificare le operazioni che in questa guida abbiamo trattato riga di comando per riga di comando. I backup automatici quotidiani eliminano il rischio di perdere una megabase per un aggiornamento andato storto, la protezione DDoS fino a 1 Tbps tiene il server online anche sotto attacco, e il supporto tecnico via Discord risponde in italiano nei giorni lavorativi, senza dover tradurre mentalmente documentazione tecnica in inglese ogni volta che qualcosa non funziona.

Il vantaggio economico reale non è solo nel prezzo del piano, ma nel tempo che non spendi a fare da amministratore di sistema part time. Visita la pagina dedicata al server Factorio per vedere i piani disponibili e attivare il tuo server in pochi clic, con la possibilità di cambiare risorse in qualsiasi momento senza vincoli contrattuali.

Fonti

Domande frequenti

Quanta RAM serve per un server Factorio con 10 giocatori?

Per un gruppo di 5-20 giocatori la community consiglia di partire con 4-6 GB di RAM, aumentando se la fabbrica cresce molto oltre le centomila entità.

Perché il mio server Factorio non parte senza errori?

La causa più comune è l’assenza di un file di salvataggio valido nella cartella saves/: usa il flag --create per generarne uno nuovo prima di lanciare --start-server.

Come rendo pubblico il mio server Factorio?

Devi impostare public su true in server-settings.json e fornire un token generato dal tuo account Factorio, oltre ad aprire la porta UDP 34197 sul firewall.

Meglio un VPS personale o un hosting gestito come AtomSync?

Un VPS autogestito offre più controllo se hai già esperienza Linux, ma un hosting gestito come AtomSync elimina backup manuali, configurazione di rete e manutenzione systemd con attivazione sotto i 60 secondi.

Quanti core servono per evitare lag su Factorio?

Pochi, ma veloci: la simulazione principale gira su singolo thread, quindi una CPU con clock elevato migliora l’UPS più di un numero maggiore di core.

Le mod del client devono corrispondere a quelle del server?

Sì, client e server devono avere esattamente le stesse mod nella stessa versione, altrimenti la connessione viene rifiutata automaticamente.

Come creare un server Factorio: guida completa alla configurazione