Fonctionnalités · Hébergement et déploiements

En ligne, et réversible.

Chaque application dispose de son propre projet d’hébergement et de son adresse trytofu.app. Une nouvelle version est contrôlée avant le build, publiée seulement après avoir répondu à une vraie requête, et conservée dans un historique depuis lequel vous pouvez la restaurer — dans le tableau de bord, ou en le demandant à votre agent.

Lire la documentationVoir les tarifs

Ce que votre agent appelle

  • deploy
  • status
  • listDeployments
  • getBuildLogs
  • getRuntimeLogs
  • rollback
Trois points d’entrée

Commencez par votre agent. Ou par GitHub.

Chaque chemin passe par le même contrôle et la même publication, et une mise à jour remplace le code source du même projet — ses réglages, son adresse et son historique restent.

  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

Avant le build

Contrôlé avant le build. Un refus n’envoie rien.

Les fichiers sur le point d’être envoyés passent d’abord par le contrôle de sécurité, et le même contrôle s’exécute de nouveau sur les octets exacts juste avant le build. Un problème détecté qui pourrait nuire à d’autres personnes (signature de logiciel malveillant connue, hameçonnage ou clé divulguée) arrête la procédure : rien n’atteint le fournisseur, et la version déjà en ligne continue de répondre. Les choix qui ne concernent que votre propre application, comme une table que tout le monde peut modifier, sont signalés comme des avertissements et sont mis en ligne tels que vous les avez conçus.

Ce que le contrôle lit, et ce qu’il ne lit pas

Publication

Un build qui annonce « prêt » n’est pas encore une application en ligne.

Tofu ne fait basculer l’adresse de votre application qu’une fois que la nouvelle version a répondu à une requête qui lui est propre.

  1. Contrôlé

    L’instantané est contrôlé ; un problème bloquant arrête tout ici et rien n’est envoyé.

  2. Build terminé

    Le fournisseur effectue le build dans le projet d’hébergement propre à l’application, pendant que la version en ligne continue de répondre.

  3. Réponse reçue

    Tofu interroge l’adresse propre au nouveau build. Seule une réponse compte ; un écran de connexion est interprété comme une protection, pas comme une panne.

  4. Publié

    C’est seulement alors que l’adresse trytofu.app de votre application bascule. Tout échec laisse la version précédente en ligne.

Ce que votre agent relit

deploy attend, pendant un temps limité, une réponse définitive, puis status prend le relais. La réponse est lisible par une machine : un agent n’a jamais besoin d’ouvrir l’adresse pour le savoir.

publiclyReachable
Vrai uniquement lorsqu’une requête anonyme a été servie — la réponse à « un visiteur peut-il l’ouvrir maintenant ? »
verification.access
public (servie), protection (refusée anonymement : une protection d’accès, pas un build en échec) ou unreachable (une adresse qui répond 404 ou ne répond pas est d’abord réinterrogée pendant 16 secondes au plus).
serving
Indique si ce déploiement répond à l’adresse de l’application ; un build prêt qui n’est pas en service n’a pas été publié.
tofu · deployexample · excerpt
{
  "status": "ready",
  "managedUrl": "https://franks-kitchen-3f9a1c07b2e4.trytofu.app/",
  "serving": true,
  "publiclyReachable": true,
  "verification": {
    "access": "public",
    "httpStatus": 200
  }
}
Historique, journaux et retour en arrière

Chaque tentative, consignée. Toute version saine, restaurée en une étape.

  • listDeployments

    Historique

    Chaque tentative avec son statut, et celle qui est actuelle : la version réellement publiée en dernier, pas simplement la plus récente.

  • getBuildLogs · getRuntimeLogs

    Journaux

    Les journaux de build et d’exécution produits par la plateforme, les lignes qui ressemblent à des identifiants étant filtrées autant que possible.

  • rollback

    Retour en arrière

    Fait pointer l’adresse vers un déploiement antérieur qui est prêt, sans nouveau build. Vos données ne reviennent pas en arrière, et votre agent vous demande d’abord.

Quand une mise à jour échoue

Un build en échec ne change rien en ligne. Votre agent reçoit ce qu’il faut pour corriger.

Une nouvelle version n’est publiée qu’après avoir répondu : un build qui échoue laisse donc la version en ligne là où elle était. Tofu transmet à votre agent de codage l’échec, les journaux et les prochaines étapes.

  1. La version en ligne reste en place

    Une version dont le build échoue ou qui ne répond pas n’est jamais publiée. Votre application reste en ligne avec la précédente.

  2. Une note pour votre agent

    L’échec, un résumé de ses journaux sans les valeurs secrètes, et les prochaines étapes — les mêmes pour tous les forfaits.

  3. Corriger, puis redéployer

    Votre agent modifie votre code et redéploie, en repassant par le même contrôle de sécurité et le même contrôle de disponibilité.

Demandez à votre agent de corriger un déploiement échoué et il lit repairContext : la tentative qui a échoué, ce qui est en ligne maintenant et ce qu’il faut faire ensuite. Tofu n’écrit jamais de lui-même dans votre code ni dans votre dépôt GitHub.

Variables d’environnement

Les noms, dans Tofu. Les valeurs, en écriture seule.

Les noms et les portées se trouvent dans le tableau de bord ; les valeurs vont directement au fournisseur d’hébergement. Un secret y est stocké en écriture seule et n’est jamais relu — ni par le tableau de bord, ni par Tofu, ni par votre agent.

Un fichier .env collé traite chaque valeur comme un secret, les noms VERCEL_* sont réservés, et les valeurs que Tofu écrit pour une base de données gérée sont gérées par Tofu et en lecture seule. Enregistrer une modification ne déclenche pas de redéploiement ; le déploiement suivant la prend en compte.

GitHub, sur tous les forfaits

Un push, et c’est déployé. Avec le même contrôle.

Importez une branche, confirmez le framework, puis activez les mises à jour automatiques. Chaque push déploie le dernier commit de la branche via le même contrôle et la même publication ; si une mise à jour échoue, votre précédente version saine reste en ligne.

Tofu lit le dépôt avec un jeton en lecture seule et de courte durée de vie, et n’y écrit jamais. Un envoi manuel met les mises à jour automatiques en pause au lieu d’être écrasé, et votre agent peut les désactiver ; les réactiver demande votre propre autorisation GitHub dans le navigateur.

Ce que Tofu héberge

Des applications web qui répondent aux requêtes. Dans la stack que vous avez déjà choisie.

Chacune de ces options répond à une requête et redescend à zéro entre deux requêtes. Tous les forfaits hébergent vos pages et le code qui les fait tourner.

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.

Bientôt disponible.

  • Déploiements de prévisualisation. Les mises à jour suivent une seule branche et une seule racine d’application par projet — pas de prévisualisation de pull request, pas de tags, et la tête de branche la plus récente plutôt que chaque commit.

  • Journaux d’exécution des applications en conteneur. Ils n’ont pas pu être lus jusqu’ici, et la lecture les signale comme indisponibles plutôt que d’afficher un journal vide.

Pas encore développé

  • Les sites finis plus volumineux nécessitent un forfait payant. Le forfait Free met en ligne un site que vous envoyez sous forme de pages finies, jusqu’à 500 fichiers et 50 MB.

Ce que Tofu ne fait pas

  • Tout ce qui doit rester en marche. Un traitement en arrière-plan, un consommateur de file d’attente, un planificateur toujours actif ou un service non HTTP ne peut pas passer par Tofu, et aucun forfait n’y change rien.

  • Votre propre planification cron. Les crons du vercel.json d’une application ne s’enregistrent pas ici ; la planification appartient à ce qui appelle l’application.

  • Une garantie de disponibilité, quel que soit le forfait. Tofu s’emploie à garder vos applications disponibles, et un engagement de disponibilité (un SLA) peut être obtenu sur demande : dites-nous ce qu’il vous faut.

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