Serverless sandboxes

Archil’s serverless sandboxes are a new kind of sandbox for running untrusted code which supports running bash, Python, and Node.js without needing to manage the lifecycle of a separate sandbox instance. Serverless sandboxes are built on full-featured Linux microVMs that are colocated with your data for maximum security and performance. Each Archil disk can support running commands concurrently across mutliple serverless sandboxes, 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.

import * as archil from "disk";

const { disk } = await archil.createDisk({ name: "agent-workspace" });
const { stdout } = await disk.exec("git clone --depth 1 https://github.com/pallets/flask.git");

import archil
from archil import S3Mount

result = archil.create_disk(name="agent-workspace")
res = result.disk.exec("git clone --depth 1 https://github.com/pallets/flask.git")

npx disk dsk-abc123 exec "git clone --depth 1 https://github.com/pallets/flask.git"

Companies are using Archil’s serverless sandboxes 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 sandbox 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 serverless sandbox 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 serverless sandbox

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 on a serverless sandbox, 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.

import * as archil from "disk";

const { stdout } = await archil.exec({
  disks: {
    data: "dsk-abc123",
    logs: "dsk-def456",
  },
  command: "wc -l /mnt/archil/data/*.csv > /mnt/archil/logs/lines.txt",
});

import archil

res = archil.exec(
    disks={
        "data": "dsk-abc123",
        "logs": "dsk-def456",
    },
    command="wc -l /mnt/archil/data/*.csv > /mnt/archil/logs/lines.txt",
)

Specifying disk options

You may want to run a serverless sandbox in which some disks have reduced permissions, so the code running cannot modify them. Serverless sandboxes support 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.

import * as archil from "disk";

const { stdout } = await archil.exec({
  disks: {
    data: "dsk-abc123",
    logs: {
      disk: "dsk-def456",
      subdirectory: "app/logs",
      readOnly: true,
    },
  },
  command: "wc -l /mnt/archil/logs/*.log",
});

import archil
from archil import ExecMountSpec

res = archil.exec(
    disks={
        "data": "dsk-abc123",
        "logs": ExecMountSpec("dsk-def456", subdirectory="app/logs", read_only=True),
    },
    command="wc -l /mnt/archil/logs/*.log",
)

Consistency with other clients

Serverless sandboxes work like other Archil clients, and they have the same read-after-write consistency model. A file written to the disk via a serverless sandbox is immediately visible to the next serverless sandbox command that reads it. By default, disks in serverless sandboxes 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 serverless sandbox 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 serverless sandbox commands in parallel, contact us to have your limits raised to thousands.

Getting started

Compute

Concepts

Data Sources

Details

Administration

Protocols

Reference

Legal

Serverless sandboxes

Working directory and environment

Composing multiple disks into a serverless sandbox

Specifying disk options

Consistency with other clients

Limits

Next steps

​Working directory and environment

​Composing multiple disks into a serverless sandbox

​Specifying disk options

​Consistency with other clients

​Limits

​Next steps

Working directory and environment

Composing multiple disks into a serverless sandbox

Specifying disk options

Consistency with other clients

Limits

Next steps