Fonctionnalités

Tout ce qu’il y a entre « ça marche » et « c’est en ligne ».

Hébergement, base de données, votre domaine, connexion et son e-mail, statistiques et paiements — le tout raccordé par un seul compte Tofu, chaque partie un outil que votre agent de codage appelle. Ce que fait chaque partie, où sont ses limites et ce qui n’est pas encore construit.

Ce qu’un seul compte raccorde

Raccordé pour vous. Chacun un outil que votre agent appelle.

Chaque partie a sa propre page : comment elle fonctionne, ce que votre agent appelle pour y accéder et où elle s’arrête.

  • Hébergement et déploiements

    En ligne, et réversible.

    Chaque déploiement est contrôlé avant le build, publié seulement une fois qu’il répond et consigné dans l’historique : une version saine antérieure se restaure en une action.

    • deploy
    • rollback
    • getRuntimeLogs
  • Base de données

    Une vraie base de données, déjà raccordée.

    Postgres géré, créé avec le déploiement, raccordé au build par des secrets en écriture seule et transféré sur demande vers votre propre organisation Supabase.

    • databaseCreate
    • databaseStatus
  • Votre domaine

    Votre domaine, HTTPS inclus.

    Sur Cloudflare, une seule approbation et Tofu écrit les enregistrements DNS ; partout ailleurs, il vous montre les enregistrements exacts et les vérifie.

    • domainConnect
    • domainAuthorize
    • domainVerify
  • Connexion et e-mail

    La connexion Google, sans Google Cloud.

    « Continuer avec Google » et la connexion par e-mail pour votre application, avec l’e-mail de création de compte envoyé depuis votre propre domaine une fois celui-ci vérifié. Pas de projet Google Cloud, pas de client OAuth, pas de clés.

    • appAuthConfigure
    • appAuthEmailConnect
  • Statistiques

    Le trafic, sans traqueur.

    Vues, pages les plus consultées et sources principales pour chaque application, comptées par Tofu sur son propre point de terminaison. Pas de cookies, pas d’adresses IP conservées, pas de compte de statistiques à ouvrir.

    • siteAnalytics
    • setSiteAutoInject
  • Agent et CLI

    Mettre en ligne sans quitter votre agent.

    Un seul client local pour tout agent de codage qui parle MCP : les mêmes projets et le même historique que le tableau de bord, après une approbation dans votre navigateur.

    • login
    • ingest
    • status
  • Paiements

    Les paiements, directement sur votre compte.

    Les acheteurs paient sur la page de paiement de Stripe, et l’argent arrive sur votre propre compte Stripe. Tofu crée vos liens de paiement, à usage unique ou récurrents, et indique à votre application qui a payé. Aucune clé à copier, et Tofu ne prend aucune commission.

    • appPaymentsConnect
    • appPaymentsSetup
    • appPaymentsLinkCreate

Le forfait Free met en ligne une application avec le code qui tourne derrière ses pages et une base de données gérée, conservée tant que l’application est en ligne, et la page des tarifs indique quels forfaits incluent votre propre domaine. Les achats de domaine sont à part. Voir les tarifs

Connecter votre compte Stripe à une application qui tourne sur un serveur demande un forfait payant, et les paiements réels s’ouvrent une fois le premier paiement de votre forfait effectué. Comment fonctionnent les paiements

Trois points d’entrée

Amenez l’application que vous avez. Par quelque chemin qu’elle arrive dans Tofu.

Chaque chemin aboutit au même type de projet, passe par le même contrôle avant le build et se met en ligne de la même façon.

  1. Votre agent de codage

    Recommandé. Collez l’invite de configuration dans n’importe quel agent de codage. L’agent vérifie et installe le client de Tofu, vous approuvez un code dans votre navigateur, et il envoie, contrôle et déploie depuis la conversation — quand vous le lui demandez. Une mise à jour remplace le code source du même projet, tandis que ses réglages, son adresse et son historique restent.

    Agent et CLI

    ❯ setup prompt pasted · code approved

  2. Une branche GitHub

    Importez une branche avec un accès en lecture seule, épinglée à un commit. Activez les mises à jour automatiques, quel que soit le forfait : chaque push déploie le dernier commit de la branche en passant par le même contrôle.

    main · push → deploy

  3. La ligne de commande

    Le client autonome exécute les mêmes opérations depuis un terminal ou un bac à sable dans le cloud : Node.js 22 ou plus récent, une approbation dans votre navigateur, aucune clé collée nulle part.

    $ node tofu-agent.mjs login

Ce que Tofu héberge

Des applications web pilotées par les requêtes. Avec les technologies que vous avez déjà choisies.

Un site préconstruit, un framework web, un serveur Python, Go ou JavaScript, ou votre propre conteneur. Chacun répond à une requête et s’arrête entre les requêtes ; la détection propose le préréglage, et vous le confirmez.

Sites et frameworks web
  • Next.js
  • Vite
  • Astro
  • SvelteKit
  • Nuxt
  • React Router
  • Gatsby
  • Static HTML

Construits par le fournisseur à partir du build propre au framework — ou, s’il s’agit d’un site statique préconstruit, publiés tels quels.

Python
  • FastAPI
  • Flask
  • Django
  • Python

Construit à partir du manifeste propre à l’application et démarré comme un processus HTTP qui répond sur l’adresse.

Go
  • Go

Construit à partir du go.mod propre à l’application et démarré comme un processus HTTP qui lit PORT.

Serveurs JavaScript
  • Express
  • Hono
  • NestJS
  • Node.js server

Un seul fichier d’entrée, que le fournisseur trouve par son nom, démarré comme un processus HTTP — le serveur répond sur /.

Conteneurs
  • Dockerfile (container)

L’image décrite par votre propre fichier de conteneur, construite par le fournisseur et exécutée comme un service.

Rien ne tourne en permanence : un traitement en arrière-plan, un consommateur de file d’attente ou un ordonnanceur toujours actif ne passent pas par Tofu, quel que soit le forfait. Hébergement et déploiements

Le contrôle de sécurité

Lu avant le build. Et clair sur ce qu’il a lu.

Avant tout build, Tofu applique un ensemble fixe de règles déterministes aux fichiers exacts sur le point d’être envoyés : clés de production présentes dans le dépôt, tables où le Row Level Security est désactivé, politiques d’écriture ouvertes et signatures connues de logiciels malveillants. Un constat qui pourrait nuire à d’autres personnes (signature de logiciel malveillant connue, hameçonnage, clé divulguée) arrête le build, et la version déjà en ligne reste en service. Les choix qui ne touchent que votre propre application, comme une table ouverte, sont signalés comme des avertissements et ne l’arrêtent jamais.

Chaque résultat nomme les fichiers qu’il a lus et ce qu’aucune règle ne recherche — il dit ce qu’il a contrôlé, et rien de plus.

Comment fonctionne le contrôle de sécurité

Pas encore construit

  • Acheter un domaine pour vous. La recherche, les devis et la transmission au bureau d’enregistrement existent, mais le parcours d’achat n’est pas ouvert.

  • Les déploiements de préversion. Les mises à jour GitHub suivent une seule branche et une seule racine d’application par projet — pas d’aperçu de pull request, pas de tags.

  • Un rapport d’analyse approfondie détaillé, la rotation du mot de passe de la base de données, l’export des statistiques, les notifications et les équipes.

  • Une console SQL. C’est une décision de principe : le code source envoyé est une entrée non fiable, et un seul identifiant d’opérateur donnerait accès à tous les projets gérés.

  • Tout ce qui doit rester en marche. Un traitement en arrière-plan, un consommateur de file d’attente, un ordonnanceur toujours actif ou un service non HTTP ; les crons du vercel.json d’une application ne sont pas non plus enregistrés.

Collez un prompt. En ligne en 10 minutes.

Votre application, sa base de données, votre domaine et votre connexion — avec l’agent que vous utilisez déjà, en 10 minutes environ.

Commencer gratuitement