Per la maggior parte dei server plugin-based, Paper è la scelta raccomandata. Spigot resta valido solo in casi legacy specifici, e CraftBukkit non va considerato per nuovi server.
Perché Paper vince nel confronto diretto:
- Performance sotto carico: grazie ad async chunk loading, entity activation range e item merging, Paper mantiene TPS significativamente più alti rispetto a Spigot quando il server è sotto pressione.
- Feature native incluse: anti-xray, limitatori di spawn mob e report Timings sono integrati, senza bisogno di plugin aggiuntivi.
- Diagnostica avanzata: Spark e Timings funzionano meglio su Paper e permettono di individuare colli di bottiglia in pochi minuti.
- Migrazione quasi indolore: Paper è un drop-in replacement per Spigot nella grande maggioranza dei casi.
Mantieni Spigot se hai plugin legacy che dipendono da chiamate NMS specifiche non aggiornate, o se gestisci una rete con tool personalizzati testati su Spigot da anni. Su un server privato con 3–5 giocatori, la differenza pratica è spesso impercettibile.
Punti chiave
Paper è la scelta raccomandata per la maggior parte dei server plugin-based perché combina performance superiore sotto carico, feature native integrate e strumenti diagnostici avanzati, con una migrazione che nella grande maggioranza dei casi si riduce alla sostituzione del JAR.
| Punto | Dettagli |
|---|---|
| Paper è il default consigliato | Per server fino a circa 50 giocatori, Paper offre TPS più stabili e feature native che Spigot non ha. |
| La migrazione richiede backup | Sostituire il JAR senza backup completo è il rischio principale; il rollback è semplice se il backup esiste. |
| I plugin NMS vanno verificati | I plugin che usano chiamate NMS interne possono rompersi; controllare la console all’avvio è il primo passo. |
| Misura prima e dopo | Usare Timings o Spark per registrare TPS e MSPT su Spigot e poi su Paper è l’unico modo per quantificare il guadagno reale. |
| AtomSync semplifica il processo | Con backup automatici, pannello Pterodactyl e supporto in italiano, AtomSync riduce il rischio operativo della migrazione. |
Indice
- Cos’è Spigot, cos’è Paper e perché evitare CraftBukkit?
- Come si confrontano Paper e Spigot sulle dimensioni che contano?
- Cosa cambia sotto il cofano: le ottimizzazioni di Paper e il loro impatto sul TPS
- Quali plugin funzionano su Paper e cosa può rompersi?
- Come passare da Spigot a Paper in sicurezza: checklist passo per passo
- Quando ha senso restare su Spigot?
- Come misurare l’impatto della migrazione con Timings e Spark
- Cosa aspettarsi nelle prime settimane dopo il passaggio a Paper
- Perché consiglio Paper per quasi tutti i server
- Hosting Paper e Spigot senza pensieri: AtomSync lo gestisce per te
- Fonti
- Domande frequenti
Cos’è Spigot, cos’è Paper e perché evitare CraftBukkit?
Capire la gerarchia tra questi tre server jar richiede meno di un minuto.
- CraftBukkit è il progetto originale che ha introdotto l’API Bukkit su Minecraft. Oggi è obsoleto, riceve aggiornamenti minimi e non offre ottimizzazioni degne di nota. Per un nuovo server non ha senso usarlo.
- Spigot è nato come fork ottimizzato di CraftBukkit, aggiungendo configurazioni come
spigot.ymlper controllare mob spawn, view distance e comportamenti del mondo. Rimane compatibile con l’API Bukkit e ha una community ampia su SpigotMC. - Paper (PaperMC) è un fork di Spigot con ottimizzazioni più profonde, un’API estesa, feature native (anti-xray, entity activation range, async chunk loading) e rilasci rapidi. Dal 2026 è la scelta predefinita per la maggior parte dei server fino a circa 50 giocatori.
Paper eredita la compatibilità con i plugin Bukkit e Spigot, ma aggiunge strati propri che Spigot non ha. La documentazione ufficiale di Paper lo descrive esplicitamente come drop-in replacement per entrambi.
Come si confrontano Paper e Spigot sulle dimensioni che contano?
| Dimensione | Paper | Spigot |
|---|---|---|
| Performance e TPS sotto carico | Superiore: async chunk loading, entity activation range, item merging | Base: ottimizzazioni limitate a spigot.yml |
| Compatibilità plugin Bukkit/Spigot | Alta (drop-in replacement) | Nativa |
| Plugin che usano NMS | Richiede aggiornamento del plugin | Compatibilità diretta |
| Feature native | Anti-xray, mob limits, Timings avanzati | Assenti o limitate |
| Stabilità e supporto comunitario | Attivo, rilasci frequenti | Attivo, community consolidata |
| Facilità di migrazione | Sostituzione JAR + backup + controllo console | N/A (punto di partenza) |
| Strumenti diagnostici | Timings integrati + Spark | Timings base |
Scegli Paper se gestisci un server pubblico, hai più di una manciata di giocatori attivi o vuoi ridurre il numero di plugin di supporto. Mantieni Spigot se hai plugin legacy che non ricevono più aggiornamenti e che dipendono da NMS specifici.
Paper è la scelta predefinita per server fino a circa 50 giocatori secondo le analisi comparative del 2026; per carichi superiori o esigenze multi-thread avanzate si valutano soluzioni come Folia.
Cosa cambia sotto il cofano: le ottimizzazioni di Paper e il loro impatto sul TPS
Il TPS (Ticks Per Second) è il battito cardiaco del server: 20 TPS significa gioco fluido, sotto 15 i giocatori iniziano a percepire lag. Paper interviene su più fronti per mantenere questo valore stabile.
Async chunk loading sposta il caricamento dei chunk dal main thread a thread separati. Su Spigot, ogni chunk caricato compete con la logica di gioco per il tempo del main thread. Su Paper, l’I/O del disco avviene in parallelo, liberando cicli preziosi. Il risultato è visibile soprattutto quando molti giocatori si spostano contemporaneamente in aree non ancora caricate.
Entity activation range riduce la frequenza di aggiornamento delle entità lontane dai giocatori. Un mob a 100 blocchi di distanza non ha bisogno di essere aggiornato ogni tick come uno a 5 blocchi. Questo abbassa il carico CPU in modo proporzionale alla densità di mob nel mondo, che su server con farm automatiche può essere considerevole.
Item merging raggruppa gli oggetti a terra in stack, riducendo il numero di entità da processare. Su server survival con farm di risorse attive, il numero di item entity può esplodere rapidamente.
Anti-xray nativo offusca i blocchi minerali lato server prima di inviarli al client, eliminando la necessità di plugin come OreObfuscator. Meno plugin attivi significa meno overhead complessivo.
Paper fornisce async chunk loading, entity activation range e vari miglioramenti che in test mostrano una migliore ritenzione del TPS sotto carico rispetto a Spigot.
Quando le ottimizzazioni sono trascurabili? Su server privati con 3–5 giocatori e attività limitata, il main thread raramente è il collo di bottiglia. In quei casi la differenza tra Paper e Spigot è quasi nulla.
Un consiglio: prima di modificare i thread di chunk loading in paper.yml, misura il comportamento di default con Timings o Spark. Aumentare i thread senza necessità può spostare il collo di bottiglia dalla CPU alla memoria, peggiorando la stabilità invece di migliorarla.
Quali plugin funzionano su Paper e cosa può rompersi?
La compatibilità è alta, ma non assoluta. Il problema non riguarda i plugin che usano l’API Bukkit standard, che funzionano senza modifiche. Il rischio riguarda i plugin che accedono alle classi NMS (net.minecraft.server) tramite reflection o che dipendono da strutture interne di Spigot.
Paper, a partire dalla versione 1.20.5, supporta i mapping Mojang a runtime, semplificando lo sviluppo e migliorando la compatibilità per i plugin moderni. I plugin sviluppati con paperweight-userdev sono nativamente compatibili. Quelli vecchi che usano NMS con mapping Spigot potrebbero generare errori.
Come verificare la compatibilità prima di migrare:
- Elenca tutti i plugin attivi e controlla l’ultima versione disponibile su SpigotMC o Modrinth.
- Cerca nella pagina del plugin menzione esplicita di compatibilità con Paper.
- Controlla se il plugin usa NMS: se la pagina del progetto menziona «NMS», «reflection» o «internals», è un candidato a problemi.
- Avvia il server in staging e leggi la console all’avvio: warning o errori
ClassNotFoundException/NoSuchMethodExceptionindicano incompatibilità NMS. - Testa ogni funzionalità critica del plugin in staging prima di portare la migrazione in produzione.
La roadmap di sviluppo di Paper depreca periodicamente alcune API Spigot in favore di implementazioni proprie più potenti. Monitorarla è utile per anticipare break changes su plugin che non ricevono aggiornamenti frequenti.
Per una guida pratica sull’installazione sicura dei plugin, puoi consultare la guida all’installazione di mod su Minecraft.
Come passare da Spigot a Paper in sicurezza: checklist passo per passo
La migrazione è semplice nella maggior parte dei casi, ma saltare il backup è l’errore che costa di più.
- Backup completo. Copia l’intera cartella del server (world, world_nether, world_the_end, plugin, configurazioni) in una posizione separata. Non procedere senza questo passaggio.
- Prepara un ambiente di staging. Replica il server su una macchina locale o su un’istanza separata. Testa lì prima di toccare la produzione.
- Scarica il JAR di Paper dalla pagina ufficiale PaperMC corrispondente alla versione Minecraft del tuo server.
- Sostituisci il JAR. Rinomina o sposta il vecchio
spigot.jare posiziona il nuovopaper.jarnella cartella del server. Aggiorna lo script di avvio per puntare al nuovo file. - Primo avvio in staging. Leggi tutta la console: cerca
[WARN]e[ERROR]. I warning NMS indicano plugin da aggiornare; gli errori critici bloccano l’avvio. - Aggiorna i plugin problematici identificati al punto precedente. Se un plugin non ha aggiornamenti disponibili, valuta un’alternativa compatibile.
- Rivedi le configurazioni. Paper genera
paper-world-defaults.ymlepaper-global.yml(nelle versioni recenti). Controlla i valori di default e confrontali con le tue impostazioni inspigot.ymleserver.properties. - Test funzionale completo. Verifica le funzionalità critiche: economy, protezioni, permessi, mini-game, chat.
- Migrazione in produzione durante un orario di bassa attività. Comunica il downtime ai giocatori in anticipo.
- Rollback. Se qualcosa va storto, ripristina il backup del punto 1 e riavvia con il vecchio JAR. Nessun dato va perso se il backup è completo.
Un consiglio: effettua la migrazione in produzione durante la notte o nei momenti di minor traffico. Le prime ore dopo il switch sono quelle in cui emergono i problemi residui, ed è meglio averle con pochi giocatori connessi.
Quando ha senso restare su Spigot?
Paper è meglio nella maggior parte dei casi, ma ci sono situazioni in cui il cambio non vale il rischio.
- Plugin legacy con NMS non aggiornabili. Se un plugin critico per il tuo server usa NMS specifici di Spigot e il suo sviluppatore ha abbandonato il progetto, migrare a Paper può romperlo senza soluzione.
- Reti con tool personalizzati testati su Spigot. Alcune reti hanno sviluppato plugin interni o sistemi di automazione strettamente dipendenti dal comportamento di Spigot. Testare tutto su Paper richiede tempo e risorse che non sempre si hanno.
- Server privati a bassissima attività. Su server con basso carico i benefici di Paper possono essere impercettibili: se giochi con 3 amici su una mappa survival, la differenza di TPS non si nota.
- Vincoli di tempo immediati. Se hai un evento in programma tra 24 ore, non è il momento di migrare. Pianifica la transizione con calma.
La regola pratica: se nessuno dei tuoi plugin usa NMS e il server ha più di 10 giocatori attivi regolarmente, il guadagno di Paper giustifica ampiamente il tempo della migrazione.
Come misurare l’impatto della migrazione con Timings e Spark
Misurare prima e dopo è l’unico modo per sapere se la migrazione ha davvero migliorato le cose.
Con Timings (integrato in Paper):
- Digita
/timings onin console per avviare la raccolta dati. - Lascia girare il server sotto carico normale per almeno 10 minuti.
- Digita
/timings reportper generare un link al report online. - Nel report, cerca le voci con il tempo medio più alto: plugin lenti, tick di entità, chunk loading.
Timings è lo strumento diagnostico standard per individuare quali plugin o attività consumano più risorse, e molti admin segnalano che ha permesso di risparmiare ore di debugging.
Con Spark (profiler esterno):
Spark va installato come plugin separato. Offre un’analisi più granulare di Timings: mostra l’uso CPU per thread, il garbage collection e i colli di bottiglia I/O. Utile per problemi che Timings non riesce a localizzare con precisione.
Metriche da registrare prima e dopo la migrazione:
| Metrica | Strumento | Cosa indica |
|---|---|---|
| TPS (Ticks Per Second) | Timings, Spark, /tps |
Fluidità generale del server |
| MSPT (Milliseconds Per Tick) | Timings, Spark | Carico del main thread per tick |
| Garbage Collection | Spark | Pressione sulla memoria JVM |
| Uso CPU per thread | Spark | Distribuzione del carico tra thread |
| I/O disco | Spark | Latenza nel caricamento chunk |
Registra i valori su Spigot, poi ripeti la stessa misurazione su Paper nelle stesse condizioni di carico. La differenza è il tuo dato reale, non una stima.
Cosa aspettarsi nelle prime settimane dopo il passaggio a Paper
Il miglioramento non è sempre immediato. Molti admin riportano che nelle prime ore dopo il switch il server si comporta in modo simile a Spigot, e i guadagni diventano evidenti solo quando il carico aumenta.
Gli errori di configurazione più comuni che peggiorano le performance invece di migliorarle:
- Aumentare i thread di chunk loading senza necessità. Paper permette di configurare il numero di thread dedicati al caricamento chunk. Su macchine con pochi core, aumentarli troppo può saturare la CPU e peggiorare il MSPT.
- Lasciare i valori di default di
paper-world-defaults.ymlsenza revisione. Alcuni default sono conservativi. Vale la pena confrontarli con la configurazione precedente dispigot.yml. - Non aggiornare i plugin dopo la migrazione. Un plugin con warning NMS che continua a girare può degradare le performance anche senza crashare il server.
La configurabilità di Paper è un’arma a doppio taglio: offre ottime leve di ottimizzazione, ma richiede competenza per non peggiorare le prestazioni.
Per server in rete con proxy (BungeeCord, Velocity), testa il backend Paper in isolamento prima di collegarlo alla rete. I problemi di compatibilità emergono più facilmente in un ambiente controllato.
Un consiglio: controlla i valori di entity-activation-range e mob-spawn-range in paper-world-defaults.yml nelle prime 48 ore. I default funzionano bene per la maggior parte dei server, ma su server con farm intensive potrebbero richiedere aggiustamenti.
Per approfondire la gestione di un server sempre online, la guida server Minecraft sempre aperto copre monitoraggio e stabilità operativa.
Perché consiglio Paper per quasi tutti i server
Paper vince il confronto non perché Spigot sia cattivo, ma perché offre più strumenti con lo stesso sforzo di gestione. L’async chunk loading da solo risolve uno dei problemi più comuni sui server pubblici: il lag da caricamento chunk durante gli spostamenti rapidi. Le feature native come anti-xray eliminano plugin che su Spigot andrebbero installati, configurati e mantenuti separatamente.
Riconosco le eccezioni: plugin legacy con NMS non aggiornabili sono un motivo reale per restare su Spigot, non una scusa. E su server privati a bassa attività, il guadagno è spesso teorico più che pratico.
La mia raccomandazione pratica: testa Paper in staging con un backup completo a portata di mano. Misura TPS e MSPT prima e dopo con Timings o Spark. Se i numeri migliorano o restano uguali, migra. Se qualcosa si rompe, il rollback richiede cinque minuti.
Hosting Paper e Spigot senza pensieri: AtomSync lo gestisce per te
Migrare a Paper è un passo tecnico. Gestire l’infrastruttura che lo fa girare in modo stabile è un altro. AtomSync offre hosting Minecraft con setup in meno di 60 secondi, storage NVMe SSD, backup automatici quotidiani e protezione DDoS fino a 1 Tbps, pensato per chi vuole concentrarsi sul server, non sull’hardware.
Il pannello Pterodactyl personalizzato da AtomSync permette di sostituire il JAR, gestire i file di configurazione e ripristinare un backup con pochi clic, senza accesso SSH. Il supporto tecnico in italiano via Discord è disponibile nei giorni lavorativi per chi ha domande sulla migrazione o sulla configurazione di Paper.
Che tu stia passando da Spigot a Paper per la prima volta o che gestisca una rete con più backend, AtomSync ti dà l’infrastruttura e il supporto per farlo senza rischi. Attiva il tuo server Minecraft oggi e testa Paper in un ambiente già pronto.
Fonti
- Paper documentation — Paper overview
- Minecraft-java-servers
- Spigot or Paper | SpigotMC - High Performance Minecraft Software
Domande frequenti
Qual è la differenza principale tra Paper e Spigot?
Paper è un fork di Spigot con ottimizzazioni aggiuntive (async chunk loading, entity activation range, anti-xray nativo) e un’API estesa. Spigot è la base da cui Paper deriva, con meno feature native e ottimizzazioni meno profonde.
Paper e Spigot sono compatibili tra loro?
Sì, Paper è un drop-in replacement per Spigot nella grande maggioranza dei casi. I plugin Bukkit e Spigot funzionano su Paper; fanno eccezione i plugin che accedono direttamente alle classi NMS interne senza aggiornamenti recenti.
Paper è meglio di Spigot per le performance?
Sì, specialmente sotto carico. Paper mantiene TPS più alti rispetto a Spigot in condizioni di stress, grazie ad async chunk loading e alla riduzione del carico sul main thread. Su server a bassa attività la differenza è spesso impercettibile.
Come si misura il miglioramento dopo la migrazione a Paper?
Usa /timings report per un report integrato o installa Spark per un’analisi più dettagliata. Registra TPS e MSPT su Spigot prima della migrazione, poi ripeti la misurazione nelle stesse condizioni su Paper per confrontare i valori reali.
Quando conviene non migrare a Paper?
Se hai plugin legacy che dipendono da NMS specifici di Spigot e non ricevono più aggiornamenti, o se gestisci una rete con tool personalizzati testati esclusivamente su Spigot, il rischio della migrazione può superare il beneficio atteso.