Skip to main content
Archil’s serverless execution makes it simple to run untrusted code like bash, Python, and Node.js directly on the data in your Archil file system without needing to manage the lifecycle of a separate sandbox instance. Serverless execution is built on full-featured Linux microVMs that are colocated with your data for maximum security and performance. Each Archil disk can run many commands concurrently, and because they’re fully elastic, you only pay for the time that your code is actually running. This makes them ideal for tasks such as the bash tool in an AI agent loop. If you instead need a sandbox that stays alive in-between calls for the purpose of running commands with long startup times or network services, you can use an Archil Persistent Sandbox.
Companies are using Archil’s serverless execution for:
  • Running untrusted AI-generated code on a machine that is close to the context that the AI is attempting to work on, without risking that code breaking the origin server.
  • Running map-reduce style jobs across large data sets for data analysis tasks such as full-text search or aggregation.
  • Using your disk from a different region in order to avoid excessive network latency between your application code and the disk, and avoid egress fees.
Archil disks include 1,000 minutes of free serverless execution usage per month, for each terabyte of active data on the disk. Each invocation is billed with a 100ms minimum runtime.

Working directory and environment

Each command starts with the working directory set to where your Archil disk is mounted (/mnt/archil). The runtime image includes most common Unix tools, but you can install additional tools into the environment by directing the binaries to your disk.

Composing multiple disks into a single command

Often, users need to run commands on multiple disks at once. For example, if you’re building an AI agent which has access to a read-only customer-specific disk and a read-write session-specific disk, and you want your agent to use documents on both disks. To run a command against several disks, you instead pass a map of disks into archil.exec. Each disk is automatically mounted to the /mnt/archil/<key> path inside the sandbox. For example, in the code below, the data disk is mounted to /mnt/archil/data and the logs disk is mounted to /mnt/archil/logs.

Specifying disk options

You may want to run a command in which some disks have reduced permissions, so the code running cannot modify them. Serverless execution supports specifying whether or not a disk should be marked as read-only or whether it should be limited to a subdirectory of the disk. For example, in the code below, the logs disk will be mounted to /mnt/archil/logs. That directory will be read-only, and code in the sandbox cannnot modify it. It will only display the contents of the app/logs subdirectory of the disk.

Consistency with other clients

Serverless execution works like other Archil clients, with the same read-after-write consistency model. A file written to the disk by one command is immediately visible to the next command that reads it. By default, disks are mounted in shared mode, which means that you’ll need to take care to call archil checkout before mutating files on the disk. For more details on how to checkout or checkin files in shared mode, see Sharing disks.

Limits

  • Each command will timeout after 5 minutes of runtime, but the sandbox itself will continue running to completion.
  • Stdout and stderr are limited to the trailing 128 KiB of output in the response. If you need to store larger output, we recommend storing the data on the disk and then using the getObject API to retrieve it.
  • Users can execute hundreds of commands in parallel, contact us to have your limits raised to thousands.

Next steps