# Limits

Design within Ferrite's manifest, ingress, compute, and application-source bounds.

Ferrite validates hard bounds before an application runs. `ferrite validate`
checks the manifest, and `ferrite check` adds source admission and compilation.

## Manifest bounds

| Setting | Accepted value |
| --- | --- |
| `compute.memory_mb` | Omit it or set at least 16 MiB. |
| `compute.cpu_percent` | Omit it or set at least 1. A value of 100 represents one core. |
| API `rate_limit_per_min` | `1` through `1,000,000`. |
| App instances in local development | `1` through `32`. |
| Chaos interval in local development | `0` through `3,600` seconds. |

Account and fleet policy may set a lower deployable ceiling than the manifest
syntax accepts. A rejected deployment returns the authoritative limit instead
of silently reducing the request.

## Source and authority

A deployable app may depend on `ferrite-app` only. Add reusable features with
Ferrite source packages. The admission gate rejects filesystem, process,
listener, ambient network, and undeclared credential access.

Every service, route, forwarded request header, outbound destination, and
secret must be declared. The absence of a declaration means the app cannot use
that authority.

## Request and work bounds

Keep request bodies, queue messages, log records, notification bodies, and MCP
results bounded. Queue workers must expect redelivery until an acknowledgement
is durable. API handlers must reply within the route timeout; move longer work
to a Queue and return an operation identifier.

Use [Object Storage](/developers/object-storage/) for large content,
[Queues](/developers/queues/) for long work, and [Reliability](/developers/reliability/)
for timeout and retry design.