Installare Minecraft Bedrock Server su Ubuntu 24.04 e 22.04

Installazione pulita su Ubuntu 24.04 e 22.04

Se vuoi un Bedrock Server stabile su Ubuntu, la scelta giusta è trattarlo come un servizio di sistema, non come un binario lanciato a mano dentro una shell SSH. La differenza la fai subito: utente dedicato, directory dati separata, avvio con systemd, porta UDP esposta in modo controllato e backup fuori dal path dell’applicazione. Su Ubuntu 24.04 e 22.04 la procedura è molto simile; cambiano poco i pacchetti e non cambia il punto importante, cioè tenere il server isolato e ripetibile.

Il Bedrock Server distribuito da Mojang è un archivio compresso con binari già pronti. Non c’è un’installazione “classica” con repository ufficiale: si scarica il pacchetto, si estrae in una directory dedicata e si crea l’infrastruttura attorno. Questo semplifica il deployment, ma sposta su di te la responsabilità di aggiornamenti, permessi, riavvii e persistenza dei dati.

Prerequisiti reali: CPU, RAM, storage e rete

Per una piccola istanza privata bastano spesso 2 vCPU e 2-4 GB di RAM, ma il collo di bottiglia vero di solito è il carico sul mondo e la latenza disco nei salvataggi. Se il server è su VPS economica, controlla soprattutto che lo storage non sia troppo lento e che la porta UDP 19132 sia raggiungibile dall’esterno. Se hai più di pochi giocatori, osserva anche l’uso di memoria durante il tick e non solo la RAM “a riposo”.

Verifica subito che il sistema sia aggiornato e che il kernel non stia già segnalando problemi di spazio o I/O. Non serve fare tuning prima di avere una base sana.

sudo apt update
sudo apt -y upgrade
df -h
free -h
uname -a

Se `df -h` mostra il filesystem quasi pieno, fermati lì: un mondo Minecraft corrotto per disco saturo è più costoso da recuperare di una mezz’ora spesa a ripulire o spostare i dati. Per il Bedrock Server, avere margine su `worlds/`, `logs/` e backup è più importante del risparmio di qualche gigabyte.

Utente dedicato, directory separata e pacchetto server

La struttura più pulita è questa: un utente di servizio senza login interattivo, una directory applicativa in `/opt/bedrock`, i dati persistenti nella stessa area o in una sottodirectory dedicata, e i log tenuti insieme al servizio. Evita di installare il server dentro la home di un utente umano: funziona, ma rende più fragile il backup e più opaco il controllo dei permessi.

Crea l’utente e la directory:

sudo adduser --system --home /opt/bedrock --group bedrock
sudo mkdir -p /opt/bedrock
sudo chown -R bedrock:bedrock /opt/bedrock

Scarica il pacchetto ufficiale dal sito Mojang. Il link cambia nel tempo, quindi la parte corretta è sempre questa: vai alla pagina di download del Bedrock Dedicated Server, prendi l’URL più recente e scarica l’archivio nella directory di lavoro. Se automatizzi, conserva il link in uno script o in una nota operativa, non in un comando copiato a memoria.

Dopo il download, estrai il contenuto come utente `bedrock`:

sudo -u bedrock bash -lc 'cd /opt/bedrock && unzip bedrock-server-*.zip'

Se l’archivio contiene già binari e file di configurazione, la directory applicativa è pronta. I file che ti interessano subito sono `server.properties`, `allowlist.json`, `permissions.json` e la cartella del mondo. Se il server non parte, il primo controllo va sempre sui permessi di questi elementi.

Configurazione iniziale: nome mondo, porta, difficulty e visibilità

Il file `server.properties` governa il comportamento base. Non serve toccare tutto: meglio cambiare solo ciò che impatta davvero l’operatività. In genere si impostano nome server, porta UDP, difficulty, gamemode, seed, view distance e eventuale whitelist/allowlist. Per una prima messa online, tieni il profilo semplice e misurabile.

Un esempio minimo di parametri sensati:

server-name=Bedrock Ubuntu Server
server-port=19132
gamemode=survival
difficulty=normal
enable-lan-visibility=false
max-players=10
view-distance=8
tick-distance=4

La `view-distance` e la `tick-distance` sono spesso sottovalutate. Su hardware modesto, abbassarle riduce il carico e migliora la regolarità del tick più di quanto faccia un micro-ottimizzazione altrove. Se il server comincia a laggare con pochi utenti, queste due variabili vanno guardate prima dei sospetti più fantasiosi.

Per l’accesso giocatori, il Bedrock usa l’allowlist. Se la vuoi attiva, devi abilitare l’opzione corrispondente e mantenere l’elenco utenti nel formato previsto dal server. In un contesto privato è la soluzione più semplice per evitare accessi casuali.

Avvio manuale per il primo test

Prima di creare il servizio systemd, esegui un avvio manuale per vedere subito eventuali errori di librerie, permessi o configurazione. È un passaggio banale, ma ti evita di debuggarlo dentro un servizio che fallisce in loop senza contesto.

sudo -u bedrock bash -lc 'cd /opt/bedrock && LD_LIBRARY_PATH=. ./bedrock_server'

Se il binario non parte, i casi più comuni sono: archivio estratto male, mancanza di bit eseguibile, librerie non trovate o file di configurazione non leggibili. Il test immediato è guardare l’output in console e verificare che la directory contenga i binari previsti.

Quando il server avvia correttamente, accetta la licenza EULA se presente il file `eula.txt` richiesto dalla versione distribuita. In pratica: il server deve trovare la conferma che l’utente accetta le condizioni d’uso prima di inizializzare il mondo. Questo file va gestito come configurazione, non modificato alla cieca dentro una sessione temporanea.

Servizio systemd robusto e riavvio automatico

Per produzione, o anche solo per un server casalingo che non vuoi rincorrere ogni volta che si riavvia la macchina, systemd è la scelta corretta. Ti dà log centralizzati, restart policy, ordering e una gestione più chiara del ciclo di vita.

Crea `/etc/systemd/system/bedrock.service` con un contenuto simile:

[Unit]
Description=Minecraft Bedrock Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=bedrock
Group=bedrock
WorkingDirectory=/opt/bedrock
ExecStart=/opt/bedrock/bedrock_server
Restart=on-failure
RestartSec=5
LimitNOFILE=4096
Nice=1

[Install]
WantedBy=multi-user.target

Qui c’è una nota importante: in alcuni casi il binario richiede `LD_LIBRARY_PATH=.` o un wrapper shell. Se l’avvio diretto fallisce ma manualmente funziona, usa uno script wrapper controllato al posto di forzare il servizio a indovinare le librerie. Non improvvisare con ambienti sporchi dentro `ExecStart`.

Esempio di wrapper minimale, se necessario:

#!/bin/sh
cd /opt/bedrock || exit 1
exec env LD_LIBRARY_PATH=. ./bedrock_server

Rendi eseguibile il file, aggiorna il servizio e avvialo:

sudo systemctl daemon-reload
sudo systemctl enable --now bedrock.service
sudo systemctl status bedrock.service

Il controllo vero non è solo `active (running)`: guarda anche `journalctl -u bedrock -n 50 --no-pager` per capire se il processo sta generando errori silenziosi, soprattutto all’avvio o al salvataggio del mondo.

Firewall: UDP 19132 e niente esposizioni inutili

Il Bedrock Server usa UDP, quindi se apri solo TCP non hai risolto nulla. Su Ubuntu con UFW la regola essenziale è una, e deve essere chiara. Non aprire porte aggiuntive “per sicurezza” o per tentativi: ogni porta in più è superficie d’attacco inutile.

sudo ufw allow 19132/udp
sudo ufw status verbose

Se il server è dietro NAT o su una VPS con firewall del provider, la regola va replicata anche lì. Il sintomo classico è il servizio in ascolto localmente ma nessun client che riesce a connettersi dall’esterno. In quel caso il problema non è Minecraft: è la catena di rete tra client e host.

Verifica di ascolto e diagnostica rapida

Dopo l’avvio, verifica che il processo stia realmente ascoltando sulla porta giusta e che lo faccia su UDP. Questo è il controllo che evita ore spese a cambiare configurazioni quando il problema è solo il binding.

sudo ss -lunp | grep 19132
sudo journalctl -u bedrock -n 100 --no-pager

Atteso: una riga con `udp` e il processo `bedrock_server`. Se non compare, il servizio non è partito davvero o sta bindando su un’altra porta. Se compare ma i client non entrano, passa alla rete esterna: firewall, port forwarding, DNS se usi un nome host, e infine eventuali filtri del provider.

Un test utile da una macchina remota è usare uno strumento che invii traffico UDP alla porta del server. Non aspettarti la stessa immediatezza di un `curl`: con UDP bisogna ragionare per assenza/presenza di risposta e per log applicativi, non solo per handshake classici HTTP.

Backup del mondo e dei file di configurazione

Il punto fragile non è il binario, è il mondo. Se perdi `worlds/`, hai perso il lavoro degli utenti. Il backup deve includere almeno la directory del mondo, `server.properties`, `allowlist.json`, `permissions.json` e qualsiasi file personalizzato tu abbia aggiunto. Se usi snapshot del filesystem, meglio ancora, ma solo se sai davvero come ripristinarli.

Una soluzione semplice è un archivio giornaliero con timestamp, salvato fuori dalla directory del server. Esempio:

#!/bin/sh
set -eu
DEST=/backup/bedrock
SRC=/opt/bedrock
TS=$(date +%F_%H-%M-%S)
mkdir -p "$DEST"
tar -C "$SRC" -czf "$DEST/bedrock-$TS.tar.gz" worlds server.properties allowlist.json permissions.json

Il backup va eseguito a server fermo o con una strategia che garantisca consistenza. Se fai snapshot “a caldo”, sappi almeno che il rischio di incoerenza cresce quando il mondo è in scrittura. Per un server piccolo, fermare il servizio per pochi secondi è spesso il compromesso più pulito.

Aggiornamento senza sorprese

Gli aggiornamenti del Bedrock Server sono manuali: scarichi il nuovo archivio, sostituisci i binari e lasci intatti i dati persistenti. Il passaggio corretto è sempre: backup, stop del servizio, aggiornamento, test, start, verifica log. Saltare uno di questi passaggi è il modo più rapido per trasformare un update in un incidente.

Procedura di base:

1. Fai un backup del mondo e dei file di configurazione.
2. Ferma il servizio: sudo systemctl stop bedrock.service.
3. Sostituisci solo i file binari con quelli del nuovo pacchetto, senza cancellare i dati.
4. Riavvia il servizio: sudo systemctl start bedrock.service.
5. Controlla i log e verifica l’accesso dal client.

Se il nuovo rilascio introduce incompatibilità, il rollback è semplice solo se hai conservato il pacchetto precedente o un backup pulito della directory applicativa. Non sovrascrivere mai in modo distruttivo senza aver prima verificato che il mondo sia al sicuro altrove.

Permessi, sicurezza e superficie d’attacco

Il server non deve girare come root. Questo è il punto di sicurezza principale e non è negoziabile. L’utente `bedrock` deve avere solo i permessi necessari sulla sua directory. Tutto il resto resta al sistema e agli amministratori. Se devi accedere via SSH, fallo con un account separato e privilegi elevati solo quando servono.

Evita di esporre pannelli, portali o servizi ausiliari collegati al server se non hai una ragione precisa. Molti problemi nascono non dal gioco in sé, ma dal contorno: script di gestione mal protetti, directory web accessibili, backup pubblici o credenziali riutilizzate. Se salvi qualsiasi segreto in file di configurazione esterni, proteggili con permessi stretti e non inserirli mai in chiaro in documentazione operativa condivisa.

Se vuoi un minimo di audit, controlla periodicamente i log di systemd e quelli applicativi, e verifica che il servizio sia l’unico processo in ascolto sulla porta prevista.

sudo ss -lunp | grep 19132
sudo journalctl -u bedrock --since today --no-pager

Problemi tipici e lettura corretta dei sintomi

Se il client non vede il server, non partire dal file di configurazione: parti dalla rete. Se il servizio parte ma poi muore, guarda i log. Se il mondo non carica, controlla spazio disco e permessi. Se il server è lento, osserva tick, view distance e carico I/O. La diagnosi efficiente segue sempre la catena: rete, processo, log, storage, mondo.

Tre sintomi ricorrenti meritano attenzione immediata:

• Connessione impossibile dall’esterno: porta UDP bloccata, NAT non inoltrato o firewall del provider.
• Crash all’avvio: binari mancanti, librerie non trovate, file di licenza/configurazione assenti o permessi errati.
• Lag progressivo: storage lento, parametri troppo aggressivi, mondo troppo grande per l’hardware disponibile.

La cosa da evitare è la modifica casuale di decine di parametri senza misurare niente. Se vuoi migliorare le prestazioni, cambia una cosa alla volta e osserva un indicatore concreto: tempi di caricamento, saturazione CPU, memoria residente, errori nei log e stabilità del tick.

Checklist operativa finale

Prima di considerare l’installazione pronta, verifica questi punti in ordine:

1. Il servizio è attivo e riparte dopo reboot con systemctl is-enabled bedrock.service.
2. La porta UDP 19132 risulta in ascolto con ss -lunp.
3. Il firewall consente solo ciò che serve con ufw status verbose.
4. I log non mostrano errori ricorrenti con journalctl -u bedrock -n 100.
5. Un backup testato del mondo esiste fuori dalla directory del server.

Se questi cinque controlli sono a posto, il server è in una condizione ragionevole per l’uso quotidiano. Da lì in poi il lavoro non è più “installare”, ma mantenere: aggiornare con criterio, monitorare il carico e proteggere i dati che contano davvero, cioè il mondo e le configurazioni.

Su Ubuntu 24.04 e 22.04 la differenza pratica è minima: conta molto di più come hai costruito il servizio intorno al binario che la versione esatta del sistema operativo. Un Bedrock Server ben tenuto è semplice da gestire; uno installato in fretta diventa fragile alla prima interruzione o al primo update.