Ferrite Docs

Limits

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

View as Markdown

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

Manifest bounds

SettingAccepted value
compute.memory_mbOmit it or set at least 16 MiB.
compute.cpu_percentOmit it or set at least 1. A value of 100 represents one core.
API rate_limit_per_min1 through 1,000,000.
App instances in local development1 through 32.
Chaos interval in local development0 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 for large content, Queues for long work, and Reliability for timeout and retry design.