What is Tissue?

Tissue is a serverless compute platform. You write functions, deploy them with a single command, and they run on a live URL: no servers to configure, no runtime to install, no infrastructure to operate.

The biological metaphor

The platform is named after biological tissue, the organizational layer between individual cells and whole organisms. In biology, tissue is what emerges when specialized cells work in coordination: each cell isolated, self-contained, doing exactly one thing well; the tissue as a whole far more capable than any individual cell.

tissue.systems extends this metaphor across the entire stack:

Cells

A Cell is the basic unit of computation. Each Cell is an isolated JavaScript or WebAssembly module that handles HTTP requests. Cells are stateless: they receive a request, produce a response, and terminate. No shared memory, no persistent local state, no side effects beyond their declared bindings.

Just as biological cells maintain their internal chemistry through a membrane boundary, Cells on tissue.systems are isolated by default. They can only reach the outside world through explicit, declared channels: outbound fetch(), a c3 database binding, or a g7 storage binding.

gate: Who may enter

By default a Cell's URL is open to anyone who has it. A gate is an access policy in front of that URL, enforced at the edge before your code runs: capability links, your own Tissue account, listed email addresses, an email domain, or an identity provider you connect over OIDC. A request that fails the policy never reaches the Cell, and the Cell needs no code to enforce any of it.

A membrane is selectively permeable; gated channels are what decide who crosses it.

c3: Structured data

c3 is the platform's structured data service, backed by SQLite. The name echoes biochemistry: C3 in biology refers to three-carbon molecules, the fundamental currency of cellular chemistry. In tissue.systems, c3 is the fundamental currency of structured information: relational, persistent, queryable.

c3 exposes a clean, familiar API. If you've used a SQL database in a serverless environment before, c3 will feel immediately familiar.

g7: Object storage

g7 is the platform's object storage service. The name is a numeronym: g + 7 (the seven letters of lycogen) + n = glycogen. The same convention behind i18n and k8s applied to a biological molecule.

In biology, glycogen is how living systems store dense, stable reserves of glucose: compact, inert, available on demand when a cell needs energy or raw material. In tissue.systems, g7 is how your Cells store dense, stable reserves of data: images, documents, compiled assets, arbitrary binary objects.

pulse: Scheduled invocations

pulse is how Cells run on a schedule. A Cell can declare one or more cron expressions in ribo.toml; the platform fires a pulse event at each scheduled time, calling the Cell's pulse(event, env) handler. No incoming HTTP request is needed.

The name echoes the biological metaphor: a pulse is the periodic signal that keeps a system alive between external stimuli.

vesicle: Webhook inbox

vesicle is the platform's webhook inbox. Creating an endpoint gives you a URL that accepts HTTP deliveries and stores every one of them under your account — before any Cell exists to handle them. Bind the endpoint to a Cell and a route and captures start dispatching; until then they wait, readable in the dashboard or with ribo vesicle tail.

In biology, a vesicle is the membrane-bound package a cell uses to hold ingested material until it is processed. The delivery is held intact until something is ready to read it.

synapse: Sensor ingest

synapse is how a physical device reaches a Cell. The device publishes over MQTT-over-TLS to ingest.tissue.dev:8883; synapse authenticates it, enforces per-device topic isolation and rate limits, and dispatches each reading into the owning Cell's sensor(event, env) handler. Synapse stores no readings — the Cell owns storage, usually c3.

A synapse is the junction that carries a signal from one cell to the next; here it carries a reading from the device into your Cell.

ribo: The CLI

ribo is the command-line tool that deploys Cells and manages platform resources. The name comes from the ribosome, the molecular machine inside every living cell that reads genetic instructions and assembles proteins from them. In the same way, ribo reads your ribo.toml and assembles a running Cell from your code.

Platform components

How a request flows

1. A request arrives at https://<cell-name>.<account-subdomain>.tissue.dev
2. The platform routes it to the correct Cell based on the hostname
3. If the Cell has a gate, the edge checks the visitor against the policy and answers the request itself if it fails
4. The Cell's fetch(request, env) handler is called in an isolated V8 instance
5. The Cell reads from env.DB (c3) or env.BUCKET (g7) if it has those bindings
6. The Cell returns a Response

The Cell's isolate is reused across requests for warm performance. Redeploying the Cell immediately routes new requests to a fresh isolate.

What invokes a Cell

An HTTP request is the common case, but not the only one. Each trigger arrives at a named export:

Pulse and synapse dispatch is best-effort and not retried. Vesicle deliveries are stored first and retried, so a handler that is down does not lose them.

Next steps

• Quick Start: deploy your first Cell in under five minutes
• Cells: what Cells are and how to write them
• Access Control: put a policy in front of a Cell's URL
• c3: persistent SQLite databases
• g7: object storage
• Pulse: run a Cell on a cron schedule
• Vesicle: webhook endpoints that capture every delivery
• Synapse: sensor and IoT ingest over MQTT