Deputies
Self-Hosted Background Agents for Engineering Teams
The Problem
Coding agents are powerful when a developer is actively supervising them from a terminal. But using agents across an engineering organization requires much more than an LLM and a command-line tool.
Teams need a way to assign work, run agents in isolated environments, preserve progress, share results, manage access, integrate with existing workflows, and review exactly what happened. Building that control plane requires queues, sandboxes, authentication, event streaming, artifact storage, integrations, and reliable recovery.
Without that infrastructure, agent usage remains tied to individual laptops, difficult to audit, and disconnected from the systems where engineering work begins.
What is Deputies?
Deputies is an open-source control plane for delegating engineering work to background agents.
Give it a task through the web UI, Slack, GitHub, or pretty much any system that can send a webhook. Deputies prepares an isolated sandbox with the appropriate repositories and tools, runs the agent asynchronously, and preserves its progress, diagnostics, artifacts, and final response in a durable session.
It gives engineering teams the shared infrastructure needed to move coding agents out of individual terminals and into repeatable, observable workflows.
How It Works
- Assign work. Start a session from the web UI or trigger one from Slack, GitHub, a webhook, or a schedule.
- Run in isolation. Deputies prepares a sandbox with the selected repositories, environment, tools, and context.
- Follow progress. Watch messages, tool calls, diagnostics, generated artifacts, and application previews as the agent works.
- Review and iterate. Inspect the result, queue follow-up instructions, download artifacts, or have the agent prepare a pull request.
What's Included
| Component | Description |
|---|---|
| Durable Agent Sessions | Persistent sessions with ordered messages, searchable history, replayable events, artifacts, and follow-ups |
| Agent Web UI | Assign work, follow live progress, inspect diagnostics, preview applications, and review results |
| Isolated Sandboxes | Run agents with Daytona, Docker, Tensorlake, Kubernetes Agent Sandbox, or AWS Lambda MicroVM environments |
| Repository Environments | Reusable, revisioned work contexts that can include multiple repositories |
| GitHub Integration | Trigger work from GitHub, provide scoped repository access, and let agents prepare branches and pull requests |
| Slack Integration | Delegate work from Slack threads and deliver completion responses back to the originating conversation |
| Webhooks and Automations | Create agent work from external events or scheduled workflows |
| Artifacts and Previews | Preserve generated files, reports, logs, and links to applications running inside agent sandboxes |
| Queued Follow-Ups | Add instructions while work is running or return later and resume the same durable session |
| Skills and Prompt Snippets | Package repeatable team procedures and quickly reuse common instructions |
| Team Access Control | Tenant-wide viewer, member, and admin roles, with support for private sessions |
| Multiple Model Providers | Use standard LLM API keys or supported subscriptions through the Pi agent runtime |
| Portable Deployment | Deploy with Railway, Docker Compose, Kubernetes, or the AWS reference architecture |
| Observability | OpenTelemetry support for control-plane traces and operational metrics |
Deployment Options
| Deployment | Sandbox Provider | Best For |
|---|---|---|
| Railway Template | Daytona or another hosted provider | Getting a hosted instance running with minimal infrastructure work |
| Docker Compose | Docker | Small teams, a dedicated server, or production-style local deployments |
| Kubernetes Helm Chart | Kubernetes Agent Sandbox | Organizations that want agent execution inside an existing Kubernetes environment |
| AWS Reference Architecture | Lambda MicroVM sandboxes | Teams standardizing on ECS, RDS, S3, and AWS-native isolation |
| Custom Containers | Any supported provider | Organizations with specific networking, security, or infrastructure requirements |
Key Design Decisions
-
Deployability is a core feature. Deputies uses portable infrastructure primitives—Node.js, Postgres, HTTP, containers, and optional S3-compatible storage—rather than depending on a single cloud platform.
-
Agent work is durable. Sessions, messages, events, artifacts, sandbox state, and callback deliveries survive beyond an individual browser tab or developer laptop.
-
Sandboxes are provider-neutral. The control plane owns the workflow while execution environments plug in through a stable provider interface. Teams can choose managed sandboxes, Docker, Kubernetes, or AWS infrastructure based on their requirements.
-
Integrations create work; they do not own it. Slack, GitHub, webhooks, and schedules all feed the same durable session model. Work can be reviewed and continued in Deputies regardless of where it started.
-
You control the trust boundary. Deputies can run alongside private repositories, internal tools, CI systems, and observability platforms. Operators decide where the control plane, sandboxes, credentials, and model access live.
-
Start simple and scale when needed. Run the API and worker together for a small deployment, then split and scale web, API, worker, storage, and sandbox orchestration independently as usage grows.
-
The agent runtime is replaceable infrastructure. Deputies currently uses Pi for real agent work while keeping the durable control-plane concerns (sessions, queues, integrations, artifacts, and sandbox lifecycle) separate from the runner.
Example Workflows
- Assign an issue from GitHub and have an agent investigate it, make a change, run tests, and prepare a pull request.
- Ask for a CI failure investigation from Slack and receive the result back in the same thread.
- Schedule recurring dependency, security, or maintenance checks.
- Launch an agent against multiple related repositories with a preconfigured development environment.
- Generate reports, migration plans, screenshots, or other artifacts and preserve them with the session.
- Run and review an application inside the sandbox before accepting the agent's changes.
- Give agents controlled access to internal tools and data through remote MCP servers such as Executor.
Who Is This For?
Engineering and platform teams who:
- Want to delegate real engineering work without tying execution to individual developer machines
- Need shared visibility into what agents are doing and how they reached their conclusions
- Work with private repositories, internal services, or custom development environments
- Want agents to participate in GitHub, Slack, CI, incident response, and scheduled workflows
- Need control over where agent infrastructure and persisted data are hosted
- Would rather customize an open-source control plane than build agent orchestration from scratch
- Want to start with a small deployment and retain a path to production-scale infrastructure
Deputies is still early-stage and evolving quickly. Expect new capabilities and occasional breaking changes as the project develops.
Links
- Website: deputies.dev
- Live Demo: demo.deputies.dev
- GitHub: github.com/sidpalas/deputies
- Deployment Guide: Deputies deployment documentation
- Deploy on Railway: railway.com/deploy/deputies-monolith