Cloudflare Workers run at the edge with no persistent filesystem. Archil gives your Workers read/write access to S3-backed storage with theDocumentation Index
Fetch the complete documentation index at: https://docs.archil.com/llms.txt
Use this file to discover all available pages before exploring further.
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, runsgrep against an Archil disk via disk.exec, and
returns the result:
Configuration
Set your Archil API key as a Worker secret: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 canexec against it.
Performance tips
- Pick the right Archil region.
disk.execruns in the Archil region, not at the edge — choose a region close to where the bulk of your traffic originates, or where your data already lives. - Push work into
exec, not into the Worker. Workers have CPU-time limits; serverlessexecdoesn’t. If a request requires scanning many files, doing it throughexeckeeps the Worker fast and avoids streaming gigabytes through the edge. - Reuse
getDisk()across requests in long-lived isolates by caching the returnedDiskat module scope.