One line of code, one fresh VM:

echo 'print(6*7)' | kedge eval python3

kedge eval <runtime> runs stdin in a fresh VM, streams stdout and stderr, and exits with the code's status. The VM is then destroyed; nothing is deployed or persisted.

Each run has the same hardware isolation as an app instance. See instant sandboxes & scale-out for restore latency.

runtimes

Every image includes the handler runtime tools: sqlite3, jq, curl, and uptime. Each run defaults to 256 MiB and 30 seconds; both limits are configurable per call.

network access

Evals and sandboxes have outbound network access by default. To run untrusted code with no network at all, pass -no-network to kedge eval or kedge sandbox; the VM then has only a loopback interface. Anonymous runs, including the front-page console, are always networkless regardless of what the request asks for.

interactive sandboxes

kedge sandbox python3 drops you into a shell inside a fresh sandbox VM, and kedge shell - does the same without naming a runtime. Either VM is destroyed when you exit. The REST sandbox operation has the same one-shot boundary: submit a runtime and command, receive the command result, and leave no execution resource or identifier behind.

There is no persistent sandbox resource. When files or processes must outlive the session, create a normal workspace app with a persistent volume; give the app an expiry if it should clean itself up later. It then uses the same shell, logs, metrics, migration, and deletion behavior as every other stateful app.

GitHub Actions runners apply the same one-run boundary to CI jobs.