Skip to main content

Architecture

Learn about Fireproof's architecture and design principles.

📄️ Core

The initial developer experience of using Fireproof is as a local ledger with a database API, reading and writing documents and querying in support of user interaction. Fireproof is powerful immediately upon npm install or by direct import, so developers can write complete apps before they think of connecting to the cloud. The core is a lightweight functional TypeScript program, which reads and writes via pluggable gateways. The default configuration is web-friendly, but the modular architecture means Fireproof also runs great in data centers or embedded device swarms.

📄️ Runtime

The Fireproof runtime defaults to in-browser operation, letting developers begin with an empty ledger that requires no external services and sync when ready. On launch, the runtime checks for both local and (if connected) remote metadata. When a remote ledger is discovered, it merges updates into a consistent snapshot and then subscribes to live updates. This process optimizes cold starts through sync hints and working set priority, reducing the time to first interaction. Users expect consistency during normal page refreshes, so Fireproof writes locally and uses the browser cache or other platform features to speed up load times. In both cases, all data is written as immutable encrypted objects, with configurable key management.

📄️ Sync

Fireproof supports configurable syncing to remote storage through pluggable gateways, allowing users to replicate ledger updates wherever needed. By default, developers can invoke the connect() function to link with Fireproof Cloud, which uses Cloudflare for data hosting and Supabase for metadata handling. This seamless default works for most projects, particularly when developers want a quick and secure way to share data between clients. For more advanced setups, the same gateway model supports custom remote backends—such as a dedicated server running on AWS or a memory-only function in a serverless environment.

📄️ Storage

Fireproof stores each data file as an encrypted container that begins with a pointer to the root blocks of the Merkle CRDT. These pointers reference the entire ledger history, allowing each file to include the complete set of content-addressed blocks that define its state. Because every block is immutable and linked by quantum-resistant hash references, the entire structure is self-verifying. When a data file is loaded, it is first decrypted, then an in-memory index of the contained blocks is built. Any subsequent block access involves verifying the block’s hash to ensure integrity, whether reads come from a file, a remote gateway, or memory.

📄️ Tooling

Fireproof's tooling ecosystem supports developers from initial prototyping through to production on the server or edge, with specialized features for AI agent observability and interaction logging. The system can be installed directly via ESM imports for rapid prototyping, or through npm for traditional build processes. This flexibility allows developers to start building immediately in any JavaScript environment, with validated deployment targets including Cloudflare Durable Objects, Deno, Netlify, and AWS Lambda, with additional cloud marketplace integrations on the roadmap.

📄️ AI Agents

As agent workloads become more complex, coordinating and verifying LLM interactions becomes increasingly critical. Traditional approaches lack provable guarantees about agent behaviors, making it difficult to audit decision chains or ensure consistent operation across distributed deployments. Fireproof's architecture addresses these challenges by providing a foundation for provable AI agent collaboration that extends classical state machine patterns with cryptographic verification and causal consistency.