Tissue vs Render
Render gives you a machine running your container. Tissue gives you no machine at all. Which is better depends entirely on what you wrote.
If you have a Rails app, a Go binary, a Python worker, or anything that wants a process, a disk and a connection it can hold open, Render will run it and tissue will not. That is the end of the comparison.
If what you have is a site and some JavaScript behind it, the trade is this. Render's free web service stops after 15 minutes without traffic and takes about a minute to come back; its free Postgres expires 30 days after you create it; its free key-value store loses everything when the instance restarts. Tissue has nothing to keep warm, nothing that expires, and no instance to size.
What each one is
Two sentences each, before any numbers.
- Render
- A place to run containers. You point it at a repository, it builds an image and runs it as a web service, a background worker, a cron job or a static site, with managed Postgres and a key-value store alongside. You choose an instance size and pay for it by the month.
- Tissue
- One Cell — a JavaScript or WebAssembly function answering on a URL — with a SQL database, object storage, scheduled runs, sign-in and secrets attached to it by name in
ribo.toml.ribo deployputs the code, the static files and every attachment live in one step.
Side by side
Every figure below came off the other company’s own pages, on one day, and is dated underneath.
| Render | Tissue | |
|---|---|---|
| Free allowance | 750 free instance hours per workspace per calendar month. | 2,000,000 CPU-milliseconds a month, on 5 Cells, with no card. |
| Idle behaviour | A free web service spins down after 15 minutes with no inbound traffic, and takes roughly a minute to come back, showing a loading page while it does. | Nothing spins down, because nothing is up. A Cell that has not run in a month answers the next request. |
| Free database | 1 GB of fixed storage, and the instance expires 30 days after it is created, with a 14-day grace period. | c3, 1 GiB on the free plan, and it does not expire. |
| Free key-value store | One per workspace, and all of its data is lost whenever the instance restarts. | There is no key-value store. c3 is the durable one, and it is durable. |
| Scheduled jobs | Cron jobs are not one of the free service types. | pulse, 3 schedules on the free plan, down to one minute. |
| What you pay for | The instance, by the month, whether or not a request arrives. | CPU-milliseconds actually spent, and gigabytes actually stored. |
| What runs | Any container: any language, any runtime, processes that stay up, connections that stay open. | JavaScript or WebAssembly in a V8 isolate. No processes, no threads, no long-lived connections. |
| Disk | Persistent disks you attach to a service. | No writable disk. c3 for structured data, g7 for files. |
| Static files | A separate free service type, deployed on its own. | Everything under public/ is served at the root of the same deploy. |
Checked 16 September 2026 against Render's own free-tier documentation. Their paid instance prices are not printed here: the two documentation pages we tried both answered 404 on the day we looked, and a price we could not read on their own site is not a price we will quote. Both of us move; if a figure here has gone stale, tell us and we will correct it.
Where Render is the better choice
This section is not decorative.
It runs your container, which is not a small thing: any language, any framework, any binary, a process that stays up, a socket that stays open, a disk you can write to. Tissue has none of that and is not going to.
Postgres you connect to with psql, private networking between services, and background workers as a first-class service type rather than a pattern you improvise.
If the application was written for a server, moving it to Render is a Dockerfile. Moving it here is a rewrite.
And 750 instance hours is a real month of a real machine, which is a better deal than a CPU allowance for anything that works steadily — as long as you can live with the spin-down.
Where tissue is the better choice
Nothing to keep warm. There is no idle timeout because there is nothing idling: a Cell starts when a request arrives and stops when it has answered.
Nothing expires. The free database is not on a 30-day clock, and the free plan is not a trial with a different name.
No instance to size. You are not choosing between too small and too expensive before you know what the traffic looks like.
The database and the file storage are attachments on the same deploy, not separate services with their own lifecycles and their own free-tier rules.
What moving looks like
The web service becomes a Cell and the managed database becomes a binding. The static assets that were their own service move under public/ in the same deploy.
[cell] name = "web" js = "./cell.js" [[bindings]] type = "files" binding = "FILES" dir = "public" [[bindings]] type = "c3" binding = "DB" database = "web"
$ ribo deploy uploading cell.js publishing ./public attaching c3 live https://web.quartz-4b.tissue.dev
The database and the bucket are created on that first deploy if they are not there yet. ribo deploy is the whole pipeline: there is no build step to configure and no second place to put the static files.
Spore is $0, takes no card, and allows commercial use. If tissue turns out to be the wrong shape for what you are building, you will know inside an afternoon.