Features · Hosting & deploys
Live, and reversible.
Every app gets its own Tofu address. A new version is checked before it builds, published only after it answers a real request, and kept in a history you can restore from — in the dashboard, or by asking your agent.
What your agent calls
deploystatuslistDeploymentsgetBuildLogsgetRuntimeLogsrollback
Start from your agent. Or from GitHub.
Each path goes through the same check and the same publication, and an update replaces the same app’s source — its settings, address and history stay.
Your coding agent
Recommended. Paste the setup message into any coding agent. The agent checks and installs Tofu’s client, you approve one code in your browser, and it uploads, checks and deploys from the conversation — when you ask it to. Agent & CLI
❯ setup message pasted · code approvedA GitHub branch
Import one branch with a read-only grant, pinned to a commit. Turn on automatic updates, on any plan, and a push deploys the branch’s latest commit through the same check.
main · push → deployThe command line
The standalone client runs the same operations from a terminal or a cloud sandbox: Node.js 22 or newer, one approval in your browser, no key pasted anywhere.
$ node tofu-agent.mjs login
Checked before it builds. A refusal submits nothing.
The files about to be uploaded go through the safety check first, and the same check runs again on the exact bytes right before the build. A finding that could harm other people (a known malware shape, phishing or a leaked key) stops it there: nothing reaches the provider, and the version already live keeps serving. Choices that only affect your own app, like a table anyone can edit, come back as warnings and go online as you built them.
A build that says ready is not yet a live app.
Tofu moves your app’s address only after the new version has answered a request of its own.
Checked
The snapshot is checked; a blocking finding stops here and submits nothing.Built
The new version is built while the live version keeps serving.Answered
Tofu requests the new build’s own address. Only an answer counts; a sign-in wall reads as protected, not broken.Published
Only then does your Tofu address move. Anything that failed leaves the previous version serving.
What your agent reads back
deploy waits a bounded time for a settled answer, and status continues from there. The answer is machine-readable, so an agent never has to open the address to guess.
publiclyReachable- True only when an anonymous request was served — the answer to “can a visitor open it now?”
verification.accesspublic(served),protection(refused anonymously: an access wall, not a failed build) orunreachable(an address that answers 404 or not at all is asked again for up to 16 seconds first).serving- Whether this deployment answers the app’s address; a ready build that is not serving was not published.
{
"status": "ready",
"managedUrl": "https://corner-bakery-3f9a1c07b2e4.trytofu.app/",
"serving": true,
"publiclyReachable": true,
"verification": {
"access": "public",
"httpStatus": 200
}
}Every attempt, on the record. Any healthy one, back in a step.
listDeployments
History
Every attempt with its status, and which one is current: the version last actually published, not simply the newest.
getBuildLogs · getRuntimeLogs
Logs
The build and runtime logs the platform produced, with lines that look like credentials filtered out on a best-effort basis.
rollback
Rollback
Points the address at an earlier deployment that is ready, without a new build. Your data does not move back, and your agent asks you first.
A failed build changes nothing live. Your agent gets what it needs to fix it.
A new version is published only after it answers, so a build that fails leaves the live version where it was. Tofu hands your coding agent the failure, its logs and the next steps.
The live version stays
A version that fails to build or to answer is never published. Your app keeps serving the one before it.A brief for your agent
The failure, a summary of its logs with secret values left out, and the next steps — the same for every plan.Fix, then deploy again
Your agent changes your code and deploys again, through the same check and health check.
Ask your agent to fix a failed deployment and it reads repairContext: the attempt that failed, what is live now, and what to do next. Tofu never writes to your code or your GitHub repository by itself.
Names in Tofu. Values write-only.
Names and scopes live in the dashboard; values go straight to the hosting provider. A secret is stored there write-only and never read back — not by the dashboard, not by Tofu, not by your agent.
A pasted .env file saves each value as a secret, except names that start with NEXT_PUBLIC_, VITE_ or PUBLIC_, which every visitor’s browser gets anyway, and APP_ADMIN_EMAILS: these are saved visible unless the name has SECRET, PASSWORD, PRIVATE_KEY or SERVICE_ROLE in it or the value looks like a password or a key. A variable that is a secret already stays one. VERCEL_* names are reserved, and the values Tofu writes for a managed database are managed and read-only. Saving a change does not redeploy; the next deployment picks it up.
Push, and it deploys. Through the same check.
Import a branch, confirm the framework, and turn on automatic updates. Each push deploys the branch’s latest commit through the same check and the same publication; if an update fails, your previous healthy version stays live.
Tofu reads the repository with a short-lived, read-only token and never writes to it. A manual upload pauses automatic updates instead of being overwritten, and your agent can turn them off; turning them on takes your own GitHub approval in the browser.
Request-driven web apps. In the stack you already chose.
Every one of these answers a request and scales to zero between requests. Every plan hosts your pages and the code behind them.
- Sites and web frameworks
- Next.js
- Vite
- Astro
- SvelteKit
- Nuxt
- React Router
- Gatsby
- Static HTML
Built by the provider from the framework’s own build — or, for a prebuilt static site, published as it is.
- Python
- FastAPI
- Flask
- Django
- Python
Built from the app’s own manifest and started as an HTTP process that answers the address.
- Go
- Go
Built from the app’s own go.mod and started as an HTTP process that reads PORT.
- JavaScript servers
- Express
- Hono
- NestJS
- Node.js server
One entrypoint file the provider finds by name, started as an HTTP process — the server answers /.
- Containers
- Dockerfile (container)
The image your own container file describes, built by the provider and run as a service.
By design.
Bigger finished sites need a paid plan. Free puts a site you send as finished pages online, up to 500 files and 50 MB.
Preview deployments. Each app’s updates follow one branch and one app root — no pull-request previews, no tags, and the latest head rather than every commit.
Runtime logs for container apps. Tofu cannot read a container app’s runtime log today; asked for one, it says so rather than showing an empty log.
Anything that has to stay running. A background worker, a queue consumer, an always-on scheduler or a non-HTTP service has no path through Tofu, and no plan changes that.
Your own cron schedule. An app’s own
vercel.jsoncrons do not register here; the schedule belongs to whatever calls the app.An uptime guarantee on any plan. Tofu works to keep your apps available, and an uptime commitment (an SLA) is available on request: tell us what you need.
Paste one message. Online in 10 minutes.
Your app, its database, your domain and your sign-in — from the agent you already use.