|
Come ho costruito la mia pagina personale gratis con Forgejo e un cloud europeo gratuito
Come pubblicare una pagina bio statica con deploy automatico usando uno script PHP, un hosting gratuito europeo e un'istanza Forgejo, senza dipendenze proprietarie.
Cercando un’alternativa per pubblicare una pagina personale con nome, bio, qualche link, la prima risposta ovvia nel mondo FOSS è LinkStack: open source, lo puoi installare dove vuoi, ma pensato per gestire molti utenti con database, pannello admin e backend. Per una pagina statica monoutente con cinque link è superfluo.
GitHub Pages funziona bene: pushi il codice e il sito è online. Ma questa apparente semplicità nasconde un dettaglio che si tende a dare per scontato: tutto il sistema dipende da Microsoft.
A quel punto ho fatto il passo più banale possibile: ho preferito HTML e CSS puri. Nessun framework, nessuna libreria, nessuna dipendenza. Una pagina statica che si carica ovunque ma senza rinunciare alla comodità del deploy automatico esattamente come fa GitHub Pages, ma senza passare da Microsoft.
Il codice è ospitato sulla mia istanza Forgejo, una delle principali alternative libere a GitHub e GitLab: Git, ma sotto il tuo controllo. Se non hai un server tuo, forgejo.it offre account gratuiti ed è gestita dalla community italiana di @opensource, non una corporation, ma persone. Per domande o supporto c’è anche il gruppo Telegram: t.me/+bJOYNC7G8S44Zjdk
Mancava l’hosting. Cercando se esistesse davvero un piano gratuito europeo senza pubblicità, ho trovato Alwaysdata: 1 GB di spazio, PHP 8.3, Apache, SSH, git preinstallato, dominio .alwaysdata.net con HTTPS gratuito. La caratteristica decisiva sono gli Scheduled Tasks: dal menù laterale sotto Advanced > Scheduled Tasks si pianifica l’esecuzione periodica di un comando senza toccare file di configurazione.
La soluzione è uno script PHP che interroga l’API pubblica di Forgejo, confronta l’ultimo commit con quello precedente, e se c’è qualcosa di nuovo aggiorna il sito in automatico. Lo Scheduled Task lo esegue a intervalli regolari. A costo zero, senza CI/CD e senza dipendenze proprietarie.
Indice dei contenuti
Una pagina bio in HTML e CSS puri
Questo sistema è pensato per siti statici semplici: quello che una volta si chiamava “homepage personale”. Nome, una foto, una descrizione di chi sei, i tuoi link, i tuoi contatti.
Lo script sincronizza quello che c’è nel repository. Quello che ci metti dentro è una scelta tua, ma non serve molto: un file index.html con il CSS nell'<head>, un’immagine avatar e qualche link.
Un riferimento concreto è il mio repository contact-page-static: un file HTML completo con CSS incluso, pronto da clonare e personalizzare. Nella cartella deploy/ trovi gli script completi, con funzionalità aggiuntive come l’aggiornamento automatico del timestamp nel footer e altro.
Cos’è l’API pubblica di Forgejo
Ogni istanza Forgejo espone per default una serie di endpoint REST accessibili senza autenticazione per i repository pubblici. In parole semplici puoi fare una domanda al server: “qual è l’ultimo commit di questo repository?” e lui ti risponde con un JSON, senza che tu debba fare login o usare token.
Lo script PHP sfrutta esattamente questo. Ad ogni esecuzione chiede a Forgejo lo SHA dell’ultimo commit, ovvero un identificativo univoco di quaranta caratteri che cambia ad ogni push. Lo confronta con quello salvato in locale: se sono uguali non è cambiato niente, se sono diversi c’è qualcosa di nuovo da deployare. Semplice, efficiente, senza dipendenze.
Per testare se l’API pubblica di forgejo è accessibile senza autenticazione per i repository pubblici, utilizza il comando:
curl -s "https://git.emanuelegori.uno/api/v1/repos/emanuelegori/contact-page-static/commits?limit=1"La struttura dell’endpoint è leggibile direttamente dall’URL:
api/v1/repos/— punto di accesso all’API REST di Forgejoemanuelegori/— il proprietario del repositorycontact-page-static— il nome del repositorycommits?limit=1— restituisce solo l’ultimo commit
Sostituisci emanuelegori e contact-page-static con i tuoi dati. Se usi forgejo.it o un’altra istanza, cambia anche il dominio.
La risposta è un JSON completo con i dati del commit, nessun errore, nessun token richiesto.
Come funziona il deploy automatico: polling, non webhook
Ci sono due modi per tenere sincronizzato un server con un repository Git.
Il primo è il webhook: ogni volta che fai un push, Forgejo invia una notifica HTTP al tuo server, che si aggiorna immediatamente. È veloce e preciso, ma su hosting condiviso lo script che gestisce il webhook gira nel contesto HTTP del web server, con limiti di esecuzione stretti. Un’operazione come git clone rischia di andare in timeout. Espone inoltre un endpoint pubblico che richiede una verifica della firma per non essere abusato.
Il secondo è il polling: è il server che chiede periodicamente a Forgejo “è cambiato qualcosa?” tramite l’API. Se è cambiato qualcosa rispetto all’ultima esecuzione scarica le novità. Se no, non fa niente. Funziona ovunque, anche su hosting condivisi, senza configurazioni aggiuntive lato server. L’unico compromesso è un ritardo tra il push e l’aggiornamento del sito proporzionale alla frequenza impostata nello Scheduled Task ma per una pagina personale statica è più che accettabile.
Il meccanismo che utilizzo è questo: l’API pubblica di Forgejo espone un endpoint che restituisce l’ultimo commit del repository, con il suo SHA, ovvero un identificativo univoco di quaranta caratteri. Lo script PHP salva questo SHA su un file. Alla prossima esecuzione, confronta lo SHA salvato con quello restituito dall’API: se sono uguali, non è cambiato niente; se sono diversi, c’è un aggiornamento da deployare.
L’endpoint è:
GET /api/v1/repos/{owner}/{repo}/commits?limit=1Lo script PHP
Lo script, pensato per funzionare su Alwaysdata, fa esattamente tre cose: controlla se ci sono novità, clona il repository in una cartella temporanea, copia i file nella document root. È volutamente semplice.
Personalizza UTENTE e REPO con i dati del tuo repository. La lista EXCLUDE contiene i file che non vuoi copiare nella document root: file di documentazione, cartelle di configurazione Forgejo, script di deploy.
La struttura sul server
Un dettaglio importante: lo script non vive dentro la cartella www/. Vive un livello sopra, nella tua home. Non è raggiungibile da browser, non può essere invocato via URL, non è esposto al web. Viene eseguito solo dal sistema come comando da terminale, tramite lo Scheduled Task.
/home/tuoaccount/
├── update-site.php <- eseguito dal cron, invisibile dal web
├── last_commit.txt <- SHA dell'ultimo deploy
└── www/ <- document root, quello che vede il browser
├── index.html
├── style.css
└── ...Il file last_commit.txt è necessario per il funzionamento del sistema. Contiene una sola riga: lo SHA dell’ultimo commit deployato. Se alla prossima esecuzione lo SHA remoto è identico, lo script esce in meno di un secondo senza fare nulla. Nessun clone, nessuna copia, nessuno spreco. Il deploy avviene solo quando c’è un cambiamento reale.
Se hai bisogno di forzare un aggiornamento, il modo più diretto è connetterti via SSH e richiamare lo script a mano:
php ~/update-site.phpVedi l’output in tempo reale e sai subito se il deploy è andato a buon fine.
Deploy in otto passi
Il flusso completo è questo:
- Apri un account su forgejo.it e crea un repository pubblico
- Carica i tuoi file HTML e CSS nel repository
- Apri un account su Alwaysdata con il piano gratuito
- Carica
update-site.phpnella tua home su Alwaysdata (fuori dawww/) - Dal pannello Alwaysdata vai in Advanced > Scheduled Tasks
- Crea un nuovo task con comando:
php /home/tuoaccount/update-site.php - Imposta la frequenza a 30 minuti
- Fai un push sul repository
Entro mezz’ora, il sito è online.
Da quel momento, il flusso di lavoro è semplice: modifichi i file in locale, fai un push su Forgejo, aspetti al massimo trenta minuti. Non devi toccare il server, non devi fare deploy manuali, non devi fare niente. Lo script fa tutto.
Conclusione
La pagina bio funziona. Costa zero. Non dipende da nessuna piattaforma proprietaria che domani
potrebbe cambiare le condizioni.
Non è la soluzione più sofisticata che esiste, ma non doveva esserlo. Doveva
essere semplice, autonoma e facile da mantenere.
Fonti e Riferimenti
