Il mio server di produzione non usa container

C'è un momento in ogni progetto personale in cui ti chiedi se dovresti containerizzare tutto.

Hai letto di Docker. Conosci Kubernetes, o almeno ne hai sentito parlare abbastanza da sapere che "non fa per te per questo progetto". Hai visto configurazioni di deploy eleganti con compose file, health check, restart policy. E poi guardi il tuo server — un VPS Ubuntu da venti euro al mese — e ti chiedi se stai facendo le cose nel modo sbagliato.

La risposta, nel mio caso, è no. E ci ho messo un po' ad arrivarci senza senso di colpa.

Cosa gira in produzione

ReD Sposi è un'app per il mio matrimonio. Il backend è un server Express su Node.js. La landing page è Next.js. Il pannello admin è Vite + React. Tre processi, un server, un dominio con sottodomini.

Barba Studio è un'app di prenotazione per barberie. Altro server Express, altro processo.

Gestionale Molinari è il mio sistema contabile interno. Ancora Express.

Tutto gira su un VPS Ubuntu, gestito con PM2. Nginx davanti come reverse proxy. Certificati Let's Encrypt via Certbot. Deploy via SSH + git pull + pm2 reload.

ssh server
cd /var/www/red-sposi-api
git pull
npm install --production
pm2 reload red-sposi-api

Fine. Non c'è altro.

Perché non Docker

Non è che Docker sia sbagliato. Docker è lo strumento giusto per molti contesti: ambienti di sviluppo riproducibili, deploy su infrastruttura cloud managed, team con più persone che devono allineare gli ambienti, applicazioni che scalano orizzontalmente.

Per i miei progetti, nessuna di queste condizioni si applica.

Sono l'unico sviluppatore. L'ambiente di sviluppo e quello di produzione divergono un poco, ma abbastanza poco da non causare problemi reali — uso le stesse versioni di Node, lo stesso schema MongoDB, le stesse variabili d'ambiente. Quando si rompe qualcosa, lo so in dieci minuti e sono già davanti al laptop.

La scala non è un problema. ReD Sposi ha qualche centinaio di invitati. Barba Studio ha utenti reali ma non ha picchi che un singolo processo non riesca a gestire. Gestionale Molinari sono io.

Containerizzare questi servizi non aggiungerebbe affidabilità — aggiungerebbe strati di astrazione da capire, mantenere, e fare debug quando qualcosa va storto alle tre di notte.

Cosa fa PM2 che basta

PM2 gestisce tre cose fondamentali che mi servono davvero:

Restart automatico. Se un processo crasha, PM2 lo riavvia. Non è sofisticato come un orchestratore, ma copre il caso più comune — un errore non gestito che fa crashare il processo — senza bisogno di altro.

Gestione dei log. pm2 logs mi dà i log di tutti i processi in un posto solo. pm2 logs red-sposi-api --lines 100 mi dà l'ultimo centinaio di righe di un processo specifico. È abbastanza.

Reload senza downtime. pm2 reload riavvia il processo in modo graceful — aspetta che le connessioni attive si chiudano prima di sostituire il processo. Per applicazioni con qualche centinaio di utenti non simultanei, funziona.

┌────────────────────┬────┬─────────┬──────┬──────┬────────┐
│ name               │ id │ status  │ cpu  │ mem  │ uptime │
├────────────────────┼────┼─────────┼──────┼──────┼────────┤
│ red-sposi-api      │ 0  │ online  │ 0%   │ 85mb │ 12D    │
│ red-sposi-landing  │ 1  │ online  │ 0%   │ 120mb│ 12D    │
│ red-sposi-admin    │ 2  │ online  │ 0%   │ 55mb │ 12D    │
│ barba-studio-api   │ 3  │ online  │ 0%   │ 72mb │ 45D    │
│ gestionale         │ 4  │ online  │ 0%   │ 61mb │ 7D     │
└────────────────────┴────┴─────────┴──────┴──────┴────────┘

Questo è tutto quello che vedo quando apro il server. È leggibile, è immediato, è sufficiente.

Il costo nascosto della complessità

C'è un costo reale nell'adottare strumenti più sofisticati di quello che serve. Non è solo il tempo di configurazione iniziale — è il carico cognitivo permanente.

Ogni strato di infrastruttura che aggiungi è uno strato che devi capire quando le cose vanno male. Un container che non si avvia, un network bridge che non instrada il traffico, un volume che non monta — questi problemi hanno soluzioni, ma richiedono tempo e attenzione in momenti in cui preferiresti non sprecarli.

Per un solo sviluppatore che gestisce più prodotti in parallelo, la semplicità dell'infrastruttura non è un compromesso — è un moltiplicatore. Più semplice è il deploy, più veloce è il ciclo di iterazione, più bassa è la soglia per spedire una fix.

Quando cambierò idea

Cambierò stack di deploy quando avrò un motivo concreto. Alcuni esempi di motivi concreti:

• Un prodotto inizia a ricevere picchi di traffico che richiedono scaling orizzontale
• Entro in un team che usa già container e devo allinearmi
• Ho bisogno di ambienti di staging e produzione perfettamente identici per un bug difficile da riprodurre
• Il costo di un'interruzione di servizio supera il costo di un'infrastruttura più robusta

Nessuna di queste condizioni si applica oggi. Quando si applicherà, adotterò lo strumento giusto.

Nel frattempo, pm2 reload mi bastano due secondi.