Self Hosted Agent Infrastructure
Many teams first meet Codebolt as an editor experience. That is real, but incomplete.
Codebolt is also agent infrastructure:
- a runtime for agents
- a server that can sit behind different interfaces
- a way to attach tools, MCP servers, plugins, and custom capabilities
- a platform for long-running and event-driven workflows
- a coordination layer for one agent or many agents working over time
That matters because many customer problems are not "we need an editor that writes code." The real need is closer to:
- "We need an always-on assistant on our own machines."
- "We need an agent gateway behind Slack, Linear, email, or internal tools."
- "We need background monitoring that notices events and acts."
- "We need agents that can coordinate structured work over hours or days."
- "We need to run the same system locally, in Docker, in sandboxes, or in cloud runtimes."
Codebolt supports that broader framing because it can run in multiple shapes:
- as a desktop product
- as a terminal experience
- as a CLI-driven headless runtime
- as a server behind custom interfaces
- as a plugin-hosted web UI through Dynamic Panels
- as a remote runtime in sandboxes or cloud environments
This section is written for buyers, technical leaders, and implementation teams who want to think about how Codebolt can fit into their own infrastructure.
The core idea
Codebolt is not only a place where users type prompts. It can also be the underlying system that:
- receives work from people, systems, or schedules
- routes work to the right agent or workflow
- gives those agents access to files, tools, browsers, terminals, and MCP servers
- keeps context and state across longer-running work
- exposes results back through chat, dashboards, plugins, or other systems
In other words: Codebolt can be the infrastructure layer for the agentic world, not only the interface layer.
What this section covers
| Page | What it covers |
|---|---|
| Deployment Modes and Topologies | How Codebolt can run locally, headlessly, in Docker, in remote sandboxes, and behind custom interfaces |
| Business and Customer Use Cases | The main ways customers can use Codebolt as an always-on assistant, coworker, monitor, or orchestration layer |
| Architecture Patterns | Repeatable architecture shapes for personal, team, embedded, and multi-agent deployments |
| Implementation Anchors | How the platform packages map to these architectures, including server, SDK, plugin, gateway, and sandbox examples |
Why this framing helps
If customers only think of Codebolt as a coding editor, they will underuse it.
If they understand it as agent infrastructure with multiple interfaces, they can reason about:
- where the runtime should live
- which interface should be exposed
- which systems should trigger work
- which plugins or capabilities should be added
- how much autonomy and coordination they want
- what security and control boundaries they need
That leads to much better architecture decisions, especially for companies that want to build internal AI operations instead of isolated chatbot experiments.