FlaryDocs0.3 RC
Browse documentation

Start

Cloudflare resources

Know which Cloudflare resources each Flary runtime feature needs.

The complete Flary runtime is Cloudflare-native today. A production deployment needs a Cloudflare account. The account can be yours or the host application’s account.

Resource matrix

Feature Worker Durable Objects D1 R2
Compile *.prompt.md No No No No
Local prompt Worker Local emulator No No No
Durable chat or support thread Yes Yes Yes No
Coding agent with small files Yes Yes Yes No
Files larger than 1,500,000 bytes Yes Yes Yes Yes
R2 history fallback Yes Yes Yes Yes

Cloudflare Sandbox, Dynamic Workers, and Artifacts are optional integrations. They are not required for a basic durable agent.

What each resource stores

Durable Object

Flue owns the canonical thread transcript and execution stream in the thread Durable Object. A Durable Object is the coordination unit for one thread.

D1

D1FlaryRunRepository stores:

  • Trusted run and tenant bindings.
  • Flue admission receipts.
  • Normalized event projections for replay.
  • Materialized run results.
  • Idempotency keys.

D1 does not copy Flue’s canonical transcript.

Apply FLARY_RUNS_D1_MIGRATION through your application’s migration process.

R2

The workspace runtime keeps files up to 1,500,000 bytes in workspace SQLite. Larger files go to R2. R2 can also store immutable history when the Cloudflare Artifacts binding is not available.

Use one private bucket for each environment. Flary derives tenant-scoped object keys, but the host must still authorize every read, write, delete, and signed transfer request.

Local development

Wrangler can emulate a Worker, Durable Objects, and D1 on the local computer. You can build and test before you create production resources. R2 behavior can also be tested locally, but production large-file storage still needs a real R2 binding.

Deployment outline

  1. Sign in with wrangler login.
  2. Create the D1 database.
  3. Add the Flue Durable Object bindings generated by the pinned Flue build.
  4. Add an R2 binding only when the selected features need it.
  5. Apply the Flary D1 migration.
  6. Store provider keys or OAuth credentials as encrypted host data.
  7. Deploy the Worker.

Flary does not force Better Auth, Clerk, Auth0, or another identity system. The host authenticates the request and returns a trusted TrustedRunContext.