Il mio blog "self-hostato" in casa.

Piattaforme come Medium risolvono un problema reale: permettono a chiunque di scrivere e pubblicare con pochissimo sforzo. È proprio per questo che le ho utilizzate, spostando nel tempo i miei articoli tra Medium, WordPress e altri servizi.

Il problema è che un servizio che sembra gratuito può cambiare modello di business, limitare la distribuzione o mettere gli articoli dietro un paywall che prima non esisteva per chi legge i tuoi articoli, così come per esempio è successo con Medium. Con il self-hosting questa incertezza scompare: il dominio, i file e la decisione su chi può leggerli rimangono miei.

Inoltre le piattaforme di blogging avevano anche un vantaggio evidente: offrivano da subito un sito curato e piacevole da leggere per i visitatori. Oggi l’AI rende molto più semplice progettare e perfezionare un blog personale con la stessa attenzione. Medium e WordPress, quindi, non sono più una scelta obbligata soltanto perché mettono a disposizione un’interfaccia e un template pronto all’uso.

Un setup volutamente semplice

L’obiettivo non era ricreare in casa WordPress, con database, plugin, pannello di amministrazione e codice server di cui questo blog non aveva bisogno. Ho scelto invece un generatore di siti statici: trasforma Markdown e template in pagine HTML già complete prima della pubblicazione. Al server di casa non resta quasi altro da fare che consegnare quei file al browser. Per questo sito ho scelto Eleventy.

Ho tenuto essenziale anche l’infrastruttura:

• NAS: spesso sottovalutato come semplice dispositivo di backup, è a tutti gli effetti un piccolo server silenzioso, con dischi per le copie di sicurezza e la possibilità di eseguire container Docker.
• Docker: mi permette di eseguire il web server in un ambiente isolato e riproducibile, facile da aggiornare o sostituire.
• Caddy: ero abituato a Nginx e Apache e non lo avevo mai provato. Si occupa automaticamente di ottenere e rinnovare i certificati TLS e di reindirizzare HTTP verso HTTPS. Con un Caddyfile molto piccolo serve inoltre i file statici e abilita HTTP/2 e HTTP/3 senza configurazioni aggiuntive.
• Nessun database: niente MySQL, PHP, pannello di amministrazione o lavoro backend per ogni visita.
• Dominio e porte: il sottodominio del blog punta al mio IP pubblico fisso e soltanto il traffico web viene inoltrato a Caddy.

Mantenere il sito statico lo rende veloce, portabile e facile da ripristinare. Elimina inoltre servizi che consumerebbero risorse senza aggiungere valore a questo progetto.

Scalare facendo meno

Scalare non significa solo comprare macchine più potenti o aggiungere risorse dinamicamente in base alla domanda. Significa anche evitare complessità quando non è necessaria e pensare a soluzioni minimali ed efficienti, che permettano al sistema di gestire molte richieste con poche risorse.

Ad esempio, la scelta di utilizzare esclusivamente pagine statiche e di fare a meno di un database per un blog personale va proprio in questa direzione. Ridurre la complessità è quindi anche un modo per scalare meglio, o quantomeno per rendere la scalabilità più semplice da gestire.

Il compromesso sulla sicurezza

Un tunnel limiterebbe l’esposizione diretta, ma in cambio introdurrebbe un’altra dipendenza esterna. Per ora, tramite il mio IP pubblico fisso, espongo verso Caddy soltanto le porte web; l’interfaccia di amministrazione del NAS rimane privata. Firewall, aggiornamenti e monitoraggio restano comunque necessari.

Conclusione

Quando un progetto è piccolo, vale la pena prendere più spesso in considerazione il self-hosting. L’AI rende questi sistemi più semplici da costruire e mantenere. La scelta migliore è partire in modo essenziale e aggiungere complessità soltanto quando la richiede un problema reale, non una scalabilità immaginata in anticipo.