Sandboxes that hold their shape — and bend when you need them to.
FireCase is an execution platform for code you don't fully trust and state you don't want to lose. We started it because every sandbox we tried forced the same tradeoff: you could have persistence, or you could have flexibility, never both at the level a serious AI workload actually needs.
Persistence is real
Every instance is born with a real v1 manifest — not a promise to materialize one later.
Forking is cheap
Content-addressed storage. A hundred sandboxes from one checkpoint deduplicate to one set of bytes on disk.
Boot is fast
We own the microVM stack end-to-end. Cold start measured in milliseconds, not seconds.
The middle ground nobody else is building
Most sandbox providers cover the core surface — boot a VM, run code, tear it down. That part is table stakes. What none of them do well is the part in between: treating filesystem state as a first-class object that you can fork, branch, snapshot, and recombine the way you already do with git.
On FireCase, a single checkpoint can fan out into a hundred live sandboxes in parallel. As an agent works across them, you can keep the subset of filesystems that produced useful results, discard the rest, and re-fork from any branch on the tree. The choice between “ephemeral and fast” and “persistent and slow” goes away — you get both, on the same primitive, controlled per operation rather than per environment.
That single design decision is what the rest of the platform is organized around. Forking is cheap because the storage layer is content-addressed. Boot is fast because we own the microVM stack end-to-end. Persistence is honest because every instance is born with a real manifest, not a promise to materialize one later.
Built for the RLVR era
The frontier of post-training is moving fast toward reinforcement learning with verifiable rewards. Instead of training models on human preference labels, labs are training on signals that come from actually executing the model's output — running the code it wrote, checking whether the tests pass, whether the proof type-checks, whether the agent completed the task. The reward function is a sandbox.
That workload looks nothing like a traditional serverless function. It is millions of short-lived, untrusted, parallel rollouts per training run, each one needing a realistic environment and a way to capture the resulting state for grading. FireCase is built from the ground up for this shape of work: hardware-isolated microVMs for the untrusted-code problem, cheap forking from a base image for the parallelism problem, and a manifest model that lets you preserve or discard each rollout's filesystem on demand. The whole platform is designed to be customizable per lab — base images, network policy, tool surface, reward hooks — rather than a fixed product surface you have to bend your training loop around.
GPU support is on the roadmap
Today FireCase is a CPU platform. Our roadmap is to bring the same primitive — fast, isolated, forkable environments — to GPU instances, so the same sandbox that grades a rollout can also be the one that trains and fine-tunes on it. The goal is end-to-end: data generation, rollout execution, reward computation, and gradient updates running on a single substrate, with the same fork-and-checkpoint semantics across the whole loop. We're building toward a platform where a lab can stand up a complete RLVR pipeline without stitching three vendors together.