Agent Deployment Modes
There are two primary "types" of agents that can be deployed via Nimbus:
- Agents that you need to interact with via some stdio-based protocol. These will include agents such as:
- Agents running with their own web interface and control stack. These will include agents such as:
Nimbus provides support for both types, and the choice depends on the application.
- Do you need smaller, lean agents with direct ACP control for programmatic access? Use an ACP-compatible agent (such as a bespoke pi.dev, opencode, or codex agent) directly in Nimbus.
- Do you want an all-batteries-included agent platform that comes with all the bells and whistles but still needs some way of managing it? Use a self-hosted agent control stack running on Nimbus.
Note
Nimbus supports cert-manager integration on the ingress routes it creates, so TLS certificates and HTTPS access can be easily used on all created endpoints.
ACP, PI RPC, and Raw Sockets
Nimbus provides an interaction layer that is able to interact with ACP-compliant agents as well as agents that implement the Pi RPC protocol. Both of these protocols exchange messages via JSONL control messages and generally over an stdio channel. This presents a problem for interacting with agents remotely, and in order to address this Nimbus provides the following services running alongside all ACP, PI, and RAW socket agents:
- A shell WebSocket that allows shell access into the container running the agent
- A control WebSocket that wraps the stdio input/output control path of the agent and exposes it via a WebSocket
All agents provisioned in this way have a number of unique ingress routes automatically created to route control operations to the correct agent.
Support for ACP, Pi RPC, and raw stdio input/output is further built into the AgentTriggers to allow direct agent interaction over a standardized control path. This isn't required in order to have triggers work, but it greatly simplifies how they interact with the agents running on Nimbus.
An example of the ACP channel to an agent being used can be seen in the Chat view in nimbus-ui:
Agent Chat Window using ACP
Self-hosted control stacks
Agents such as OpenClaw provide their own fully functional Gateway, Control, Cron, Trigger, and Webhook functionality. Using these types of agents means that AgentTriggers and AgentWebhooks via Nimbus are less effective, and deferring that functionality to the agent directly is best. That is not to say that AgentTriggers and AgentWebhooks won't work - just that the AgentTriggerTemplate needs to be carefully defined and might be limited.
In order to support this mode, the ports that the agent uses to expose its web interface are exposed via unique agent-specific ingress routes, which will proxy traffic into the agent pod for it to handle.
OpenCode on Nimbus
OpenClaw on Nimbus
