Execute untrusted Python code in isolated Docker containers
TakoVM runs agent code in isolated Docker/gVisor sandboxes with built-in job queues, execution history, and replay.
Why it matters
Run AI-generated or untrusted code safely in production by providing isolated execution environments with built-in job queuing, retry logic, execution history, and gVisor sandboxing-eliminating the need to build custom queue infrastructure, persistence layers, and security boundaries.
Outcomes
What it gets done
Execute Python code in ephemeral Docker containers with automatic cleanup and resource limits
Queue and retry failed jobs with built-in worker pools and idempotency keys
Store execution history with stdout, stderr, timing data, and artifacts in PostgreSQL
Isolate untrusted workloads using gVisor, seccomp profiles, and network-deny defaults
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/las7-takovm | bash Overview
TakoVM
TakoVM is a secure execution backend for AI agents, running code in isolated Docker/gVisor containers with a built-in job queue, execution history, retries, and a replay API. Use it when agents need to execute untrusted code and the surrounding infrastructure - queueing, history, retries, replay - matters, not just the sandbox. Strict mode needs explicit config for production.
What it does
TakoVM is a secure execution backend for AI agents: it runs agent-generated Python code in isolated Docker containers, with optional gVisor sandboxing for a userspace-kernel boundary, and bundles the infrastructure a sandbox-only tool leaves you to build yourself - a job queue and worker pool, persisted execution history (stdout, stderr, timing, artifacts), automatic retries, idempotency keys, and a rerun/fork API for replaying past jobs to debug them.
When to use - and when NOT to
Use it when agents need to execute untrusted, often AI-generated code and the surrounding infrastructure - queueing, history, retries, replay - matters as much as the sandbox itself. Compared to sandbox-only tools like e2b, daytona, or microsandbox, TakoVM includes the job queue, execution history, retry logic, idempotency, and replay/debugging that would otherwise require bolting on Redis/Celery, a Postgres schema, and custom tooling. For production workloads running genuinely untrusted code, it needs security_mode: strict with container_runtime: runsc explicitly set - the default permissive mode silently falls back to standard Docker (runc) if gVisor isn't available, which removes the userspace-kernel isolation boundary. It is currently single-use per container; durable, per-agent workspaces that persist and rehydrate across runs are on the roadmap, not yet shipped.
Capabilities
- Job queue and worker pool for async code execution, with no separate Redis/Celery/Bull setup required.
- Execution history: every job persisted with stdout, stderr, timing, and artifacts.
- Replay and debugging: rerun a past job with its exact original code and inputs via a rerun/fork API.
- Docker isolation per job with seccomp filtering, plus optional gVisor for a stronger userspace-kernel boundary.
- Network isolation by default (--network=none), with an optional allowlist per job type.
- Self-hosted: runs on your own machine, offline-capable, with zero per-execution cost.
- Idempotency via an idempotency_key instead of custom deduplication logic.
How to install
pip install "tako-vm[server]"
tako-vm setup # pull the executor Docker image
tako-vm server # start server (auto-starts PostgreSQL via Docker)
Requires Docker and Python 3.10+. Once running, submit code over the REST API (curl -X POST http://localhost:8000/execute -d '{"code": "print(1 + 1)"}'); the CLI also covers local dev (tako-vm dev up --with-server), config validation (tako-vm validate my.yaml), and health checks (tako-vm status).
Who it's for
Teams building AI agents that need to execute code safely and at scale, beyond a bare sandbox, with job queueing, execution history, retries, and replay built in rather than assembled from separate infrastructure. Open source under the Apache License 2.0.
Source README
File system and python execution for your agents. Job queues and Docker isolation built-in. Used by teams deploying in enterprise.
English | 日本語
A secure file system for your agents to execute code. Every job runs in its own
isolated Docker container, with an ephemeral workspace, optional gVisor sandboxing, job
queues, retries, and execution history included.
Where this is headed: durable, per-agent workspaces that persist and rehydrate
across runs, a serverless filesystem for agents. Today each container is single-use;
persistent workspaces are on the roadmap. gVisor remains the sole isolation boundary.
Documentation · Quick Start · API Reference
# Install (requires Docker + Python 3.10+)
pip install "tako-vm[server]"
tako-vm setup # pull the executor Docker image
tako-vm server # start server (auto-starts PostgreSQL via Docker)
# Execute code
curl -X POST http://localhost:8000/execute \
-H "Content-Type: application/json" \
-d '{"code": "print(1 + 1)"}'
Why Tako VM?
Sandbox solutions like e2b, daytona and microsandbox give you isolated code execution, but that's it. You still need to build:
| You build | With sandbox-only | With Tako VM |
|---|---|---|
| Job queue | Redis + Celery/Bull | Built-in |
| Execution history | Postgres + schema | PostgreSQL included |
| Retry logic | Custom code | Automatic |
| Idempotency | Deduplication logic | idempotency_key |
| Replay/debugging | Custom tooling | Rerun/fork API |
Tako VM is the complete package:
- Job queue + workers - Async execution with worker pool, no Redis/Celery setup
- Execution history - Every job persisted with stdout, stderr, timing, artifacts
- Replay to debug - Rerun past jobs with exact same code and inputs
- Docker isolation - Each job in its own container with seccomp filtering
- Network isolation - No network by default, optional allowlist per job type
- Self-hosted - Your machine, offline-capable, zero per-execution cost
CLI
tako-vm setup # Pull executor image and verify Docker
tako-vm server # Start the API server
tako-vm server --port 9000 # Custom port
tako-vm dev up # Start local PostgreSQL for development
tako-vm dev up --with-server # Start PostgreSQL + API server
tako-vm dev status # Check local PostgreSQL status
tako-vm dev down # Stop local PostgreSQL
tako-vm config # Show current configuration
tako-vm config --json # Output as JSON
tako-vm validate # Validate current config
tako-vm validate my.yaml # Validate specific file
tako-vm status # Check server health
tako-vm version # Show version
tako-vm --config my.yaml server # Use specific config file
Documentation
| Topic | Link |
|---|---|
| Installation | docs/getting-started/installation.md |
| Quick Start | docs/getting-started/quickstart.md |
| Configuration | docs/getting-started/configuration.md |
| REST API | docs/api/rest.md |
| Python SDK | docs/api/sdk.md |
| Job Types & Environments | docs/guide/environments.md |
| Filesystem, Caches & ML Models | docs/guide/filesystem-and-caches.md |
| Security | docs/deployment/security.md |
| Deployment | docs/deployment/how-to-deploy.md |
| Config Reference | tako_vm.yaml.example |
Security
Tako VM runs untrusted, often AI-generated, code, so isolation is the core of the project. It uses layered defenses: gVisor (userspace kernel), per-job ephemeral Docker containers, a default-deny seccomp profile, network isolation (--network=none by default), capability dropping, non-root execution, and enforced resource and input limits.
For untrusted workloads in production, set security_mode: strict with container_runtime: runsc. The default permissive mode falls back to standard Docker (runc) if gVisor is unavailable, which removes the userspace-kernel boundary.
See SECURITY.md for the threat model and hardening guidance, and docs/deployment/security.md for full details.
Found a vulnerability? Report it privately via the Security tab → Report a vulnerability. Please do not open public issues for security findings.
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.