Skip to main content
Cloudflare Workers run at the edge with no persistent filesystem. Archil gives your Workers read/write access to S3-backed storage with the disk SDK — a pure-JavaScript control-plane client with no native dependencies, which works inside the Workers runtime. The pattern: a Worker dispatches work to disk.exec, which runs the command in a container with the filesystem mounted. The Worker stays small and stateless; the heavy lifting happens server-side, against the disk.

Install the SDK

Worker example

This Worker accepts a query parameter, runs a parallel search against an Archil disk via disk.grep, and returns the matching lines:

Configuration

Set your Archil API key as a Worker secret:
In your wrangler.toml, enable the Node.js compatibility flag (the SDK depends on standard Node APIs but no native modules):

Archil with R2

If you’re already using Cloudflare R2 for object storage, you can use R2 as Archil’s data source. Archil keeps a managed cache in front of R2, so reads from your Workers go to fast cached storage instead of round-tripping to R2 on every request — and you get filesystem semantics on top of the bucket. Create a disk backed by your R2 bucket and your Workers can exec against it.

Performance tips

  • Pick the right Archil region. disk.exec runs in the Archil region, not at the edge — select a region close to where the bulk of your traffic originates, or where your data already lives.
  • Push work into exec or grep, not into the Worker. Workers have CPU-time limits; the serverless runtime doesn’t. If a request requires scanning many files, run it through disk.grep (for search) or disk.exec (for arbitrary commands) to keep the Worker fast and avoid streaming gigabytes through the edge.
  • Reuse getDisk() across requests in long-lived isolates by caching the returned Disk at module scope.