Omnara agents can now run on Tenki Sandboxes
Omnara now supports Tenki Sandboxes as a machine pool provider. Add a Tenki API key and your Omnara agents get their own Linux VMs on demand.
Guzman Pintos
4 min read
Omnara now supports Tenki Sandboxes as a machine provider. Point an Omnara machine pool at your Tenki workspace, and any agent that needs a computer gets its own Tenki VM, created when the agent asks for it and deleted when it's done.
What Omnara does
Omnara is an open source platform for running managed agents. You define an agent's model, tools and instructions, launch it from the API, the CLI, the dashboard or Slack, and Omnara handles execution and state. Agent state lives in Postgres, so an agent picks up where it left off after a crash or a lost machine.
In Omnara, the machine doesn't own the agent. An agent can run with no machine, one, or several, and machines can be added or removed while it runs. You can connect your own laptop or VM, or let Omnara take machines from a pool: capacity it provisions from a sandbox provider when an agent needs it. Until now those providers were Blaxel, Unikraft Cloud, Daytona, Modal and Freestyle, and Tenki joins that list.
What happens when an agent asks for a machine
Omnara creates a Tenki sandbox session with the CPU and memory the pool allows. The Omnara daemon starts when the VM boots and connects back to Omnara, and from then on the agent uses that VM for its commands and files. When the agent releases the machine, or it sits idle past the pool's idle limit, Omnara terminates the session.
Every session Omnara creates is tagged with ownership metadata, and Omnara only lists, inspects or deletes sessions carrying its own tags, so the rest of your Tenki workspace is left alone. Tenki pools also support Omnara's optional runtime protection: with it on, Omnara deletes a sandbox that keeps running after its daemon has gone quiet.
Tenki bills sandboxes per second, which suits this pattern well: agents tend to grab a machine for a short task and let it go.
Set up a Tenki pool
- Create a Tenki API key. The key picks the workspace the sandboxes run in.
- Store the key in Omnara as an org-owned secret.
- Create the pool. In the dashboard, open Machines, click New pool, choose Tenki, select the secret, and set the machine size and limits. From the CLI:
npx omnara pools create \
--name tenki-pool \
--provider tenki \
--provider-auth-secret-id sec_your_tenki_key \
--default-machine-provider-options '{}' \
--default-machine-cpu 2 \
--default-machine-memory-mb 4096 \
--max-machine-cpu 4 \
--max-machine-memory-mb 8192 \
--max-total-cpu 16 \
--max-total-memory-mb 32768 \
--max-total-machines 8
- Grant the pool to a project and reference it from your agent config:
machine_sources:
- machine_pool_name: tenki-pool
max_machines: 3
Choosing the image
If you leave the image empty, machines boot the Tenki base image, an Ubuntu 24.04 VM with common languages and tools already installed. Omnara gives these machines a 20 GB disk unless the pool sets disk_size_gb.
If your agents need the same repo and dependencies every time, build a Tenki template and set the pool's image option to the resulting registry image. Each machine then starts from that prepared environment instead of installing everything at the start of every task. Pools can also set disk_size_gb (5 to 100) and a startup_script, and an org can restrict which images a pool accepts with allowed_images.
The full option reference is in Omnara's machine pool docs.
Get started
If you already use Omnara, add a Tenki pool next to your existing ones and grant it to a project. If you're new to Tenki, the sandbox quickstart takes you from install to a running VM.
I wrote the provider myself, and it ships with opt-in live tests that create and delete real Tenki VMs. Thanks to the Omnara team for reviewing and merging it.


