Pagare un server cloud per ospitare qualche applicazione personale è diventata una scelta sempre meno scontata, soprattutto quando i prezzi della DRAM rendono anche l’acquisto di un mini-PC un’operazione fuori tempo massimo. Uno sviluppatore ha raccontato sul proprio blog come ha risolto il problema: in breve, ha ripescato da un cassetto un CMF Phone 1 e lo ha trasformato nel suo server personale, sostituendo di fatto un’istanza VPS su Hetzner che ospitava alcune app web, un browser remoto e il classico corredo di servizi di supporto.

Il telefono di Nothing, con i suoi otto core ARM, 8 GB di RAM, 128 GB di storage, Wi-Fi 6, modem 5G e una batteria integrata che funge da UPS naturale, era rimasto sostanzialmente inutilizzato. Lo sviluppatore lo aveva già pagato, e le specifiche gli sembravano decisamente sprecate per un dispositivo lasciato a prendere polvere. Oggi quello smartphone fa girare Surf (un browser remoto), un tracker di finanza personale, un servizio di condivisione schermo e diverse altre applicazioni web, tutte sopravvissute ai riavvii e raggiungibili anche quando il telefono cambia rete.
I primi tentativi sono stati un fallimento. L’idea più “pulita” sembrava sostituire Android con una distribuzione Linux vera e propria, sfruttando la porta postmarketOS disponibile per il dispositivo. Wi-Fi, Bluetooth e accelerazione hardware risultavano segnalati come non funzionanti nella pagina del progetto, ma l’autore ha deciso comunque di procedere. Il risultato è stata una schermata nera dopo il boot di postmarketOS: né un server, né più un telefono.
Un CMF Phone 1 può diventare un server domestico
Il recupero del firmware Nothing OS originale si è trasformato in una piccola odissea a parte, tra un’installazione di Windows in QEMU, driver MediaTek ostili e uno strumento di flashing che si bloccava di continuo. A un certo punto il dispositivo è rimasto completamente inerte, mostrando solo uno schermo nero: la sensazione, racconta l’autore, era quella di aver trasformato un telefono perfettamente funzionante in un fermacarte.
Il telefono alla fine è tornato in vita, e la lezione appresa è stata chiara: Android dispone già di driver funzionanti per ogni componente hardware, dal Wi-Fi alla gestione energetica fino al modem. Buttare via tutto questo lavoro per rincorrere uno userspace Linux più convenzionale era la strada sbagliata. Non serviva un telefono trasformato in una macchina Linux qualunque, ma un dispositivo capace di far girare app Linux in modo affidabile, lasciando ad Android il compito di gestire l’hardware.
La soluzione è arrivata con Termux, usato come ambiente host: OpenSSH, runit come supervisore dei processi, Caddy come reverse proxy e Tailscale per un indirizzo privato stabile raggiungibile da qualsiasi dispositivo della propria rete. Per i servizi più leggeri, proot-distro ha permesso di eseguire le immagini OCI ARM64 già pronte senza modificarle, ma per il carico di lavoro più pesante, il browser Surf, la traduzione delle chiamate di sistema in userspace introduceva una latenza inaccettabile. La soluzione è stata effettuare il root del dispositivo, non per sostituire Android ma per montare lo stesso filesystem Debian con un chroot vero, capace di raggiungere il kernel Android con syscall native. Come racconta l’autore nel post pubblicato sul proprio blog, il miglioramento prestazionale non è stato affatto marginale.

Tenere sveglio un telefono pensato per risparmiare batteria ha richiesto un intervento mirato sul profilo Android: wake lock persistente, disattivazione dell’idle profondo, esenzione di Termux e Tailscale dalle restrizioni in background e configurazione della VPN always-on. L’intera configurazione, dalle versioni dei servizi ai controlli di salute, è gestita tramite Ansible da un repository privato, così che l’intero host possa essere ricostruito a comando anche su un telefono diverso, senza dover ricostruire a mano una cronologia di comandi shell dimenticati.
Per il traffico in ingresso, l’autore si affida a un Cloudflare Tunnel per le applicazioni HTTP standard, che richiede solo connessioni in uscita e continua a funzionare anche se il telefono cambia rete. Il caso più delicato riguarda Surf, la cui connessione sensibile alla latenza e con certificato TLS pinnato non tollera la terminazione TLS lato Cloudflare: la soluzione trovata è stata incapsulare l’intero flusso TLS di Surf dentro un normale WebSocket, aggiungendo un salto di rete ma mantenendo la connessione autenticata end-to-end. Il risultato pratico, testato collegandosi da un ufficio remoto tramite Tailscale, ha permesso di pilotare un vecchio iPad connesso al telefono rimasto acceso a casa.
L’autore chiarisce comunque i limiti dell’operazione: i chroot condividono lo stesso kernel Android e non vanno considerati un confine di sicurezza, il root espande la superficie di attacco e nessun dato irrecuperabile dovrebbe finire su un dispositivo del genere senza backup automatici. Resta però, a suo dire, un’alternativa concreta a un VPS pagato indefinitamente, soprattutto per chi ha già in casa uno smartphone ARM64 rootabile che non usa più.