Cell Limitations

These are the current boundaries of what Cells can do. Most reflect deliberate design choices; some are areas of active development.

Storage and state

No persistent local filesystem. Cells are stateless. There is no writable disk — only the bindings declared in ribo.toml provide persistent storage. Use c3 for structured data and g7 for files and binary objects.

No shared memory. Cells are isolated from each other. Two Cells cannot share a variable, a cache, or any in-memory state. Communication must go through c3 or g7.

Networking

fetch() only. Cells can make outbound HTTP/HTTPS requests using the standard fetch() API. There is no access to raw TCP/UDP sockets, DNS resolution, or other network primitives.

No WebSockets. Neither inbound nor outbound WebSocket connections are currently supported. Long-lived connections must be modelled as a sequence of HTTP requests.

No inbound streaming. Request bodies are buffered before the Cell's fetch handler is called.

Compute

No in-request background tasks. A Cell's execution ends when the fetch handler returns its Response. There is no waitUntil — work that outlasts the response is not supported inside fetch. For periodic background work, use pulse to run a handler on a cron schedule instead.

No spawning processes or threads. Cells run in a single-threaded V8 context. You cannot spawn child processes or worker threads.

WASM Cells specifically

JSON serialization boundary. Request and response data crosses the JS/WASM boundary as JSON strings. This means binary request bodies are not supported for WASM Cells, and binary response bodies must be base64-encoded or represented as text.

No async Rust without wasm-bindgen. Standard Rust async runtimes (Tokio, async-std) do not work in WASM. Async from WASM requires wasm-bindgen futures, which adds complexity.

Code size