Un bureau dans un onglet, adossé à des API de fichiers et d'IA
Puter affiche dans un onglet de navigateur un bureau à fenêtres, avec ses dossiers, un dock et un magasin d'applications. Derrière l'interface, un backend garde les fichiers de chaque compte, tient une base clé-valeur, relaie les requêtes vers des modèles d'IA et héberge des sites. Une app web y accède par le SDK Puter.js pour enregistrer des données ou interroger un modèle, sans serveur à elle. Le projet se dit « internet computer » open source, et puter.com en héberge une instance publique.
Des apps sans backend, confinées à leur dossier AppData
- Puter.js s'installe par npm (
@heyputer/puter.js) ou par une balise<script>, et tourne sur un site, dans une app Puter, sous Node.js ou dans un worker. Il couvre l'IA, l'authentification, les fichiers, la base clé-valeur, l'hébergement statique, les workers serverless et la connexion pair à pair. - Cloisonnement par défaut : une app reçoit le dossier
~/AppData/<id-de-l-app>/et sa propre base clé-valeur, et ne voit rien d'autre du compte. Pour un fichier, un dossier ou l'adresse e-mail de l'utilisateur, elle passe par une demandeputer.perms.request. - Un sous-domaine par site ou par app : chaque compte publie sur des sous-domaines que Puter crée à la volée,
<nom>.site.<domaine>ou<nom>.app.<domaine>. - IA sur ses propres clés : sur une instance maison, une clé Claude, OpenAI ou Gemini posée dans
config.jsonactive le fournisseur, et le profil Composeailance Ollama avectinyllamapour un modèle local. - Accès aux comptes : connexion OIDC (Google, Apple, Microsoft ou autre fournisseur), captcha par preuve de travail sans service externe, inscriptions fermées par
disable_user_signup.
DNS joker et compteur de coûts à couper sur une instance maison
L'auto-hébergement demande cinq services et un DNS joker. Le docker-compose.yml officiel, que la documentation présente comme le plus proche d'un déploiement de production gérable sur une seule machine, démarre Puter avec MariaDB, Valkey, DynamoDB Local, un stockage S3 RustFS et Caddy. Puter aiguille les requêtes d'après le nom d'hôte (api., site., app., s3.) : il faut un enregistrement DNS joker et, pour une instance publique, un certificat joker obtenu par défi DNS, que l'image Caddy fournie ne sait pas demander seule. Le npm start du README lance le mode développement, sur SQLite.
Les quotas de puter.com s'appliquent aussi chez soi. Une instance maison mesure ce que coûte chaque compte (octets servis, requêtes au stockage, jetons d'IA) contre le forfait gratuit du service hébergé : 0,50 dollar par mois, soit environ 2,5 Gio de téléchargement. Au-delà, les opérations échouent en erreur 402, sans offre payante pour relever le plafond. Le guide d'auto-hébergement conseille de poser "unlimitedMetering": true.
Sur puter.com, l'utilisateur paie sa consommation. Avec ce que le projet appelle le « User-Pays Model », chaque utilisateur d'une app Puter.js se connecte avec son compte Puter et règle l'IA et le stockage consommés au-delà d'un forfait mensuel gratuit. Le développeur ne paie aucune infrastructure, mais chacun de ses utilisateurs doit avoir un compte Puter.
La licence AGPL ne couvre pas la marque. Le code est sous AGPL-3.0, mais TRADEMARK.md impose à toute version modifiée redistribuée de retirer les logos Puter et d'indiquer qu'elle n'est pas approuvée par Puter Technologies Inc. Enregistrer un nom de domaine qui contient la marque est interdit.
Dix versions publiées en moins de quatre mois. Numérotées par année et par mois, elles vont de la 26.07, sortie le 8 juillet 2026, à la 26.10.1, sortie le 25 octobre ; le dernier commit date du 27 octobre 2026. MariaDB/MySQL et SQLite sont les bases prises en charge. Le support de PostgreSQL, apporté par la communauté et absent de la production de puter.com, peut encore buter sur des requêtes peu courantes.