OtoDock
github.com/otodock/oto-dock- Category
- AI Agents
- Rank
- No. 1179Tools index
Previous survey · No. 1154 ·
- Pricing
- Open Source
- Type
- AGENT
- Use case
- Agent Building · Workflow Automation
- Interfaces
- Web · CLI · API · Desktop
- GitHub
- 193 stars
- Latest release
- v1.8.1
- Date
About
OtoDock is a self-hosted, multi-tenant platform for building and running AI agents that connect to a company's tools, delegate work across departments, and keep working unattended on schedules or triggers. It runs on the user's own Claude Code or Codex subscriptions (or local models), supports remote machine pairing, phone-line access via Twilio/Asterisk, and sandboxes every agent with network isolation and encrypted credentials.
What it does
OtoDock is a company-in-a-box for AI agents. You build named agents out of six parts: instructions, standing memory, a shared or private folder, reference documents, learned skills and a permission list of tools. Agents sit in a company map organized by team, and one agent can hand a task to another and wait for the reply. Everything runs on your own hardware, using your own Claude Code, Codex or a local model as the reasoning engine, so the compute bill and the data stay yours rather than a vendor's.
Why it's ranked here
The code backs up the pitch. A phone call pipeline enforces a live-call cap and validates every caller-supplied identifier before it can touch internal state. A path-traversal guard on the dashboard file server resolves and confines every request instead of trusting a substring check. The remote-machine daemon carries its own crash-loop detector that rolls itself back to the last working build rather than bricking a paired machine on a bad update, the kind of defensive detail unattended, credentialed agents actually need. The license is fair source, not open source, and the audio package is still tagged pre-release.
What's good
The telephony layer treats a phone call as a real distributed system problem, not a demo. Inbound and outbound calls each get their own accounting path so a call is logged exactly once, capacity limits reject callers loudly instead of silently dropping them, and PIN digits reach the gate through the phone system's own signaling channel as well as in-band tone detection, so a PIN entry is not lost to a bad connection. The audio layer is provider-agnostic and stateless by design: a provider class takes credentials as arguments and never touches configuration or disk itself, which keeps swapping speech vendors cheap.
Tradeoffs
Running this means running a small fleet of services: a main proxy, a separate telephony daemon, and an optional companion process on every paired machine, each with its own configuration and failure modes. Telephony depends on a self-hosted Asterisk or FreePBX install, or a Twilio account, neither of which is trivial to operate correctly. The audio package is explicitly an early, unstable release. And the license sits under a fair-source model rather than a standard permissive one, worth reading closely before building a commercial product on top of it.
How to use it well
This fits a team that already runs its own servers and wants agents with real authority: reading a shared drive, answering the office phone, running scheduled jobs unattended overnight. Start with one agent on the dashboard before wiring up telephony, since the phone path adds its own operational surface, a PBX or Twilio account, DTMF handling, call capacity limits, on top of the core platform. It is a poor fit for anyone who wants a hosted, zero-ops assistant, or who needs a fully open license rather than a fair-source one with a future open grant.
Technical notes+
audio/__init__.py documents a provider-agnostic STT/TTS/VAD/turn-classifier package shared by proxy/app.py's chat audio routes and phone/main.py's call pipeline; provider classes are documented as pure, taking credentials and audio-format parameters as constructor arguments and never reading the database, environment or filesystem themselves. phone/main.py runs an asyncio TCP server for Asterisk's AudioSocket protocol, rejects new connections once a configured live-call cap is hit, validates the Asterisk uniqueid against a regex before it can key an AMI DTMF registration map, and reports each inbound call exactly once from a single finally block. proxy/app.py is a FastAPI app exposing WebSocket routes for dashboard chat, phone audio, satellite pairing and Twilio media, with explicit router-ordering comments to stop OAuth callback routes from shadowing each other, and a _safe_dashboard_file path resolver that confines requested paths under the dashboard build directory to block a percent-encoded traversal. satellite/__main__.py keeps its boot guard's imports limited to the standard library and a local config module so a broken auto-update, such as a missing or renamed submodule, can trigger a version-matched, crash-safe rollback to satellite.previous before any heavier import runs; it also hash-checks four vendored modules shared with the proxy for drift.
Observed
- License
- Functional Source License 1.1 with Apache 2.0 future grant (FSL-1.1-Apache-2.0)
- Deployment
- Self-hosted via Docker on a Linux server (x86-64 or arm64), 4 GB RAM minimum
- Interfaces
- Web dashboard, embedded terminal (Claude Code / Codex CLI), phone (Twilio or self-hosted Asterisk/FreePBX), MCP tool servers, satellite daemon for paired remote machines
- LLM engines
- Claude Code CLI, Codex CLI, direct provider API calls, or local models, selectable per agent and per chat
- Packaging
- Audio subsystem shipped as a separately versioned package, tagged pre-release (0.1.0a0)
Read from README.md, audio/__init__.py, phone/main.py, proxy/app.py, satellite/__init__.py, satellite/__main__.py, audio/providers/__init__.py, audio/streaming/__init__.py, phone/calls/__init__.py, phone/pipeline/__init__.py, phone/telephony/__init__.py.
What it can do
Encrypt stored credentials
Credentials → Encrypted credentials
Tags
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.