Many engines, one console
Drive Claude Code and Gemini through their own CLIs, or call Claude, OpenAI, Gemini, Kimi and Qwen straight through the API. Pick the engine per run without leaving the page.
Self-hosted. Runs on your own server.
One console for every coding agent you run on your server.
AgentOps points Claude Code, Gemini and API models at the projects you register, a local directory or a remote host over SSH. Brief an agent, watch the run stream, and stop it the moment it wanders.
Your files, runs and keys stay on your box. The only thing that leaves is the model request itself.
A plain Node service on the stack already on your box
- Node.js
- Fastify
- SQLite
- systemd
- OpenLiteSpeed
- Claude Code & Gemini
Every engine in one place, pointed only where you allow
The console answers three questions on every run: which project, which engine, and what changed.
Projects, local or remote
Register a project as a directory on this server or a path on another host over SSH. The agent works there, and nowhere you did not register.
A guard on the working directory
Before a local run starts, the workspace guard resolves the real path, follows symlinks, and pins the agent to the project root, so a sibling like app-backup can never pass as app.
Live output you can stop
Watch the run stream over a WebSocket instead of waiting for a summary. Hit stop and it sends SIGTERM, then SIGKILL after a grace window; every run has a hard time limit besides.
Agents, skills and task building
Pick a persona from the agent library, attach skills, and compose multi-agent jobs in the task builder. Resume any conversation to carry its context into the next pass.
Every run on the record
Briefs, turns, tool calls and outputs land in a local SQLite database. Reopen a transcript, continue where it left off, and track token usage per run.
From a brief to a reviewed change
Register a project once, then it is pick, brief, review. Nothing runs anywhere you did not point it.
Register a project
Add a local directory or a remote host over SSH. Write access stays off until you grant it, and the console proves the grant with a real create-and-delete before it trusts it.
Brief an agent
Choose an engine and a persona, describe the change in plain language, and start the run. The working directory is pinned to the project you picked.
Watch, then keep or resume
Follow the streamed output, stop it if it heads the wrong way, and read the result. Continue the conversation for another pass, or leave the project exactly as it was.
The security model, in full
An agent with write access on a shared host is a real risk. Here is what stands between a run and the rest of your server.
Workspace guard
The guard resolves each project path with realpath, rejects anything that is not absolute, and demands a true directory boundary, so one project root cannot be mistaken for a neighbour. It ships with its own test suite.
Explicit, granted write access
The service runs as one dedicated system user, not root and not your site owners. A project stays read-only until you grant write, which adds a POSIX ACL through a single audited root script and confirms it with a live write probe.
Secrets encrypted at rest
API keys are sealed with AES-256-GCM under a master key and never returned to the browser. The admin sign-in is bcrypt-hashed with optional TOTP two-factor, rate-limited attempts, and server-side sessions.
Self-hosted, single tenant
The database, the transcripts, your uploads and your files all live on your own server. Nothing is copied to a third-party dashboard; the only thing that leaves the box is the model request.
Questions worth asking first
Especially the ones about blast radius.
What is actually running when I start a job?
The engine you picked, headless, with its working directory pinned to the project you chose. For Claude Code that is claude -p in streaming-JSON mode. The console owns the parts a bare terminal session does not: who may start a run, where it may run, and where the transcript goes afterwards.
Which models can it use?
Claude Code and Gemini through their own command-line tools, plus Claude, OpenAI, Gemini, Kimi and Qwen over the API. You choose the engine per run, and any API keys are stored encrypted and never handed back to the browser.
Can a run reach another project on the server?
For local projects the workspace guard resolves the real path and pins the working directory to that project's root before the run starts, and the service runs as one dedicated user whose write access is limited to the directories you have granted. Remote projects run over SSH and are contained on the far host.
Where does my data live?
On your server. Run history and settings are kept in a local SQLite database next to the application, and your project files never move. Nothing is copied to a third-party service.
Does it require CyberPanel?
It is built for the CyberPanel and OpenLiteSpeed layout and ships a vHost proxy snippet, but underneath it is a plain Node service bound to localhost. Any host that can reverse-proxy to it will serve it just as well.
Point an agent at a project and watch what it does
Sign in, register a project, and give it something small first. The transcript will tell you whether to trust it with something bigger.