La nuova infrastruttura di PeaceLink

L'associazione PeaceLink nasce nel 1991 come rete telematica pacifista, in anni in cui internet in Italia passava ancora per modem e BBS. Per oltre dieci anni il sito e le mailing list dell'associazione sono stati ospitati gratuitamente da ITBnet, uno dei provider pionieri della telematica sociale italiana, che ha garantito hosting del server web, gateway e gestione del DNS durante la fase di crescita di PeaceLink. Con l'aumento del traffico e dell'uso di banda, l'associazione ha iniziato ad affiancare a quel supporto gratuito anche dei costi di gestione autonomi per il mantenimento e l'aggiornamento dei propri server.

Nel 2017 è arrivato il salto dai server fisici a server virtuali nel Cloud. Una scelta finanziariamente sostenibile grazie al programma di crediti TechSoup per le organizzazioni non profit, e resa sicura dalle competenze tecniche interne, che ci hanno permesso di evitare sia la dipendenza da un unico fornitore sia i costi nascosti tipici del cloud commerciale. È stato, a suo modo, un esercizio di indipendenza: usare il cloud senza farci usare da esso, prestando estrema attenzione ad evitare di vincolarsi nelle soluzione proprietarie dei fornitori commerciali.

È in questo solco — trent'anni di infrastruttura costruita e ripensata passo dopo passo, sempre con l'obiettivo di restare autonomi — che si inserisce la decisione, presa nel 2024, di fare un secondo salto: rimpatriare tutta l'infrastruttura di PeaceLink dal cloud commerciale statunitense (il cosiddetto BigTech) verso un'infrastruttura europea, sotto il nostro pieno controllo. Questa scelta è antecedente alla più ampia presa di coscienza europea sulla sovranità digitale, innescata nel 2025 dal comportamento dell'amministrazione Trump. Oggi, a distanza di tempo, raccontiamo pubblicamente per la prima volta questo percorso, che si può dire concluso: non un singolo servizio critico di PeaceLink gira più su cloud statunitense.

Non è stato un progetto facile: una migrazione di questa portata, fatta da volontari, richiede tempo se si vuole farla senza interrompere i servizi e senza perdere un solo dato. Ed è quello che è successo: nessun downtime percepito da chi usa i nostri servizi, nessuna perdita di dati, per nessuno dei servizi coinvolti.

I principi che ci hanno guidato

Erano già chiari fin dall'inizio, nel 2024, e li confermiamo oggi che il percorso è concluso. Riassumiamo i principi di fondo.

• Indipendenza dal big-tech, tanto infrastrutturale quanto applicativa. Non ci basta più "usarli senza essere usati": vogliamo non avere più niente a che fare con loro, con la sola eccezione di poche integrazioni puntuali dove il beneficio supera nettamente il rischio (tipicamente funzionalità a bassissimo volume di chiamate, senza dati sensibili in transito).
• Controllo pieno dei dati, dei nostri e di chi ci affida i propri: dove risiedono, chi vi accede, come vengono trattati.
• Permanenza nel perimetro legislativo europeo, sia per l'infrastruttura sia per i servizi che vi si appoggiano, in coerenza con GDPR e con una visione della sostenibilità energetica che non si limiti a certificati di carbon-neutrality di dubbia tracciabilità.
• Agilità, per poter sperimentare con le tecnologie moderne — orchestrazione dei container, automazione, intelligenza artificiale — senza essere ostaggio della complessità di un'infrastruttura monolitica o dei costi nascosti del cloud commerciale.
• Etica, non essere in alcun modo collegati ad aziende complici dell'industria bellica, pesantemente coinvolte nell'estrattivismo di dati e risorse, e gravate da conflitti di interesse nel trattamento dei dati, soprattutto nell'era dell'AI.

Il riposizionamento dei servizi

Fin dall'inizio del percorso avevamo in mente la necessità di alleggerire il carico di manutenzione legato ad alcuni servizi storicamente offerti da PeaceLink, e al tempo stesso riposizionare l'offerta su tecnologie critiche, nel senso letterale di "difficili da replicare": intelligenza artificiale applicata, data intelligence, analisi di dati aperti, strumenti di ricerca e comunicazione avanzati. Sono ambiti dove il nostro contributo tecnico e volontario ha un valore reale, perché richiede competenze rare.

Un sito web o una mailing list oggigiorno non rientrano più in questa categoria. Preferiamo che il volontariato ingegneristico che offriamo crei valore che altrove non si trova, senza togliere spazio a opportunità lavorative che potrebbero remunerare chi offre già questi stessi servizi.

Questo è il senso profondo della migrazione: non solo un cambio di fornitore, ma un cambio di postura. L'infrastruttura che abbiamo costruito in questi due anni è pensata per sostenere gli ambiti in cui vogliamo crescere.

Dove siamo arrivati

Oggi PeaceLink gira su un'infrastruttura presso Hetzner, un provider tedesco con data center alimentati al 100% da energie rinnovabili e pienamente conforme alla legislazione europea su privacy e protezione dei dati. Tutta l'infrastruttura è descritta come codice, versionata, riproducibile e verificabile; non più configurazioni manuali sparse su macchine virtuali, ma un sistema automatizzato, monitorato e con backup ridondanti su infrastruttura separata.

Nessuno sponsor, nessuna pubblicità

Un'ultima cosa che ci teniamo a dire, perché non è scontata: tutto questo — la progettazione, la migrazione, la manutenzione quotidiana — è stato fatto da volontari, nel tempo libero. PeaceLink non ha sponsor, non ospita pubblicità e non monetizza i dati di chi usa i suoi servizi. Il costo dell'infrastruttura è sostenuto dalle piccole donazioni di chi crede in un'informazione e in una comunicazione indipendenti. Se questo lavoro ti sembra utile, sostienici: è quello che ci permette di continuare a farlo senza compromessi.

Dettagli tecnici

Nota: l'infrastruttura descritta qui sotto è gestita internamente come codice (infrastructure-as-code) e non è pubblicamente consultabile, per non fornire indicazioni dettagliate a potenziali malintenzionati. Quanto segue è una descrizione ad alto livello dei componenti adottati, non della loro configurazione.

La piattaforma

Il cuore della nuova infrastruttura è un cluster k3s su nodi Hetzner Cloud con sistema operativo Linux openSUSE MicroOS (immutabile, aggiornamenti atomici). k3s è una distribuzione leggera e certificata di Kubernetes (non un progetto diverso o parallelo: è Kubernetes stesso, impacchettato in un singolo binario e ottimizzato per essere più snello nell'uso di risorse), pensata per ambienti dove i requisiti hardware di un cluster Kubernetes "standard" sarebbero eccessivi. Il provisioning è interamente gestito con OpenTofu, basato su un modulo open source della community (terraform-hcloud-kube-hetzner) che abbiamo adattato alle nostre esigenze specifiche.

Componenti chiave della piattaforma:

• Cilium come CNI (Container Network Interface), il componente che gestisce la rete tra i pod del cluster: instradamento del traffico, policy di rete e sicurezza a livello di rete.
• Traefik come ingress controller, con autoscaling delle repliche in base al carico, e certificati TLS automatici via cert-manager/Let's Encrypt, dietro un load balancer dedicato fornito nativamente da Hetzner.
• Longhorn come storage distribuito, con storage-class multiple (SSD locale per i carichi che richiedono IOPS elevate, volumi di rete per tutto il resto) e backup incrementali su object storage compatibile S3, su infrastruttura separata dal cluster.
• Kured per il riavvio automatico e coordinato dei nodi in caso di aggiornamenti che lo richiedano.
• Prometheus e Grafana per metriche e alerting, Loki con Fluent Bit per la centralizzazione dei log.
• Cert-manager per il ciclo di vita dei certificati TLS.

Tutti gli applicativi, sia quelli distribuiti come manifest Kubernetes "raw" sia quelli installati via Helm, sono gestiti come configurazione dichiarativa versionata.

Solo software open source

Ogni componente di questa infrastruttura è software open source, e in molti casi software libero in senso stretto (licenze GPL, AGPL, MPL e simili), anche se, con decine di componenti diversi, tracciare con precisione la licenza esatta di ciascuno non è semplice. È una scelta di principio prima ancora che tecnica, e in un paio di casi ci ha portato deliberatamente controcorrente: usiamo OpenTofu e non Terraform, perché quest'ultimo è passato a una licenza che non è più open source; OpenTofu è il fork nato dalla community per restare libero. Per lo stesso motivo, per il nostro Git self-hosted usiamo Forgejo, il fork di Gitea nato in risposta a scelte di governance ritenute troppo orientate al modello commerciale. Quando un progetto open source cambia rotta verso qualcosa di più chiuso, la nostra scelta è restare dalla parte del fork libero.

Database: l'addio a MariaDB

Una delle decisioni più significative prese durante il percorso è stata l'abbandono di MariaDB come motore relazionale principale. Nel 2025, l'operatore MariaDB su Kubernetes, nella nostra esperienza, non si è dimostrato sufficientemente maturo per un ambiente di produzione: gestione dello switchover meno affidabile di quanto sperato, integrazione con lo storage distribuito non sempre lineare, complessità operativa superiore al beneficio. Nel frattempo pare che la situazione sia migliorata, ma noi avevamo già deciso di convertire progressivamente tutti gli applicativi verso PostgreSQL. Specificamente con l'operatore CloudNative-PG (CNPG), che si è rivelato molto solido nell'automazione di failover, backup e gestione del ciclo di vita dei cluster database su Kubernetes. Anche PhPeace, il CMS che PeaceLink sviluppa e mantiene internamente per il proprio sito, è stato convertito per usare Postgres al posto di MariaDB/MySQL.

Identità e accesso

Tutti gli applicativi condividono un Single Sign-On basato su Keycloak. Questo copre gli strumenti interni (Forgejo, Nextcloud, Superset...), l'autenticazione sul sito peacelink.it, e servizi più delicati come la posta elettronica: Roundcube (webmail) e i client di posta (Thunderbird e simili) si autenticano tutti attraverso Keycloak, con un meccanismo di token dedicato per i protocolli che non parlano OAuth2 nativamente.

Posta elettronica

Lo stack di posta è stato riscritto quasi per intero. Sendmail e Sympa, entrambi difficilmente compatibili con un'architettura a container orchestrati, sono stati sostituiti rispettivamente da Postfix e Mailman. Il filtraggio anti-spam, che utilizzava SpamAssassin, è passato a Rspamd, più performante e con un'integrazione più naturale con Redis per l'apprendimento Bayesiano e con la firma ARC dei messaggi in uscita. La consegna locale è gestita da Dovecot via LMTP, con autenticazione OAuth2 verso Keycloak per webmail e client nativi.

Va detto che gestire oggi un servizio di posta davvero indipendente è probabilmente la sfida più difficile di tutto questo percorso. Un pugno di grandi player, per lo più statunitensi, decide di fatto cosa arriva a destinazione e cosa finisce in spam o viene silenziosamente scartato; nel panorama italiano, inoltre, gran parte dei provider di posta si affida ciecamente a filtri anti-spam commerciali senza offrire alcun canale per gestire le eccezioni. Il risultato pratico è che, se il traffico non passa attraverso uno dei grandi player, le probabilità di consegna calano sensibilmentem indipendentemente da quanto sia corretta la propria configurazione tecnica (SPF, DKIM, DMARC, reputazione dell'IP). Per questo stiamo sperimentando diversi servizi di invio rigorosamente europei per l'inoltro della posta in uscita: un'area che comporta integrazioni non banali e un costo economico, ma che riteniamo necessaria per non dipendere, anche qui, da un singolo fornitore extra-UE.

Applicativi

Diversi servizi storici sono stati sostituiti con alternative più adatte a un'esecuzione containerizzata e orchestrata. Per nessuno di questi cambi esisteva uno strumento di migrazione pronto all'uso in grado di preservare storico e struttura dei dati così come li avevamo noi: in più di un caso — il passaggio da RocketChat a Mattermost e da Trello a Nextcloud Deck sono gli esempi più significativi — abbiamo dovuto scrivere il codice di migrazione, per portare messaggi, canali, schede e cronologia da un sistema all'altro senza perdere nulla.

• RocketChat (che richiedeva MongoDB, database che abbiamo scelto di non introdurre nello stack) è stato sostituito da Mattermost, gestito tramite operatore dedicato.
• Trello è stato sostituito da Nextcloud Deck, all'interno della nostra istanza Nextcloud.
• Google Maps come componente UI è stato sostituito da OpenStreetMap (manteniamo, per ora, solo la geocodifica lato server con Google Maps).
• Il Google reCAPTCHA è stato sostituito dal captcha di Cloudflare.
• I repository, in precedenza su GitLab.com, sono ora ospitati su una nostra istanza self-hosted di Forgejo, con pipeline CI/CD basate su Forgejo Actions e runner dedicati: nessuna dipendenza residua da GitLab.
• Apache Superset è stato introdotto come piattaforma di analisi e visualizzazione per i nostri dataset di open data (disarmo, conflitti, spesa militare, qualità dell'aria e altri), a supporto diretto della strategia di riposizionamento verso la data intelligence descritta nella prima parte.
• Al posto di Google Analytics, per le statistiche dei nostri siti usiamo Matomo, self-hosted, configurato nella modalità meno invasiva possibile per la privacy di chi ci visita: tracciamento senza cookie e indirizzi IP anonimizzati, con i dati che restano interamente sui nostri server. Ci siamo anche costruiti un'integrazione su misura per tracciare le visite degli assistenti di intelligenza artificiale che recuperano le nostre pagine per conto di chi li interroga (ChatGPT, Claude, Perplexity e altri), che non eseguendo JavaScript sfuggono al tracciamento standard: i log del server vengono intercettati e instradati verso Matomo lato server, così da avere comunque visibilità su quanto e come questi assistenti leggono i nostri contenuti.

Nextcloud e Collabora, al posto di Google Drive e Google Docs

Uno dei cambiamenti più concreti per la redazione di PeaceLink è l'abbandono di Google Drive e Google Docs a favore di Nextcloud (cloud.peacelink.it), affiancato da Collabora Online per l'editing collaborativo in tempo reale di documenti, fogli di calcolo e presentazioni. Nextcloud è diventato, secondo la nostra esperienza diretta, un prodotto finalmente maturo: gestione e condivisione file, calendari, contatti, gestione progetti con Deck ed editing documentale con Collabora coprono ormai comodamente ciò che prima chiedevamo a Google Workspace, con in più il vantaggio di avere tutto sotto il nostro controllo diretto.

Questa maturazione arriva in un momento in cui il tema della sovranità digitale europea è tornato centrale nel dibattito pubblico: sempre più amministrazioni e organizzazioni in Europa stanno considerando alternative ai grandi fornitori statunitensi, e Nextcloud è spesso il punto di partenza.

Mastodon

L'istanza Mastodon di sociale.network, che girava su Azure, è stata anch'essa migrata sulla nostra infrastruttura Hetzner: componenti web, streaming e Sidekiq su Kubernetes, database su CNPG, ricerca su Elasticsearch, Redis per le code dei job di Sidekiq, il pub/sub dello streaming in tempo reale e la cache.

Al momento in cui abbiamo affrontato questa migrazione, all'inizio del 2026, la community non aveva ancora un helm chart ufficiale e stabile per Mastodon su Kubernetes; abbiamo quindi scritto i manifesti a mano, componente per componente. È stato un lavoro impegnativo, ma ci ha lasciato molta più visibilità e controllo su ogni singolo componente dello stack, cosa che, per un servizio complesso come Mastodon, riteniamo importante.

L'assistente AI

Parallelamente alla migrazione infrastrutturale, abbiamo sviluppato un assistente basato su intelligenza artificiale, pensato per attivisti pacifisti e ambientalisti, con accesso a fonti documentali specializzate (l'archivio storico di PeaceLink a vari dataset aperti) tramite un'architettura a agenti e RAG (retrieval-augmented generation). Gira anch'esso sulla nostra infrastruttura Kubernetes e include servizi Python (FastMCP, FastAPI), tracciamento (Langfuse) e oauth2proxy. Grazie all'estensione pgvector di PostgreSQL, il medesimo operatore che usiamo per tutti gli altri applicativi (CNPG) funge anche da database vettoriale per la ricerca semantica del RAG, senza bisogno di un database dedicato separato. Ne parleremo diffusamente in un articolo dedicato.

Cosa resta fuori

Per scelta, alcuni servizi restano ancora esterni: la geocodifica di Google Maps (per l'affidabilità, a fronte di un volume di chiamate irrilevante ai fini della privacy), Cloudflare per DNS, cache degli asset statici e captcha, e un registry Docker pubblico per le immagini dei nostri applicativi (che abbiamo affiancato con un registry interno per quelle più sensibili).

Per le riunioni usiamo il servizio di Jitsi, di cui stiamo sperimentando una nostra istanza dedicata. Durante la pandemia abbiamo usato estensivamente l'ottimo BigBlueButton, ma si è rilevato troppo impegnativo da mantenere, vista anche la ridotta frequenza dei nostri incontri e webinars.

Vuoi darci una mano?

Tutto questo è stato costruito e mantenuto da volontari, nel tempo libero. Se conosci una o più di queste tecnologie (Kubernetes, PostgreSQL, sviluppo con AI / Python, o una qualsiasi delle altre citate in questo articolo) e vorresti mettere a disposizione un po' del tuo tempo per PeaceLink, contattaci!