Skip to main content
A runtime is Gravix Layer’s secure sandbox — an isolated microVM with code execution, terminal, filesystem, and SSH. Ready in ~50ms. In the API and SDK the resource is called runtime. It is the sandbox your app or agent uses to run untrusted or LLM-generated code.

​
Quick start

​
What you can do

Run code

Python and JavaScript inside the sandbox

Shell commands

Install packages, run scripts, inspect the OS

Files and Git

Read, write, upload, clone, and commit

Identity Providers

Attach secrets from Identity providers as env vars

Web Services

HTTPS URLs for HTTP apps inside a runtime

Network Policies

Control which outbound destinations a sandbox can reach

​
Templates

System base templates (Ubuntu 24.04, Python 3.14.6 via uv, Node 24). See Templates for the full toolchain list and custom builds.

​
Multi-Cloud Support

​
Security best practices

Runtimes isolate guest code from your host and other tenants. They do not stop a compromised or prompt-injected agent from misusing whatever it can reach inside the sandbox — files, shell, network, and any credentials present there.
Treat sandbox isolation as a containment boundary, not a trust boundary for agent inputs. Anything the agent can read or call inside the runtime is also available to an attacker who influences that agent.

​
Credentials and the sandbox

Avoid placing long-lived API keys, tokens, or database passwords into the sandbox whenever you can. Env vars, mounted files, and Identity provider injection all make secrets readable to code that runs inside the microVM — including code steered by a malicious prompt. Prefer architectures where authentication stays outside the sandbox:
  • Host-side tools — your application holds credentials and exposes narrow tools (for example “fetch models” or “create issue”). The agent invokes the tool by name and never sees the secret.
  • Scoped, short-lived credentials — if something must enter the sandbox, use the least privilege and shortest lifetime you can, then revoke or rotate promptly.
If you do inject secrets (including via Identity providers), reduce blast radius: require human approval for sensitive tool use, constrain outbound traffic with Network Policies, and watch for unexpected egress. These controls help; they do not eliminate context-injection risk.

​
General hardening

  • Review sandbox outputs before your product acts on them (commands, URLs, file paths, tool arguments).
  • Disable or tightly restrict network when the workload does not need it — see Network Policies.
  • Redact sensitive patterns from tool and execution outputs before logging or returning them to users.
  • Assume everything produced inside the runtime is untrusted input to the rest of your system.
See Identity Providers and Network Policies for detailed guidance.

​
Next

Create your first sandbox

Quickstart with code, files, and secrets

Runtime overview

How the sandbox works end to end