Server Dedicato Rust: 12 Passi in 40 Minuti [2026]

Rust resta uno dei giochi survival multiplayer più giocati su Steam, e gestire un server dedicato è l’unico modo per avere il pieno controllo su regole, mod e persistenza del mondo invece di dipendere da un server pubblico affollato. A differenza di titoli come Palworld o Minecraft, Rust ha requisiti hardware più pesanti e una configurazione di rete un po’ più articolata, con una porta di gioco, una porta di query per il server browser e una porta RCON per l’amministrazione remota da gestire separatamente. In questa guida vediamo passo per passo come installare, configurare e mantenere un server dedicato Rust nel 2026, partendo da zero fino ad avere uno script di avvio pronto per la produzione.

Il percorso copre la scelta tra VPS e macchina locale, l’installazione di SteamCMD, il download dei file server tramite l’App ID dedicato, l’apertura delle porte corrette, la creazione di un servizio systemd per l’avvio automatico, la configurazione di RCON, l’aggiunta del framework di mod Oxide/uMod e, infine, backup automatici e ottimizzazione delle prestazioni. Il tempo stimato per completare l’intera procedura, incluso il primo avvio e la generazione della mappa, è di circa 40 minuti su una connessione media.

Rispetto a un server Minecraft o a un server FiveM per il roleplay su GTA, un server Rust chiede più attenzione su tre fronti: il carico sulla CPU durante i combattimenti di gruppo, la gestione dei wipe periodici della mappa (il reset volontario o forzato del mondo di gioco) e un sistema di mod che va tenuto sincronizzato con ogni patch ufficiale. Chi arriva da altri giochi survival tende a sottovalutare proprio quest’ultimo punto, e finisce con un server che si avvia regolarmente ma con metà dei plugin di amministrazione fuori uso dopo un aggiornamento.

Prerequisiti: hardware, software e versioni necessarie

Prima di iniziare serve chiarire una distinzione che genera spesso confusione: Rust ha un App ID per il client (252490) e un App ID separato per il server dedicato (258550). Scaricare l’App sbagliata è l’errore più comune tra chi prova questa procedura per la prima volta, perché il client da solo non include il binario RustDedicated necessario per ospitare una partita.

Di seguito i requisiti minimi e consigliati per un server da 50-100 giocatori, basati sulle linee guida di hosting più diffuse nel 2026:

Componente	Minimo	Consigliato (server modato o mappa grande)
CPU	4 core, clock elevato (single-thread conta più dei core)	6-8 core, 3.5 GHz+
RAM	4-6 GB	8-16 GB
Storage	10-12 GB SSD (installazione base)	20-30 GB SSD/NVMe (mappa, salvataggi, log, mod)
Sistema operativo	Windows 10/Server o Ubuntu 20.04+ (64 bit)	Ubuntu 22.04 LTS (64 bit)
Banda in upload	5 Mbps	10+ Mbps

Software necessario: SteamCMD (ultima versione, aggiornata automaticamente a ogni esecuzione), un client SSH se il server è remoto, e un editor di testo da riga di comando come nano. Su Linux serve inoltre la libreria a 32 bit lib32gcc-s1, richiesta da alcuni componenti di SteamCMD anche se il server Rust stesso gira in 64 bit. Il sistema operativo deve essere aggiornato: versioni datate di Ubuntu possono mancare di dipendenze che SteamCMD si aspetta di trovare.

Serve anche un account Steam, ma non necessariamente uno a pagamento con il gioco acquistato: il download del server dedicato tramite SteamCMD funziona con un login anonimo, senza bisogno di credenziali personali. È una differenza importante rispetto ad altri titoli che richiedono un account Steam valido anche solo per scaricare i file server, e semplifica non poco l’automazione degli aggiornamenti pianificati più avanti in questa guida.

Quanto costa gestire un server Rust: locale, VPS o hosting gestito

Prima ancora di toccare un terminale conviene decidere il modello di hosting, perché condiziona ogni passaggio successivo della guida. Esistono tre strade praticabili, con costi e livello di controllo molto diversi tra loro.

Opzione	Costo indicativo	Controllo	Adatta a
Macchina locale (PC o mini PC dedicato)	0€ extra (solo elettricità)	Totale, ma dipende dalla rete domestica	Server privati con amici, meno di 10-20 giocatori
VPS self-managed	10-40€/mese	Totale, richiede competenze Linux	Server pubblici di medie dimensioni, chi vuole seguire questa guida fino in fondo
Hosting gestito specializzato in Rust	15-60€/mese a seconda degli slot	Limitato, pannello di controllo preconfigurato	Chi vuole un server pubblico senza gestire SteamCMD, systemd o firewall manualmente

Questa guida segue il percorso del VPS self-managed perché è quello che offre il massimo controllo su porte, mod e automazione, ed è anche l’unico che permette di capire davvero cosa succede sotto al cofano quando qualcosa smette di funzionare. Chi sceglie un hosting gestito può comunque usare le sezioni su RCON, Oxide e ottimizzazione delle prestazioni, che restano valide indipendentemente da chi gestisce l’infrastruttura sottostante.

Passo 1 – Scegliere tra VPS e macchina locale

La prima decisione operativa riguarda dove far girare il server. Una macchina locale costa zero in più ma dipende dalla stabilità della connessione domestica: se il router si riavvia o l’IP pubblico cambia (comune con la maggior parte dei contratti internet residenziali in Italia, che assegnano IP dinamici), il server sparisce dalla lista finché non si aggiorna la configurazione o non si imposta un servizio di DNS dinamico. Un VPS invece garantisce un IP statico, uptime più prevedibile e banda simmetrica, a fronte di un costo mensile che va indicativamente dai 10 ai 40 euro al mese a seconda di RAM e CPU allocate.

Per un server privato con amici, una macchina locale con una buona connessione in fibra è sufficiente. Per un server pubblico con decine di giocatori simultanei, un VPS con CPU dedicata, non condivisa con altri clienti, è la scelta più sensata, perché Rust è particolarmente sensibile ai cali di prestazioni della singola CPU durante i picchi di attività, come raid, esplosioni e generazione di nuove aree della mappa. Nella scelta del data center, la vicinanza geografica ai giocatori conta quanto le specifiche hardware: un provider con un nodo in Italia o comunque nell’Europa continentale riduce la latenza percepita rispetto a uno negli Stati Uniti o in Asia, dove il ping può facilmente superare i 150-200 ms.

Passo 2 – Preparare il sistema operativo

Questa guida usa Ubuntu 22.04 LTS come riferimento perché è la distribuzione più documentata per l’hosting di server di gioco e riceve aggiornamenti di sicurezza a lungo termine. I comandi Windows sono equivalenti con PowerShell, ma il flusso Linux è più semplice da automatizzare con systemd e cron, quindi lo useremo come base per tutta la guida.

sudo apt update && sudo apt upgrade -y
sudo apt install -y software-properties-common
sudo dpkg --add-architecture i386
sudo apt update

L’aggiunta dell’architettura i386 è necessaria perché SteamCMD e alcune librerie di supporto sono ancora a 32 bit, anche se il server Rust vero e proprio gira interamente in 64 bit. Saltare questo passaggio è una causa frequente di errori “libraries missing” durante l’installazione successiva.

Passo 3 – Installare SteamCMD

SteamCMD è lo strumento a riga di comando di Valve per scaricare e aggiornare i contenuti Steam senza interfaccia grafica, ed è il metodo ufficiale per installare qualsiasi server dedicato distribuito tramite Steam, incluso Rust.

sudo apt install -y steamcmd lib32gcc-s1
mkdir -p ~/rustserver
sudo useradd -m -s /bin/bash rustsrv
sudo passwd rustsrv

Creare un utente dedicato (rustsrv nell’esempio) invece di far girare tutto come root è una buona pratica di sicurezza: se il server viene compromesso da un exploit, i danni restano confinati a quell’utente. È lo stesso principio che vale per qualsiasi servizio esposto a internet, come spiegato nella nostra guida su come irrobustire l’accesso SSH a un server.

Passo 4 – Scaricare RustDedicated con l’App ID 258550

Con SteamCMD installato, il passaggio successivo è scaricare i file del server usando l’App ID corretto. Va ribadito: 258550 è l’ID del server dedicato, mentre 252490 è l’ID del client di gioco. Usare il secondo al posto del primo scarica l’intero gioco invece del binario headless, sprecando tempo e spazio su disco.

su - rustsrv
steamcmd +force_install_dir /home/rustsrv/rustserver \
  +login anonymous \
  +app_update 258550 validate \
  +quit

Il download richiede circa 10-12 GB e, su una connessione da 100 Mbps, dura indicativamente 10-15 minuti. Al termine, SteamCMD stampa un messaggio del tipo Success! App '258550' fully installed. Se invece compare un errore relativo a spazio su disco insufficiente, verificare di avere almeno 15 GB liberi prima di ripetere il comando: app_update con il flag validate ricontrolla ogni file, quindi un’interruzione a metà non corrompe l’installazione ma va semplicemente rilanciata.

Passo 5 – Configurare i parametri di avvio del server

Rust non usa un unico file di configurazione monolitico come altri giochi: la maggior parte delle impostazioni principali (nome del server, porte, numero massimo di giocatori, dimensione della mappa) viene passata come parametri di avvio al momento del lancio del binario RustDedicated. Le impostazioni vengono poi salvate nella cartella indicata da +server.identity, così da poter gestire più server sulla stessa macchina semplicemente cambiando questo valore.

I parametri di avvio principali

Questi sono i flag che quasi ogni server dedicato Rust deve impostare esplicitamente:

Parametro	Funzione	Esempio
`+server.port`	Porta principale di gioco (UDP)	28015
`+server.queryport`	Porta per la visibilità nel server browser (UDP)	28016
`+server.hostname`	Nome visibile del server	Il Mio Server Rust ITA
`+server.identity`	Cartella dei salvataggi/config, separa più server	my_server
`+server.maxplayers`	Numero massimo di slot giocatore	100
`+server.worldsize`	Dimensione della mappa procedurale	3500
`+server.seed`	Seed della mappa, per rigenerarla in modo identico	12345
`+rcon.port`	Porta per l’amministrazione remota RCON (TCP)	28017
`+rcon.password`	Password RCON	una password lunga e casuale

Un dettaglio spesso trascurato: worldsize influisce direttamente sul tempo di generazione della mappa al primo avvio e sul carico di RAM successivo. Una mappa da 3500 (valore medio) è un buon compromesso per 50-100 giocatori; valori sopra i 4500 vanno riservati a macchine con almeno 12-16 GB di RAM dedicata al solo processo del server.

Passo 6 – Aprire le porte e configurare il firewall

Rust usa tre porte distinte che vanno aperte sia nel firewall del sistema operativo sia, se il server è dietro un router domestico, nel port forwarding del router stesso.

Porta	Protocollo	Uso	Esposta a internet
28015	UDP	Traffico di gioco principale	Sì
28016	UDP	Query port, elenco server nel browser	Sì
28017	TCP	RCON, amministrazione remota	Solo verso IP fidati o tramite VPN

Per il firewall di sistema su Ubuntu con UFW:

sudo ufw allow 28015/udp
sudo ufw allow 28016/udp
sudo ufw allow 28017/tcp
sudo ufw status

La porta RCON non andrebbe mai lasciata aperta a qualsiasi indirizzo IP: è pensata per l’amministrazione, non per l’accesso pubblico. Chi gestisce il server da remoto dovrebbe limitarla al proprio IP statico o, meglio ancora, tunnellarla attraverso una VPN, come descritto nella nostra guida per configurare un server WireGuard su Ubuntu. Per verificare che le porte siano effettivamente raggiungibili dall’esterno una volta aperte, è utile uno strumento come quello descritto nella guida su come scansionare una rete con Nmap.

Passo 7 – Creare lo script di avvio e il servizio systemd

Lanciare RustDedicated manualmente da terminale funziona per un test rapido, ma appena si chiude la sessione SSH il processo muore. La soluzione corretta è uno script di avvio combinato con un servizio systemd, così il server riparte automaticamente anche dopo un riavvio della macchina.

Script start.sh:

#!/bin/bash
cd /home/rustsrv/rustserver
./RustDedicated -batchmode \
  +server.port 28015 \
  +server.queryport 28016 \
  +rcon.port 28017 \
  +rcon.password "CAMBIA_QUESTA_PASSWORD" \
  +rcon.web 1 \
  +server.identity "my_server" \
  +server.hostname "Il Mio Server Rust ITA" \
  +server.worldsize 3500 \
  +server.maxplayers 100 \
  +server.saveinterval 300

Unità systemd /etc/systemd/system/rustserver.service:

[Unit]
Description=Rust Dedicated Server
After=network.target

[Service]
User=rustsrv
WorkingDirectory=/home/rustsrv/rustserver
ExecStart=/home/rustsrv/rustserver/start.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

chmod +x /home/rustsrv/rustserver/start.sh
sudo systemctl daemon-reload
sudo systemctl enable --now rustserver
sudo systemctl status rustserver

Il flag Restart=on-failure è quello che fa la differenza tra un server che resta giù per ore dopo un crash notturno e uno che si rialza da solo in dieci secondi. È lo stesso schema di resilienza usato per qualsiasi servizio in produzione, non solo per i server di gioco.

Passo 8 – Primo avvio e generazione della mappa

Al primo avvio, con worldsize 3500, la generazione procedurale della mappa richiede in genere tra i 3 e gli 8 minuti a seconda della CPU. Nei log si vede una sequenza di messaggi che termina con qualcosa simile a questo:

[Server] Sync World ...
[Server] World generation done in 274.32s
Server startup complete
Listening on 0.0.0.0:28015

Da questo momento il server è raggiungibile. Per connettersi dal client Rust basta aprire la console di gioco (tasto F1) e digitare client.connect IP:28015, sostituendo IP con l’indirizzo pubblico del server, o quello della rete locale se ci si trova sulla stessa rete. Se il server non compare nella lista pubblica, il problema è quasi sempre nella porta di query (28016) non correttamente inoltrata, non nella porta di gioco.

Monitorare i log del server in tempo reale

Prima di passare a RCON, vale la pena sapere dove finiscono i log e come leggerli, perché la maggior parte dei problemi di configurazione si diagnostica da lì prima ancora di aprire un client di amministrazione remota. Con il server avviato tramite systemd, i log del processo confluiscono nel journal di sistema e si possono seguire in tempo reale con:

journalctl -u rustserver -f

Il flag -f mantiene il terminale aperto mostrando le nuove righe man mano che vengono scritte, utile per osservare in diretta cosa succede durante un riavvio, un wipe o l’ingresso di un nuovo giocatore. Se invece il server è stato avviato manualmente fuori da systemd, i log restano nella cartella server/<identity>/logs, con un file separato per ogni sessione di avvio, nominato in genere con data e ora. Controllare periodicamente la dimensione di questa cartella evita che accumuli gigabyte di log storici mai puliti, uno degli errori più comuni citati più avanti in questa guida.

Passo 9 – RCON: amministrazione remota sicura

RCON permette di inviare comandi al server senza essere fisicamente collegati alla console, utilissimo per bannare giocatori, cambiare regole o riavviare il server da remoto. Con +rcon.web 1 attivato nello script di avvio, l’interfaccia web di RCON è raggiungibile da un client compatibile via WebSocket.

# Connessione RCON via WebSocket con un client compatibile:
# host: IP_DEL_SERVER
# porta: 28017
# password: quella impostata in +rcon.password

# Comandi RCON di base una volta connessi:
status
say "Riavvio programmato tra 5 minuti"
kick "NomeGiocatore" "Violazione regolamento"
save

Una password RCON debole o riutilizzata da altri account è probabilmente il rischio di sicurezza più concreto per chi gestisce un server pubblico: chi la ottiene ha di fatto pieno controllo amministrativo. Vale la pena generarla con lo stesso criterio usato per qualsiasi credenziale sensibile, magari con un gestore di password piuttosto che con una frase facile da ricordare.

Passo 10 – Installare Oxide/uMod e le mod essenziali

Un server Rust vanilla va benissimo per un gruppo ristretto di amici, ma la community usa quasi universalmente il framework di modding Oxide, noto anche come uMod, per aggiungere plugin di amministrazione, sistemi anti-cheat aggiuntivi, economia interna e regole personalizzate. L’installazione richiede di sovrascrivere alcuni file del server con la versione modata del framework, che resta compatibile con gli aggiornamenti ufficiali di Facepunch Studios, lo sviluppatore di Rust, fintanto che si aggiorna anche Oxide dopo ogni patch del gioco.

cd /home/rustsrv/rustserver
wget -O oxide.zip https://umod.org/games/rust/download
unzip -o oxide.zip -d .
sudo systemctl restart rustserver

Dopo il riavvio, la cartella oxide/plugins conterrà i plugin installati. Attenzione: ogni volta che Facepunch rilascia un aggiornamento importante del gioco, cosa che avviene tipicamente con cadenza mensile, Oxide può impiegare da poche ore a un paio di giorni per pubblicare la versione compatibile. Aggiornare il server prima che Oxide sia pronto rompe tutti i plugin fino al rilascio della patch corrispondente.

Passo 11 – Backup automatici e aggiornamenti pianificati

Un server senza backup è a una sola crash di troppo dal perdere settimane di progressi dei giocatori. Uno script cron semplice può occuparsi sia dei backup sia degli aggiornamenti automatici tramite SteamCMD.

#!/bin/bash
# backup.sh - backup giornaliero della cartella identity
DATE=$(date +%Y%m%d)
tar -czf /home/rustsrv/backups/my_server_$DATE.tar.gz \
  /home/rustsrv/rustserver/server/my_server
find /home/rustsrv/backups -mtime +7 -delete

Aggiunto a crontab con crontab -e, ad esempio ogni notte alle 4:

0 4 * * * /home/rustsrv/backup.sh
0 5 * * 4 systemctl stop rustserver && steamcmd +force_install_dir /home/rustsrv/rustserver +login anonymous +app_update 258550 validate +quit && systemctl start rustserver

La riga di aggiornamento è programmata per il giovedì, giorno tipico delle patch di Rust, qualche ora dopo il rilascio atteso, così da minimizzare il tempo in cui il server resta disallineato dalla versione ufficiale del gioco, cosa che altrimenti impedirebbe ai client aggiornati di connettersi.

Passo 12 – Ottimizzare tick rate e prestazioni

Il tick rate, impostabile con +server.tickrate e tipicamente compreso tra 10 e 30, determina quante volte al secondo il server aggiorna la simulazione di fisica e combattimento. Un valore più alto rende il gameplay più reattivo ma consuma più CPU; molti host commerciali usano 30 come compromesso per server con meno di 100 giocatori, scendendo a 10-15 su hardware più limitato o con molte mod attive.

Altri interventi che incidono concretamente sulle prestazioni percepite dai giocatori: evitare un server.saveinterval troppo aggressivo (un salvataggio ogni 300 secondi è ragionevole; salvataggi troppo frequenti causano micro-freeze percettibili), limitare il numero di entità decorative sulle mappe molto grandi, e programmare i wipe, cioè il reset della mappa, con regolarità, perché una mappa che accumula settimane di basi e loot cresce di dimensione e rallenta i salvataggi.

Sicurezza del server: oltre RCON

RCON non è l’unico fronte di sicurezza da presidiare. Rust usa Easy Anti-Cheat lato client per contrastare i cheater più comuni, ma questo non protegge il server dedicato da tentativi di scansione delle porte, brute force sulla password RCON o, nei casi più seri, attacchi volumetrici mirati a mandare offline il server nelle ore di punta. Un server pubblico con una community consolidata è un bersaglio più interessante di uno privato tra amici, semplicemente perché ha più da perdere in termini di reputazione e giocatori attivi.

Alcune misure pratiche riducono concretamente la superficie di attacco: limitare l’accesso SSH alla sola autenticazione tramite chiave, disabilitando il login con password (lo stesso approccio descritto nella guida su come generare e usare chiavi SSH Ed25519 per irrobustire un server); tenere il sistema operativo aggiornato con patch di sicurezza regolari; e, se il provider VPS lo offre, attivare una protezione anti-DDoS a livello di rete invece di affidarsi solo al firewall applicativo. Molti provider orientati all’hosting di server di gioco includono una protezione di base senza costi aggiuntivi, ma vale la pena verificarlo esplicitamente prima di annunciare pubblicamente il server, non dopo il primo attacco.

Gestire i wipe: reset della mappa e calendario della community

Il wipe è il reset periodico della mappa e, a seconda della configurazione, anche dei progressi dei giocatori (blueprint, oggetti sbloccati). Facepunch Studios impone un wipe forzato lato server ogni mese, in coincidenza con la patch principale del gioco, ma la maggior parte dei server pubblici aggiunge wipe volontari più frequenti, tipicamente settimanali o bisettimanali, per mantenere il gameplay fresco e impedire che poche fazioni dominino la mappa per settimane consecutive.

Un wipe si esegue cancellando i file di salvataggio della cartella identity (o rinominandola, se si vuole conservare un archivio) prima di riavviare il servizio:

sudo systemctl stop rustserver
mv /home/rustsrv/rustserver/server/my_server \
   /home/rustsrv/backups/pre_wipe_$(date +%Y%m%d)
sudo systemctl start rustserver

Comunicare in anticipo il calendario dei wipe, magari con un annuncio in gioco tramite RCON qualche ora prima, è una delle pratiche che distingue un server con una community fedele da uno che perde giocatori a ogni reset a sorpresa. Molti amministratori pubblicano il calendario dei wipe su Discord o nella descrizione del server, così i giocatori sanno esattamente quando ripartire da zero.

Errori comuni da evitare

Scaricare l’App ID sbagliato. Usare 252490, il client, invece di 258550, il server, scarica l’intero gioco con interfaccia grafica, inutile su un server headless e molto più pesante da mantenere aggiornato. Il sintomo tipico è una cartella di installazione da oltre 20 GB invece dei 10-12 GB attesi, con file che il binario del server non sa nemmeno interpretare.
Lasciare la porta RCON aperta a tutto internet. È la falla di sicurezza più comune sui server pubblici: chiunque la scopra con una scansione automatica e indovini la password ottiene il controllo completo, incluso l’accesso a comandi distruttivi come il wipe forzato della mappa o il ban di massa dei giocatori legittimi.
Dimenticare di aggiornare Oxide dopo una patch del gioco. Il server parte ma i plugin smettono di funzionare, spesso in modo silenzioso, senza errori evidenti nei log, lasciando i giocatori senza i comandi di amministrazione o l’economia interna a cui erano abituati.
Sottovalutare lo spazio su disco per i log. Su server con molto traffico i file di log possono crescere di diversi gigabyte a settimana se non viene configurata una rotazione, fino a bloccare i salvataggi automatici quando il disco si riempie del tutto.
Impostare un worldsize troppo grande per la RAM disponibile. Una mappa da 4500 o più su una macchina con 6 GB di RAM porta quasi certamente a crash da esaurimento memoria nelle ore di punta, proprio quando il server ha più giocatori connessi.
Eseguire il server come utente root. Comodo per i test, ma espone l’intero sistema in caso di vulnerabilità sfruttata tramite il gioco o un plugin malevolo, invece di limitare il danno a un singolo utente con permessi ridotti.
Ignorare il calendario dei wipe ufficiali di Facepunch. Programmare un wipe volontario proprio a ridosso della patch mensile forzata genera confusione tra i giocatori, che si trovano con due reset ravvicinati invece di uno pianificato.

Risoluzione dei problemi più comuni

Il server non compare nella lista pubblica. Verificare che la porta di query (UDP, ad esempio 28016) sia inoltrata correttamente sul router e aperta nel firewall, non solo la porta di gioco 28015.
Errore “libraries missing” durante l’installazione di SteamCMD. Mancano le librerie a 32 bit: rieseguire sudo dpkg --add-architecture i386 && sudo apt update && sudo apt install lib32gcc-s1.
Il servizio systemd si riavvia in loop. Controllare i log con journalctl -u rustserver -n 100: quasi sempre è un parametro di avvio malformato o un permesso mancante sulla cartella del server.
I client aggiornati non riescono a connettersi. Il server sta ancora girando su una build precedente rispetto all’ultima patch di Facepunch; rilanciare app_update 258550 validate.
La generazione della mappa non finisce mai. Probabile carenza di RAM o CPU insufficiente per il worldsize scelto; ridurre server.worldsize a 3000-3500 o aumentare le risorse della VPS.
RCON si connette ma i comandi non hanno effetto. Verificare che +rcon.web 1 sia effettivamente presente nei parametri di avvio e che la password non contenga caratteri speciali gestiti male dal client RCON usato.
Il server crasha regolarmente durante i raid o le esplosioni. Sintomo tipico di CPU sottodimensionata rispetto al numero di giocatori attivi; abbassare il tick rate a 10-15 come misura temporanea mentre si valuta un upgrade hardware.
I plugin Oxide smettono di caricarsi dopo un aggiornamento. Scaricare la build più recente di Oxide compatibile con la versione attuale del gioco dal sito ufficiale umod.org e sovrascrivere i file, poi riavviare il servizio.
Lo spazio su disco si esaurisce rapidamente. Controllare la dimensione della cartella dei log e dei backup; impostare una rotazione automatica dei log più aggressiva e ridurre la retention dei backup se non strettamente necessaria.

Consigli avanzati per chi gestisce più server

Chi amministra più server Rust sulla stessa macchina fisica dovrebbe assegnare a ciascuno un blocco di porte non sovrapposto, ad esempio 28015-28017 per il primo e 28025-28027 per il secondo, oltre a un server.identity univoco per ciascuna istanza. Questo evita conflitti di configurazione e permette di riavviare un server senza toccare gli altri. Vale anche la pena isolare ogni istanza in un servizio systemd separato, così un crash di un server non forza il riavvio degli altri.

Per chi punta a un server competitivo di lunga durata, è utile automatizzare anche il monitoraggio delle risorse: uno script che controlla l’uso di CPU e RAM ogni pochi minuti e invia un avviso quando si superano soglie critiche permette di intervenire prima che i giocatori notino lag o disconnessioni. Allo stesso modo, testare periodicamente la raggiungibilità delle porte dall’esterno con uno strumento di scansione di rete evita brutte sorprese dopo un aggiornamento del firewall o del router.

Un altro accorgimento utile su server con più amministratori è centralizzare l’accesso RCON dietro un unico pannello condiviso invece di distribuire la password a più persone: ogni admin in più con accesso diretto è un punto di rischio aggiuntivo, e revocare l’accesso a una singola persona diventa complicato se la password è condivisa invece che individuale. Alcuni framework di modding per Rust supportano permessi granulari per gruppo, così da assegnare comandi di moderazione senza dare accesso RCON completo a tutto lo staff.

Infine, per chi gestisce un server su una macchina condivisa con altri servizi (un piccolo homelab, ad esempio), vale la pena isolare il processo Rust con limiti di risorse a livello di systemd, usando direttive come MemoryMax e CPUQuota nell’unità del servizio. Questo impedisce che un picco di carico del server di gioco impatti altri servizi in esecuzione sulla stessa macchina, come un sito web o un server di posta.

Il progetto completo: struttura finale pronta all’uso

Mettendo insieme tutti i passaggi precedenti, la struttura finale di un server dedicato Rust in produzione si presenta così:

/home/rustsrv/rustserver/
├── RustDedicated              (binario del server, App ID 258550)
├── start.sh                   (script di avvio con tutti i parametri)
├── server/
│   └── my_server/              (cartella identity: salvataggi, log, config)
├── oxide/
│   └── plugins/                 (plugin Oxide/uMod installati)
└── backups/                    (archivi tar.gz generati da backup.sh)

/etc/systemd/system/rustserver.service   (servizio di avvio automatico)

crontab (utente rustsrv):
  0 4 * * *  backup.sh
  0 5 * * 4  aggiornamento automatico post-patch

Con questa struttura il server si avvia da solo al riavvio della macchina, si riavvia automaticamente in caso di crash, si aggiorna ogni giovedì dopo le patch di Facepunch, esegue un backup giornaliero e mantiene solo l’ultima settimana di archivi per non riempire il disco. È lo scheletro minimo che qualunque server pubblico dovrebbe avere prima di essere annunciato alla community.

Da qui in avanti, le uniche operazioni manuali ricorrenti restano la lettura periodica dei log per individuare comportamenti anomali, la comunicazione del calendario dei wipe ai giocatori e, occasionalmente, l’aggiornamento dei plugin Oxide quando escono nuove versioni compatibili. Tutto il resto, dall’avvio all’aggiornamento del gioco fino al backup dei dati, gira senza intervento umano.

Domande frequenti

Qual è l’App ID corretto per il server dedicato di Rust?

L’App ID ufficiale del server dedicato è 258550, distinto dall’App ID 252490 del client di gioco. Vanno sempre tenuti separati perché SteamCMD scarica pacchetti completamente diversi a seconda di quale viene usato.

Quanta RAM serve davvero per un server Rust con 100 giocatori?

Tra 8 e 16 GB sono la fascia realistica per un server pieno con mappa di dimensioni medio-grandi e alcuni plugin Oxide attivi. Sotto gli 8 GB il rischio di crash da esaurimento memoria nelle ore di punta aumenta sensibilmente.

Posso ospitare un server Rust su Windows invece che su Linux?

Sì, RustDedicated gira anche su Windows 10 e Windows Server tramite SteamCMD. La differenza principale è che l’automazione di avvio e backup richiede Task Scheduler e script batch o PowerShell invece di systemd e cron, con una configurazione leggermente più macchinosa.

Perché il mio server non appare nel browser server di Rust?

Nella grande maggioranza dei casi la porta di query, UDP, tipicamente 28016 nell’esempio di questa guida, non è correttamente inoltrata dal router o è bloccata dal firewall, anche se la porta di gioco 28015 funziona regolarmente per chi si connette con l’IP diretto.

Cos’è Oxide/uMod e serve davvero?

Oxide, noto anche come uMod, è il framework di modding più diffuso per Rust, usato per plugin di amministrazione, economia interna e regole personalizzate. Non è obbligatorio per un server vanilla tra amici, ma è quasi uno standard per qualsiasi server pubblico con una community attiva.

Con che frequenza va aggiornato il server dopo le patch di Facepunch?

Facepunch Studios rilascia aggiornamenti con cadenza tipicamente mensile. Il server va aggiornato appena possibile dopo ogni patch, perché i client aggiornati non riescono a connettersi a una versione del server precedente.

Quanto costa un VPS adatto a un server Rust di medie dimensioni?

Indicativamente tra 10 e 40 euro al mese per una configurazione con 4-8 core, 8-16 GB di RAM e storage SSD, a seconda del provider e della regione scelta per la latenza verso i giocatori.

È sicuro lasciare RCON sempre attivo?

È sicuro solo se l’accesso alla porta RCON è ristretto a IP fidati o instradato tramite VPN, e se la password è lunga e casuale. Lasciarlo aperto senza restrizioni a tutto internet è uno dei rischi di sicurezza più concreti per un server pubblico.

Ogni quanto conviene fare il wipe della mappa?

Il wipe forzato mensile imposto da Facepunch in coincidenza con la patch principale è obbligatorio per restare compatibili con l’ultima versione del gioco. Molti server pubblici aggiungono wipe volontari settimanali o bisettimanali per mantenere il gameplay competitivo, ma la scelta finale dipende dalle preferenze della community che si vuole costruire.

Serve per forza Oxide per gestire un server con pochi amici?

No. Un server vanilla senza plugin funziona perfettamente per un gruppo ristretto che non ha bisogno di comandi di amministrazione avanzati, economia interna o protezioni anti-raid personalizzate. Oxide diventa utile soprattutto quando il server cresce e serve moderare una community più ampia.