A personal ops dashboard for Zo Computer — built by a Zo user, for Zo users.
See what's running on your Zo, tail logs, browse your databases, track automations, and monitor workspace health — all in one place, without needing AI to be active.
⚠️ Always install as a private service. ZoOps exposes your workspace files, service logs, database contents, and system metrics. It has no authentication layer of its own — it relies entirely on Zo's private service gating. Never publish it as a public service or expose it on a public port. The install instructions below register it as private by default; don't change that.
Open your Zo chat and send this one message:
Install ZoOps from github.com/sthoms12/zoops and register it as a private service
Your Zo AI will clone the repo, install dependencies, and register it as a persistent private service automatically.
Open your Zo terminal and run:
curl -fsSL https://raw.githubusercontent.com/sthoms12/zoops/main/setup.sh | bashThe script clones, installs, and attempts to auto-register the service using your Zo identity token. If that step fails it prints the exact prompt to paste into your Zo chat.
git clone https://github.com/sthoms12/zoops /home/workspace/zoops
cd /home/workspace/zoops
bun installThen ask your Zo AI:
Register ZoOps as a private Zo service. Entrypoint:
bash -c "cd /home/workspace/zoops && NODE_ENV=production bun run server.ts", port 50165.
| Page | What it does |
|---|---|
| Command Center | Exception-first attention queue, inventory, monitored services, and current composite health |
| Sites & Services | Zo sites, zo.space pages, and published service surfaces |
| Services | Registered services with live HTTP health checks, latency, failure streaks, and check history |
| Automations | Cached scheduled-agent inventory with source age, schedule, and delivery method |
| Schedule | Cached schedule catalog grouped by daily, weekly, monthly, and other cadences |
| Discovery | Auto-scanned workspace items (sites, DBs, skills, logs) |
| Workspace Changelog | Diff between discovery scans — what was added or removed |
| Log Viewer | Live tail of any /dev/shm/*.log service log, with severity coloring |
| DB Explorer | Browse and query any SQLite database discovered in your workspace |
| Skills & Personas | Catalog of workspace skills and personas |
| Health | Composite host, service, automation, discovery, and application health |
| Settings | Persistent key/value config |
- Runtime: Bun + Hono
- Frontend: React + Vite + Tailwind v4 + shadcn/ui
- Database: SQLite (local, zero config)
- Local-first — normal operation reads your Zo filesystem directly; optional AI automation sync is disabled by default
| Command | What it does |
|---|---|
bun run dev |
Dev server (port 50165, Vite HMR on 50166) |
bun run build |
Production build into dist/ |
bun run test |
Unit test suite |
bun run typecheck |
TypeScript validation without emitting files |
bun run check |
Tests, typecheck, and production build |
bun run smoke |
Read-only API and SPA route smoke test against a running ZoOps instance |
bun run prod |
Build + serve production |
All state lives in data/zoops.db (SQLite, gitignored). Each install gets a fresh database. On first boot, ZoOps scans your workspace. If data/automations-snapshot.json exists, it loads that local automation snapshot; otherwise the automation inventory starts empty. Reload snapshot reads that file locally and never calls AI.
Zo Space discovery reads the authenticated route inventory directly from Zo's route API using the runtime identity token. ZoOps stores only path, route type, visibility, and capture time in a local last-known-good cache; route source code and credentials are never cached. Page routes and public-facing HTML API routes appear as site surfaces, while /api/*, internal probes, robots.txt, and sitemap.xml do not. Every Space link is stored as an absolute URL. Private pages remain visible but are excluded from anonymous health checks.
Optional Sync with AI is disabled by default. To use it, enable AI calls in Settings and confirm each individual sync from the Automations page. Every AI sync may consume AI usage. ZoOps never schedules AI synchronization in the background. If an AI sync fails or returns a partial list, ZoOps keeps the existing cache rather than deleting unmatched records.
Automation rows are reconciled against the latest authoritative local snapshot, while user notes are preserved. Schedule status distinguishes upcoming, overdue, inactive, and unknown records instead of treating every timestamp as upcoming.
Service monitoring is observational. Every five minutes ZoOps checks eligible public HTTP endpoints and records response time, HTTP status, last success, consecutive failures, and recent check history. Private Zo services, private Space routes, local-only ports, and non-HTTP records remain visible inventory but are excluded from automatic checks and unchecked-warning totals. ZoOps intentionally does not kill processes or restart services; process control belongs to Zo's managed hosting layer.
Automation data is cached reference information and never affects operational health. When its source is stale, ZoOps labels the synchronization age, hides cached next-run timestamps, and presents recurring schedules as a cadence catalog rather than inventing future dates. Zo currently exposes no direct non-AI automation inventory endpoint to ZoOps, so a current inventory requires an explicitly confirmed AI sync until such an endpoint is available.
The settings API never returns stored reporting tokens to the browser. ZoOps still has no application-level authentication, so private service gating remains mandatory.
Before a release, run bun run check, start a production instance, then run bun run smoke. The smoke test is read-only and can target another base URL with ZOOPS_BASE_URL.
Bug reports and pull requests are welcome. Read CONTRIBUTING.md for the development and verification workflow. Security-sensitive reports should follow SECURITY.md.
When a user asks you to install ZoOps, follow these steps:
- Clone the repo:
git clone https://github.com/sthoms12/zoops /home/workspace/zoops - Install:
cd /home/workspace/zoops && bun install - Register as a private Zo service:
- Name:
ZoOps - Entrypoint:
bash -c "cd /home/workspace/zoops && NODE_ENV=production bun run server.ts" - Local port:
50165 - Mode:
http - Private:
true
- Name:
- Return the service URL to the user.
If /home/workspace/zoops already exists, run git pull instead of cloning.
MIT — free to use, modify, and share.
Built by @thomstech · Zo Computer