Company
Shipping is still the hard part.
Tofu is the ship-it layer for vibe-coded apps: your agent wrote it, Tofu ships it. This page is why we build it, what it does today in alpha, and what it cannot do yet.
Writing the app got fast. Shipping it did not.
An afternoon with a coding agent now ends with something that runs: a working page, a small app, one database table. The stretch after that has not moved. Deploying it, pointing a domain at it, setting environment variables, arranging a certificate, checking that it is really up — that is a pile of accounts and dashboards, none of it the thing anyone set out to build.
It also breaks in the least useful place. A build that works on a laptop fails on the platform. A key exists on one machine and not in the build. The site loads and does the wrong thing, and there is no log to read. Then the app is live, and nobody is on call for it.
We are not trying to write more code for you — there are enough tools that do that. Tofu exists to close that last stretch: so the app your agent wrote actually goes live, and so what goes live can be trusted. That means saying what was checked, what changed, what is broken, and how to get back to a version that worked.
What we believe.
Three things we would rather build slowly than fake.
Built for agents first
A delivery layer should treat a coding agent as a real user, not as something added after an API was designed for people. Tofu's local MCP bridge reaches the same projects, deployments, logs and checks the dashboard does, and the human approves the connection in the browser.
Honest state before a pretty dashboard
A read Tofu cannot make is reported as unavailable, never as a zero, and a number from a partial read is named as partial. A failed build is reported as failed, and a surface that is not built yet says so instead of showing a plausible mock. If we cannot measure it, we do not draw a chart of it without saying so.
Yours to leave with
Your code stays yours, and the export is a real one: the source archive Tofu stores, your environment variable names and a documented hand-off for the database. A domain you connected can point somewhere else. Moving a running app and its database is still a coordinated, manual step rather than a button, and we would rather say that than imply one exists.
What Tofu is today.
One path from code to a running app, and it is the path we use ourselves.
Tofu is in alpha. Paid plans are rolling out to invited users, there is no uptime guarantee, and every plan has limits the service enforces. What works today, in the order you meet it:
- Bring your code. Upload a folder or a ZIP, import a GitHub repository, or let your coding agent do it through the Tofu MCP bridge.
- Check before it ships. A deterministic scan reads the source for committed secrets and dangerous patterns, explains each finding in plain English and hands you a paste-ready fix. Blocking findings have to be resolved before the deploy runs.
- Host and publish. Tofu builds the app, deploys it into hosting it manages and serves it at
<app>.trytofu.app. Build and runtime logs, deployment history, rollback and a repair hand-off for your agent live next to it in the same dashboard. - Settings and data. Environment variables (names and scopes in Tofu; secret values are write-only at the hosting provider and never stored by us), a domain you already own, and one managed database for a paid app. The database is still in testing, arrives empty, and Tofu does not run migrations against it.
- Traffic. First-party analytics for the site Tofu hosts for you: no cookie, no third-party script, and the numbers are yours.
- Your agent. A local MCP bridge, approved in the browser and revocable from the dashboard, that reaches the same projects and deployments as the console.
Not built yet, and not implied here: sign-in, email and payments inside your app — the dashboard labels them Coming next — an in-browser preview, and a one-click move of a live app and its database. Tofu does not buy, renew or transfer domains, and writes no DNS records for you.
Alpha, plainly: features can change, limits are real, and a build or a provider can fail. Keep your own copy of anything you cannot afford to lose.
The features page takes the same list apart, with the details and the limits. The documentation walks the flow end to end, including the parts that are missing.