Tissue runs on Tissue.
We recently moved tissue.systems itself — the landing page, auth, dashboard, docs, and support — to run as Cells on Tissue. The platform now hosts its own front door.
This is the kind of milestone that either feels trivial ("of course it should run on itself") or reveals something important about where the platform actually is. For us it felt like the second one.
| Domain | What it does |
|---|---|
| tissue.systems | Landing page — static files served by a Files Cell |
| auth.tissue.systems | OAuth login, token issuance, /api/me — a JS Cell backed by c3 SQLite |
| dashboard.tissue.systems | Developer dashboard — JS Cell, reads the management API |
| docs.tissue.systems | Documentation — static files Cell |
| support.tissue.systems | Support — JS Cell |
Each of these is deployed with a standard ribo deploy from a ribo.toml, the same as any user Cell. The custom domains point at the same routing layer as every other Cell, with TLS provisioned automatically.
The management API at api.tissue.systems is not a Cell. It is the process that deploys Cells — it cannot coherently run inside itself. It runs as a bare system process and is the only part of the platform that cannot eat its own cooking. Everything above that layer can.
Moving to this setup raised an immediate question: auth.tissue.systems issues the JWT tokens that ribo login stores locally. Those tokens are required to deploy Cells. So the auth Cell must be running before you can deploy anything — including the auth Cell itself.
In practice the sequence is: stand up the management API first (bare metal), deploy auth with a temporary credential, then use the issued token to deploy everything else. The substrate has to exist before the things that run on it. This is not a deep paradox — it is just the order of operations — but it clarifies what "the substrate" actually is. The management API is the bedrock. Everything else, including our own product's front door, is a Cell.
Running on your own platform is the most honest test of it. The things we noticed immediately: cold-start latency matters when it is your own login page. c3 SQLite needs to be reliable when it is storing your own user sessions. Custom domain TLS provisioning needs to be invisible when it is your own domain at stake.
None of those turned out to be problems. That is the point of writing this down.
If you want to deploy a function and get a live URL, with SQL and storage and scheduling included, on infrastructure you control — sign up and run ribo deploy.