tako-vm 0.1.5

A secure file system and Python execution layer for AI agents: isolated Docker/gVisor containers with job queues, retries, and history

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
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.

Contributing

Contributions are welcome! See CONTRIBUTING.md for dev setup, testing, and PR conventions. Good entry points are issues labeled good first issue, and Discussions is open for questions and ideas.

Contact

Questions, feedback, or partnership inquiries? Reach out to [e-mail].

License

Apache License 2.0