Zops

ZOPS

A server ops panel that AI agents can actually operate. One Rust binary, one SQLite file, no external services — a desktop-like control panel for a single Linux box, plus a built-in MCP server and skill pack so Codex, Workbuddy or any MCP-capable agent can watch and fix that box under your rules.

Website: https://ops.zenceglow.com · Source: https://github.com/zenceglow/zops

Install

On the server, as root:

curl -fsSL https://cdn.zenceglow.com/app/ops/install.sh | bash

Six short prompts, every one with a default — pressing Enter all the way through gives you a working panel:

It downloads the binary, writes a systemd unit, starts the service, creates the admin account and prints the panel URL, credentials and MCP endpoint.

Same command upgrades. The installer keeps your port, domain, data directory and accounts, backs up the database, then swaps the binary. The panel can also upgrade itself — new versions pop a dialog with an Update now button that downloads, verifies (size → ELF magic → actually runs --version), swaps atomically, keeps a .bak, and restarts the service.

Non-interactive installs read the same values from the environment:

OPS_LANG=en OPS_PORT=5200 OPS_DOMAIN=ops.example.com \
OPS_USER=admin OPS_PASSWORD=secret bash install.sh

Access analytics, fed by the Caddy access log: requests, cities, bots and scanners, blocked probes, and a live traffic feed.

What you get

Desktop — greeting, health score, live pressure, and a request-path map that draws every domain to the container serving it	Sites — visual entries next to the raw Caddyfile, validated before saving, versioned in SQLite
Docker — per-container usage, images with sizes, networks, junk, and an editable engine config (registry mirrors)	MCP — create a token, copy the config into your agent, and see exactly what it is allowed to do

Why not another panel

Panels like 宝塔 / 1Panel / Cockpit are forms for humans; agent support, when it exists, is a bolt-on. ZOPS starts from the other end — the panel is the only door, for you and for the agent. That is what makes it safe to let an agent near production:

Features

Desktop — a health score ring, live CPU / memory / disk / swap, and a request path map from domain to container. Not a wall of tables.

Server — timezone, swap file, firewall, and patch management that detects the distro (Ubuntu / Debian / CentOS / Rocky…) and folds outstanding security updates into the health score. Cleanup scans first, shows you what it found, then asks.

Docker — containers (start / stop / restart / delete), images (size, in use by, delete), networks, junk, and the engine config: edit registry-mirrors and insecure-registries in a form, or the raw JSON. Validated, backed up, written atomically, then Docker restarts.

Caddy gateway — every site is written between # ZOPS:BEGIN/END markers, so edits and deletions touch one site instead of the whole file, and nothing is saved until caddy validate passes. Config history lives in SQLite.

Also — SSH terminal, application log viewer, scheduled tasks, notification channels (Feishu / DingTalk / WeCom / Slack / Discord / Telegram / webhook), members with RBAC, an operation audit log, and in-panel self-update.

Storage — everything the panel knows lives in one SQLite file, so that file is also the thing that can quietly eat the disk. Settings → Storage shows its real size (main file + WAL), how many rows each table holds, which ones shrink on their own and which don't, with a retention window you can change and a Compact button that actually gives the space back. Deleting rows never shrinks a SQLite file on its own — that distinction is the whole point of the page.

Connect an agent

Open MCP in the panel, create a token (read or write) and copy the config:

# ~/.codex/config.toml
[mcp_servers.zops]
url = "https://ops.example.com/api/ops/mcp"
http_headers = { Authorization = "Bearer ops_xxxxxxxx" }

The same page gives you a one-liner that installs the skill pack into the agent's skill directory — that is the difference between "the agent has 34 tools" and "the agent knows what to do with them".

panel       ops_panel_info            ops_system_overview
container   ops_container_list        ops_container_status     ops_container_logs
            ops_container_start       ops_container_stop       ops_container_restart
gateway     ops_gateway_status        ops_gateway_logs         ops_gateway_reload
            ops_caddyfile_get         ops_caddyfile_put
logs        ops_log_source_list       ops_log_tail
server      ops_port_list             ops_member_list          ops_automation_task_list
            ops_automation_task_run
notify      ops_notify_channel_list   ops_notify_send
deploy      ops_deploy_list           ops_deploy_plan          ops_deploy_apply
job         ops_deploy_job_list       ops_deploy_job_get       ops_deploy_job_create
            ops_deploy_job_put_script ops_deploy_job_put_file  ops_deploy_job_run
            ops_deploy_job_log
app         ops_app_list              ops_app_plan             ops_app_install

ops_deploy_job_* is how a compiled binary reaches the box without SSH: create the job, push text artifacts over MCP, upload binaries with curl -T, run the script, poll the log.

Tokens are hashed server-side and shown once. State-changing tools carry an explicit "changes the server" flag, and the skill instructs the agent to get your confirmation before calling them.

Deploy your own apps

Give the agent a project directory and it will:

1. Look at the machine first — ops_port_list for a free port, ops_deploy_list to avoid name collisions, instead of guessing.
2. Run a production check — restart policy, log rotation, time zone, network, plaintext credentials. Missing items come back as warn or block.
3. Ask only when it matters — a missing log rotation policy is a warn; a hardcoded database password is a block.
4. Write and start it — generates the compose file, runs docker compose up -d --build, reports the port and URL.

You stop writing Docker configs by hand and still get the layout you would have written yourself.

Security model

• One door. Agents go through the panel, never the host. Every write is a typed tool call, not an arbitrary shell.
• Scopes. read tokens cannot call state-changing tools, and MCP tools/list filters by permission — the agent does not even see them.
• Audit. Every write, human or agent, records actor, kind, IP, method, path, status, a summary and a redacted body. Secrets are stripped before writing.
• Validate before save. Caddy config is validated in a temp file first, so a bad site can no longer take the whole gateway down.
• Accounts. Argon2 hashes, JWT sessions, role-based permissions. Locked out? zenceglow-ops --reset-password <user> <new> on the box.

Develop

./dev.sh              # frontend :5173, backend :127.0.0.1:5200
cargo test            # backend tests
cd frontend && npx tsc --noEmit

Rust (axum + SQLite) and React + Vite + Tailwind, embedded into the binary with rust-embed so production is a single file. See API-CONVENTIONS.md for the response envelope and route conventions.

Release

# 1. bump Cargo.toml version — it is the only source of truth
# 2. commit (the commit subject becomes the release note)
git commit -am "feat: ..."
./deploy.sh

deploy.sh builds the frontend, cross-compiles with cargo zigbuild, smoke-tests the binary locally (must start, /api/ops/version must answer, unknown /api paths must return JSON 404 rather than falling through to the SPA), then uploads to R2 under four keys:

All served from https://cdn.zenceglow.com/app/ops/… with max-age=300.

The version must be strictly greater than latest.json on the CDN. Forgetting to bump it fails silently: everything uploads fine and installed panels never see the update.

Credentials: wrangler login, or CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID for CI. --remote is mandatory on the wrangler r2 calls — without it wrangler writes to a local simulator and still prints "upload complete".

Once published, the panel updates itself: it downloads, verifies (size → ELF magic → runs --version), swaps atomically, keeps a .bak, restarts.

Keywords

AI agent server management · MCP server for DevOps · Codex skill · Workbuddy · agent operations tool · Agent 运维工具 · Docker panel · Caddy GUI · single-server ops · self-hosted panel · 宝塔替代 · 1Panel alternative · deploy your app from an agent

License

MIT © 2026 Zenceglow (广州境际之光科技有限公司) · [email protected] · https://ops.zenceglow.com