Puter trasforma il browser in un sistema operativo: perché divide gli utenti

Una parte sempre più ampia del software quotidiano passa dal browser: editor di testo, fogli di calcolo, strumenti per collaborare, storage remoto, ambienti di sviluppo. Il progetto Puter nasce esattamente da questa idea, ma la porta più avanti rispetto ai classici servizi cloud. Si tratta di un ambiente desktop open source per il browser Web che punta a trasformare il software con cui “navighiamo” ogni giorno in una sorta di sistema completo, auto-ospitabile e personalizzabile, con applicazioni integrate e un’infrastruttura pensata anche per chi sviluppa software.

Puter prova a costruire una piattaforma realmente utilizzabile: storage cloud, applicazioni native nel browser, pubblicazione di web app, supporto AI, database e persino funzioni serverless. Non cerca di “scimmiottare” Windows o Linux sul web; tenta piuttosto di creare un ambiente operativo interamente accessibile tramite browser, senza dipendere da infrastrutture proprietarie.

La novità è che Puter è appena uscito dalla fase beta, dopo 2 anni di sviluppo, oltre 370 contributori, centinaia di migliaia di download e decine di migliaia di stelle su GitHub.

Il problema principale: tutti pensano che Puter sia una VM remota

Nel mondo delle soluzioni self-hosted capita raramente che un progetto riesca contemporaneamente ad attirare entusiasmo, scetticismo tecnico e discussioni quasi filosofiche sul senso stesso del software moderno. Ma è esattamente quello che sta succedendo con Puter.

La maggior parte delle incomprensioni nasce da un equivoco fondamentale: appena si guarda l’interfaccia di Puter, la mente corre immediatamente verso desktop Linux remoti, VDI aziendali, ambienti tipo Citrix, Kasm, Guacamole, noVNC, workstation accessibili via browser.

Visivamente il richiamo è inevitabile: finestre, desktop, file manager, applicazioni, icone, drag-and-drop. Il fatto è che Puter non funziona affatto come una macchina virtuale remota tradizionale.

Non c’è un sistema operativo Linux completo che gira lato server. Non c’è streaming grafico di un desktop remoto. Non esiste una GPU virtualizzata che renderizza finestre native da inviare via rete. Il rendering avviene direttamente nel browser dell’utente, tramite JavaScript e componenti web.

Tant’è vero che il codice di Puter usa principalmente JavaScript e TypeScript, mentre la distribuzione self-hosted supporta Linux, macOS e Windows. Gli sviluppatori indicano come requisito minimo Node.js 24+, almeno 2 GB di RAM e descrivono una configurazione relativamente semplice, attivabile anche tramite Docker.

Puter: un computer remoto che gira nel browser

L’idea alla base di Puter ricorda alcuni progetti storici come eyeOS, OS.js oppure i primi tentativi di desktop remoto HTML5. Puter integra tuttavia una quantità di servizi decisamente superiore: dopo il login, l’utente si trova davanti a un’interfaccia desktop con finestre, file manager, applicazioni, notifiche e archiviazione cloud. È possibile fare subito una prova collegandosi con la demo disponibile online.

Tra le applicazioni incluse compaiono editor di testo, registratore vocale, fotocamera, fogli di calcolo e strumenti multimediali. L’obiettivo dichiarato è offrire un ambiente unificato per lavorare e archiviare dati senza passare continuamente da servizi differenti.

Dal punto di vista tecnico l’interfaccia gira interamente nel browser e sfrutta il rendering lato client; non si tratta quindi di un desktop remoto tradizionale trasmesso in streaming video come avviene con VNC o RDP (Desktop remoto). La UI risponde direttamente nel browser dell’utente, riducendo latenza e consumo di banda.

Una scelta interessante riguarda il frontend: gli sviluppatori hanno evitato framework come React o Angular, preferendo JavaScript “vanilla” e jQuery. Una decisione che può sembrare anacronistica, ma che ha una logica precisa: ridurre i layer di astrazione permette infatti di controllare meglio prestazioni, dimensione del bundle e compatibilità interna.

Self hosting: installazione locale e infrastruttura

L’installazione locale di Puter si può avviare clonando il repository GitHub ed eseguendo i comandi che seguono:

git clone https://github.com/HeyPuter/puter
cd puter
npm install
npm start

L’ambiente avvia normalmente il servizio all’indirizzo puter.localhost:4100. In alternativa è prevista la distribuzione tramite Docker e Docker Compose, con mount dedicati per configurazione e storage persistente.

La piattaforma genera automaticamente un file di configurazione che definisce porte HTTP, protocollo, dominio pubblico e parametri di accesso. Chi utilizza reverse proxy basati su Nginx o Cloudflare può esporre Puter via HTTPS configurando le variabili relative alla porta pubblica e al protocollo.

La versione self-hosted crea un account predefinito con password casuale mostrata nella console di sviluppo: è bene modificare immediatamente le credenziali dopo il primo accesso.

Perché molti utenti lo considerano “inferiore a una VM”

Sebbene Puter sia ormai considerabile che un progetto “di lungo corso” (due anni di sviluppo non sono pochi per uscire dalla beta…), una delle critiche più in voga risulta davvero pungente: “qualunque cosa faccia Puter, una macchina virtuale (VM) la fa meglio“.

Dal punto di vista strettamente infrastrutturale, è difficile sostenere il contrario. Tuttavia, Puter non nasce per sostituire le VM: le sue applicazioni sono web app integrate nell’ecosistema della piattaforma. Non si installa un software Linux arbitrario come avverrebbe in Ubuntu o Debian; non si esegue un container Docker per pubblicare servizi personalizzati; non si avvia un browser desktop completo capace di comportarsi come una workstation remota tradizionale.

Puter non è assolutamente progettato per sostituire una distribuzione Linux o una piattaforma VDI (Virtual Desktop Infrastructure) enterprise. L’idea di fondo è quella di costruire:

• un cloud personale browser-native;
• un ambiente applicativo distribuito;
• una piattaforma web self-hosted;
• un layer unificato per storage, autenticazione e applicazioni;
• un ecosistema di web app integrate.

In altre parole, Puter è molto più vicino a una reinterpretazione moderna di Google Drive, Dropbox o ChromeOS che non a una workstation Linux remota.

Open source, comunità e sostenibilità del progetto

Uno dei fattori che sta contribuendo alla crescita di Puter è la forte componente partecipativa. Progetti di questo tipo richiedono manutenzione continua: compatibilità browser, sicurezza delle API, gestione delle dipendenze Node.js, integrazione AI e aggiornamenti frontend.

Inoltre la scelta di costruire una piattaforma così ampia aumenta inevitabilmente la complessità interna: non è affatto semplice mantenere stabilità in un software che combina desktop virtuale, storage cloud, runtime applicativo e servizi backend nello stesso ambiente.

Resta comunque un progetto tecnico molto interessante da osservare. Per anni, infatti, il browser è stato considerato soltanto un punto d’accesso alle applicazioni; Puter prova invece a trasformarlo direttamente nel computer stesso. Può sembrare ambizioso, forse perfino eccessivo in certi aspetti. Eppure l’evoluzione del software cloud sta andando esattamente in quella direzione.