Custom sandbox templates for AI agents, tools preinstalled

Orkestr has launched custom sandbox templates for AI agents that preinstall tools like ripgrep and ffmpeg, eliminating the need for repeated installations at runtime. The templates are built once via API or MCP and can be reused across sandbox sessions, saving time and cost. The feature is available on EU-hosted sandboxes and supports Debian and Wolfi bases.

If you run AI agents in sandboxes, you've probably hit this: every run boots clean, so the agent reinstalls ripgrep, ffmpeg, whatever it needs before it can do anything useful. That's seconds and money spent on the same setup, every single run. EU-hosted sandboxes for AI agents on orkestr now bake custom templates, so those tools are preinstalled instead of reinstalled. Pick a base, give it a recipe of shell steps, and it builds into a reusable template your agents start from with everything already there. The build happens one time. After that, the agent's first command is a real command, not apt-get install . Here's the whole thing - one request to build the template: curl -X POST https://api.orkestr.eu/v1/templates \ -H "Authorization: Bearer $ORKESTR API KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "my-stack", "base template": "debian-12", "recipe": "apt-get update && apt-get install -y ripgrep ffmpeg" , "network": "restricted" }' - { "id": "tmpl 01J...", "status": "building", ... } It builds in the background. Once it's ready you pass that id like any other template, and the tools are already in the box: python from orkestr import Sandbox with Sandbox.create template="tmpl 01J..." as sbx: print sbx.exec "rg --version" .stdout ripgrep, already there You don't have to write any of that by hand, either. The whole thing is exposed over MCP, so you can hand it to your favorite assistant - Claude, Cursor, whatever speaks MCP - and just say "build me a template with ripgrep and ffmpeg on Debian." The agent calls create template itself, polls the build, and comes back with the tmpl ... id ready to use. The thing that's going to run in the sandbox can set the sandbox up. The recipe runs once, at build time, as root. Whatever it does - apt-get install , pip install , cloning a repo, dropping in a config file - gets snapshotted into the image, and every sandbox you launch from that template starts from that snapshot. You don't strictly need a template to install something. The sandbox root is writable, so apt-get install or apk add works at runtime in a plain sandbox. But a runtime install is ephemeral - it's gone the moment the box terminates. Fine for a one-off, wasteful when every run reinstalls the same thing. A template is how you stop paying that cost: install once at build time, and every run after that starts ready. You also get reproducibility - the recipe is the source of truth for what's in the image, so two sandboxes from the same template are the same box. A few things to know about recipes: HOME=/root . Anything they install sticks. apt-get install -y <pkg on debian-12 , apk add <pkg on the Wolfi bases more on the bases below . "network": "open" if a step genuinely needs the open internet.You can build templates from the console https://orkestr.eu/sandboxes , the REST API, or the MCP server, so an agent can build its own templates as a tool call. Full reference is in the templates docs https://orkestr.eu/docs/sandboxes/templates . Early sandbox images were minimal for a real reason. Packing many tenants onto shared infrastructure means a smaller guest is a smaller attack surface. Minimal was a security posture, not a size preference. That changed when each sandbox became its own virtual machine https://dev.to/managed-sandboxes-for-ai-agents/ . The isolation boundary is the VM now - its own kernel, its own filesystem, its own slice of hardware. Whether the guest ships build-essential has nothing to do with whether one tenant can reach another. They can't, because the boundary is the machine, not the package list. So the constraint that justified a stripped-down general-purpose base is gone, and it can just be real Debian. That also matches what E2B, Modal, and Daytona default to, so an agent that works against one of them works against ours without relearning the package manager. The Wolfi bases haven't gone anywhere. Want a small, fast Python or Node start? python-3.12 , python-3.12-bare , and node-22 are still there and still use apk . Rule of thumb: debian-12 when you want a general-purpose box where apt-get works, the Wolfi bases when you want a lean runtime and a quick boot. Tools in the image are half the picture. The other half is what the sandbox is allowed to reach. Sandboxes default to network="restricted" , which routes egress through an allowlisting proxy - package registries, GitHub, the major LLM APIs, and the Debian mirrors are reachable, and nothing else is. That's the right default for code an LLM wrote thirty seconds ago. The gap was everything in between. If your agent needed to hit one internal API or a private package mirror, your only escape used to be network="open" - full egress, which is a much bigger give-up than the one host you actually wanted. So restricted sandboxes can now carry their own allowlist. You pass allow domains and the sandbox reaches the HTTPS hosts you name - on every plan, free included. Naming the one host you trust is strictly safer than opening the whole internet, and you already had open , so there's no reason to paywall the safer option: python from orkestr import Sandbox sbx = Sandbox.create template="debian-12", network="restricted", allow domains= "pypi.org", "pythonhosted.org", "api.internal.example.com" , One thing to know: the list replaces the default set, it doesn't add to it. So include the registries you still need - that's why pypi.org is in the example. It's still HTTPS-only and proxy-mediated; no raw sockets, no DNS tricks, no widening to full egress. Sandbox.limits hands back the default allowlist so you've got a starting point to edit rather than retype. This is where it loops back to templates. You can bake an allow domains default into a custom template, and every restricted sandbox built from it inherits that allowlist unless the create call overrides it. So a template isn't just "my tools are preinstalled" - it's "my tools are preinstalled and the box already knows which hosts it's allowed to talk to." Resolution is simple: the per-sandbox flag wins, then the template's baked default, then the platform default. Custom templates are open - EU hardware, per-second billing, debian-12 ready to go. Build one from the templates docs https://orkestr.eu/docs/sandboxes/templates and point your agent at the id. We're still tuning the build and caching layer, so if you put a real workload through it, tell us how it went - what built slow, what you wanted to bake in that you couldn't. That feedback is what shapes the next pass. What's a custom sandbox template? An image you define once with a base plus a recipe of shell steps. It builds into a tmpl ... id, and every sandbox you create from it boots with your tools already installed - no per-run setup. Do I need a custom template to install packages? No. The sandbox root is writable, so apt-get install and apk add work at runtime in a plain sandbox. But a runtime install is ephemeral - it's gone when the sandbox terminates. A template bakes the install in at build time so every run starts with it already there, no reinstall. Why does apt-get fail in some templates? python-3.12 , python-3.12-bare , and node-22 are built on Wolfi, which uses apk , not apt . Use debian-12 for an apt -based image, or apk add on the Wolfi bases. Does apt work with restricted networking? Yes. The restricted-egress proxy allows deb.debian.org and security.debian.org alongside the package registries it already permitted, so apt-get works on the default network="restricted" without opening full egress. Can a restricted sandbox reach my internal API? Yes, on every plan. Pass allow domains with your HTTPS hosts and the sandbox reaches exactly those. The list replaces the default allowlist, so include any package registries you still need. No need to fall back to full open egress for one host. Baking a default allowlist into a custom template is the one paid-gated path, since custom templates require a paid plan to begin with. Is the old ubuntu-24.04 base gone? It's retired from the docs and UI but still bootable as an alias, so existing callers don't break. New templates should use debian-12 - it's real Debian with working apt-get ; the old one never was.