Funktionen · Hosting und Bereitstellung

Live, und rückgängig zu machen.

Jede App erhält ein eigenes Hosting-Projekt und eine eigene trytofu.app-Adresse. Eine neue Version wird vor dem Build geprüft und erst veröffentlicht, nachdem sie eine echte Anfrage beantwortet hat; sie bleibt in einem Verlauf erhalten, aus dem Sie sie wiederherstellen können – im Dashboard oder indem Sie Ihren Agenten bitten.

Dokumentation lesenPreise ansehen

Was Ihr Agent aufruft

  • deploy
  • status
  • listDeployments
  • getBuildLogs
  • getRuntimeLogs
  • rollback
Drei Wege zu Tofu

Beginnen Sie bei Ihrem Agenten. Oder bei GitHub.

Jeder Weg durchläuft dieselbe Prüfung und wird auf dieselbe Weise veröffentlicht. Ein Update ersetzt nur den Quellcode desselben Projekts – Einstellungen, Adresse und Verlauf bleiben erhalten.

  1. Ihr Coding-Agent

    Empfohlen. Fügen Sie den Einrichtungs-Prompt in einen beliebigen Coding-Agent ein. Der Agent prüft und installiert den Tofu-Client, Sie bestätigen einen Code im Browser, und er lädt hoch, prüft und stellt aus dem Gespräch heraus bereit – wenn Sie ihn darum bitten. Ein Update ersetzt den Quellcode desselben Projekts, während Einstellungen, Adresse und Verlauf erhalten bleiben.

    Agent und CLI

    ❯ setup prompt pasted · code approved

  2. Ein GitHub-Branch

    Importieren Sie einen Branch mit einer Nur-Lese-Berechtigung, an einen Commit gebunden. Aktivieren Sie automatische Updates, in jedem Tarif: Ein Push stellt dann den neuesten Commit des Branches durch dieselbe Prüfung bereit.

    main · push → deploy

  3. Die Kommandozeile

    Der eigenständige Client führt dieselben Operationen in einem Terminal oder einer Cloud-Sandbox aus: Node.js 22 oder höher, eine Freigabe im Browser, kein Schlüssel, der irgendwo eingefügt wird.

    $ node tofu-agent.mjs login

Vor dem Build

Geprüft, bevor gebaut wird. Bei einer Ablehnung wird nichts übermittelt.

Die Dateien, die hochgeladen werden sollen, durchlaufen zuerst die Sicherheitsprüfung. Unmittelbar vor dem Build läuft dieselbe Prüfung noch einmal über die exakten Bytes. Ein Fund, der anderen Menschen schaden könnte (ein bekanntes Malware-Muster, Phishing oder ein offengelegter Schlüssel), stoppt den Vorgang an dieser Stelle: Nichts erreicht den Hosting-Anbieter, und die bereits veröffentlichte Version wird weiter ausgeliefert. Entscheidungen, die nur Ihre eigene App betreffen, etwa eine Tabelle, die jeder bearbeiten kann, kommen als Warnungen zurück und gehen so online, wie Sie sie gebaut haben.

Was die Prüfung liest – und was nicht

Veröffentlichung

Ein Build, der „bereit“ meldet, ist noch keine veröffentlichte App.

Tofu schaltet die Adresse Ihrer App erst um, wenn die neue Version an ihrer eigenen Adresse eine Anfrage beantwortet hat.

  1. Geprüft

    Der Snapshot wird geprüft. Ein blockierender Fund stoppt hier, und es wird nichts übermittelt.

  2. Gebaut

    Der Hosting-Anbieter baut sie im eigenen Hosting-Projekt der App, während die veröffentlichte Version weiter ausgeliefert wird.

  3. Beantwortet

    Tofu ruft die eigene Adresse des neuen Builds auf. Nur eine Antwort zählt; eine Anmeldeseite gilt als geschützt, nicht als defekt.

  4. Veröffentlicht

    Erst dann wird Ihre trytofu.app-Adresse umgeschaltet. Was fehlschlägt, lässt die vorherige Version weiter ausliefern.

Was Ihr Agent zurückliest

deploy wartet eine begrenzte Zeit auf eine endgültige Antwort, und status setzt dort an. Die Antwort ist maschinenlesbar, sodass ein Agent die Adresse nie öffnen muss, um zu raten.

publiclyReachable
Nur wahr, wenn eine anonyme Anfrage beantwortet wurde – die Antwort auf „Kann ein Besucher die App jetzt öffnen?“
verification.access
public (ausgeliefert), protection (anonym abgelehnt: eine Zugangssperre, kein fehlgeschlagener Build) oder unreachable (eine Adresse, die mit 404 oder gar nicht antwortet, wird vorher bis zu 16 Sekunden lang erneut abgefragt).
serving
Ob diese Bereitstellung die Adresse der App beantwortet; ein fertiger Build, der nicht ausgeliefert wird, wurde nicht veröffentlicht.
tofu · deployexample · excerpt
{
  "status": "ready",
  "managedUrl": "https://franks-kitchen-3f9a1c07b2e4.trytofu.app/",
  "serving": true,
  "publiclyReachable": true,
  "verification": {
    "access": "public",
    "httpStatus": 200
  }
}
Verlauf, Protokolle und Zurücksetzen

Jeder Versuch, festgehalten. Jede gesunde Version, in einem Schritt zurück.

  • listDeployments

    Verlauf

    Jeder Versuch mit seinem Status und der Angabe, welcher aktuell ist: die zuletzt tatsächlich veröffentlichte Version, nicht einfach die neueste.

  • getBuildLogs · getRuntimeLogs

    Protokolle

    Die Build- und Laufzeitprotokolle, die die Plattform erzeugt hat; Zeilen, die nach Zugangsdaten aussehen, werden so weit wie möglich herausgefiltert.

  • rollback

    Zurücksetzen

    Richtet die Adresse auf eine frühere, fertige Bereitstellung aus, ohne neuen Build. Ihre Daten werden nicht mit zurückgesetzt, und Ihr Agent fragt Sie vorher.

Wenn ein Update fehlschlägt

Ein fehlgeschlagener Build ändert nichts an der veröffentlichten Version. Ihr Agent erhält, was er zur Behebung braucht.

Eine neue Version wird erst veröffentlicht, nachdem sie antwortet; ein fehlgeschlagener Build lässt die veröffentlichte Version also, wo sie war. Tofu übergibt Ihrem Coding-Agenten den Fehler, die zugehörigen Protokolle und die nächsten Schritte.

  1. Die veröffentlichte Version bleibt

    Eine Version, die nicht gebaut werden kann oder nicht antwortet, wird nie veröffentlicht. Ihre App liefert weiter die Version davor aus.

  2. Eine Anleitung für Ihren Agenten

    Der Fehler, eine Zusammenfassung seiner Protokolle ohne Secret-Werte und die nächsten Schritte – in jedem Tarif gleich.

  3. Beheben, dann erneut bereitstellen

    Ihr Agent ändert Ihren Code und stellt erneut bereit – durch dieselbe Sicherheitsprüfung und dieselbe Antwortprüfung.

Wenn Sie Ihren Agenten bitten, eine fehlgeschlagene Bereitstellung zu beheben, liest er repairContext: den fehlgeschlagenen Versuch, was jetzt live ist, und die nächsten Schritte. Tofu schreibt nie von sich aus in Ihren Code oder Ihr GitHub-Repository.

Umgebungsvariablen

Namen in Tofu. Werte nur schreibbar.

Namen und Geltungsbereiche stehen im Dashboard; die Werte gehen direkt an den Hosting-Anbieter. Ein Secret wird dort nur schreibbar gespeichert und nie zurückgelesen – nicht vom Dashboard, nicht von Tofu, nicht von Ihrem Agenten.

Eine eingefügte .env-Datei behandelt jeden Wert als Secret, VERCEL_*-Namen sind reserviert, und die Werte, die Tofu für eine verwaltete Datenbank schreibt, sind von Tofu verwaltet und schreibgeschützt. Das Speichern einer Änderung löst keine neue Bereitstellung aus; die nächste Bereitstellung übernimmt sie.

GitHub – in jedem Tarif

Ein Push, und es wird bereitgestellt. Durch dieselbe Prüfung.

Importieren Sie einen Branch, bestätigen Sie das Framework und schalten Sie automatische Updates ein. Jeder Push stellt den neuesten Commit auf dem Branch über dieselbe Prüfung und dieselbe Veröffentlichung bereit; wenn ein Update fehlschlägt, bleibt Ihre letzte funktionierende Version online.

Tofu liest das Repository mit einem kurzlebigen, schreibgeschützten Token und schreibt nie hinein. Ein manueller Upload pausiert die automatischen Updates, statt von ihnen überschrieben zu werden, und Ihr Agent kann sie ausschalten; zum Einschalten braucht es Ihre eigene GitHub-Freigabe im Browser.

Was Tofu hostet

Web-Apps, die auf Anfragen reagieren. In dem Stack, den Sie bereits gewählt haben.

Jede dieser Varianten beantwortet Anfragen und skaliert zwischen Anfragen auf null herunter. Jeder Tarif hostet Ihre Seiten und den Code dahinter.

Websites und Web-Frameworks
  • Next.js
  • Vite
  • Astro
  • SvelteKit
  • Nuxt
  • React Router
  • Gatsby
  • Static HTML

Der Hosting-Anbieter baut sie aus dem eigenen Build des Frameworks – oder veröffentlicht eine fertige statische Website unverändert.

Python
  • FastAPI
  • Flask
  • Django
  • Python

Gebaut aus dem Manifest der App und gestartet als HTTP-Prozess, der die Adresse beantwortet.

Go
  • Go

Gebaut aus der go.mod der App und gestartet als HTTP-Prozess, der PORT liest.

JavaScript-Server
  • Express
  • Hono
  • NestJS
  • Node.js server

Eine einzige Einstiegspunktdatei, die der Hosting-Anbieter anhand ihres Namens findet; sie wird als HTTP-Prozess gestartet – der Server beantwortet /.

Container
  • Dockerfile (container)

Das Image, das Ihre eigene Containerdatei beschreibt: vom Hosting-Anbieter gebaut und als Dienst ausgeführt.

Demnächst verfügbar.

  • Vorschau-Bereitstellungen. Updates folgen einem Branch und einem App-Wurzelverzeichnis pro Projekt – keine Vorschauen für Pull Requests, keine Tags und jeweils nur der neueste Stand statt jedes einzelnen Commits.

  • Laufzeit-Protokolle für Container-Apps. Sie waren bisher nicht lesbar, und die Abfrage meldet sie als nicht verfügbar, statt ein leeres Protokoll anzuzeigen.

Noch nicht umgesetzt

  • Größere fertige Websites brauchen einen kostenpflichtigen Tarif. Der Free-Tarif stellt eine Website online, die Sie als fertige Seiten senden – bis zu 500 Dateien und 50 MB.

Was Tofu nicht macht

  • Alles, was dauerhaft laufen muss. Ein Hintergrund-Worker, ein Dienst, der eine Queue abarbeitet, ein dauerhaft laufender Scheduler oder ein Nicht-HTTP-Dienst lässt sich mit Tofu nicht betreiben – und kein Tarif ändert das.

  • Ein eigener Cron-Zeitplan. Cron-Jobs in der vercel.json einer App werden hier nicht registriert; der Zeitplan gehört dem Dienst, der die App aufruft.

  • Eine Verfügbarkeitsgarantie in jedem Tarif. Tofu arbeitet daran, Ihre Apps verfügbar zu halten; eine Verfügbarkeitszusage (ein SLA) ist auf Anfrage erhältlich: Sagen Sie uns, was Sie brauchen.

Einen Prompt einfügen. In 10 Minuten online.

Ihre App samt Datenbank, Ihre Domain und Ihre Anmeldung – in etwa 10 Minuten mit dem Agenten, den Sie schon nutzen.

Kostenlos starten