# Ferrite

Ferrite is a self-contained application platform for durable state, background work, isolated compute, governed networking, deployment, and operations.

Ferrite gives an application six composable primitives behind one SDK: a
key-value store, ordered streams, queues, multi-key transactions, object
storage, and isolated functions. A gateway, capability system, deployment
pipeline, and dashboard turn those primitives into a complete place to build
and run an application.

## What you can build

Use Ferrite for request-driven web applications, APIs, background workers,
durable workflows, event streams, agent backends, MCP servers, and applications
that need strong state guarantees without a separate database, queue, object
store, or scheduler.

Every deployable app is one Rust crate with `ferrite-app` as its only runtime
dependency. Its `ferrite.json` file names every resource and network route the
app may use. The platform injects only those handles at runtime.

## Six primitives, one application contract

| Developer need | Ferrite primitive | What it provides |
| --- | --- | --- |
| Small durable records | [Key-value Store](/developers/store/) | Linearizable reads and writes, CAS, ADD, TTL, scans |
| Ordered events | [Streams](/developers/streams/) | Dense offsets, retention, replay, durable consumers |
| Background work | [Queues](/developers/queues/) | Leases, retries, delayed delivery, dead letters |
| Atomic changes | [Transactions](/developers/transactions/) | One commit decision across up to 64 keys |
| Files and large values | [Object Storage](/developers/object-storage/) | Content-addressed blobs and verified reads |
| Application code | [Functions](/developers/functions/) | Isolated Rust processes with bounded resources |

The same replication, identity, audit, backup, and upgrade model sits under the
durable primitives. You do not assemble independent services with unrelated
failure and permission models.

## A request through Ferrite

```mermaid
flowchart LR
  client["Browser or agent"] --> gateway["Gateway"]
  gateway --> fn["Function"]
  fn --> store["Store"]
  fn --> queue["Queue"]
  fn --> stream["Stream"]
  fn --> blob["Object storage"]
  deploy["Source deploy"] -. capabilities .-> fn
```

The Gateway terminates public traffic and forwards a typed request to your
function. Your code reads injected handles from `AppContext`; it has no ambient
database credentials or arbitrary socket access. Outbound HTTP goes through a
declared, audited egress policy.

## Start locally

```bash
ferrite new webapp hello-ferrite --with-tests
cd hello-ferrite
ferrite dev
```

The local loop runs the real plane semantics, prints a clickable URL, preserves
state across rebuilds, recompiles Rust when source changes, and refreshes the
browser when content changes. Continue with the [Quickstart](/developers/quickstart/)
or learn the complete [Ferrite CLI](/developers/cli/) workflow.

## Security and scale

Ferrite evaluates an app before it runs, scopes authority to named bindings,
isolates each app process, and fails closed when a required capability is
missing. Gateways are stateless and scale horizontally. Durable services use
fenced replication and verified rejoin; workers use leases and idempotency so a
crash can redeliver work without losing it.

Security is shared, but authorization remains yours. Authentication can
establish a subject and assurance; your app still decides who may view an
order, administer a booking calendar, or deploy a release.

## Next steps

- [Create and run your first app](/developers/quickstart/).
- [Install the Agent Plugin](/developers/plugin/) for CLI and MCP access.
- [See complete apps](/developers/apps/) for commerce, scheduling, support, and compliance patterns.