The agent that runs on your server is open source. The managed cloud provides identity, plans, tunnel relay, history, and paid monitoring surfaces.
The managed cloud is paid. The agent is not — inspect it, build it, verify it yourself.
The first command should never install anything. Get the binary from the public release, check that the checksum file actually covers the exact filename you downloaded, then run it once before you trust it with anything persistent.
Prefer a script over typing commands? See the inspectable install.sh below — same steps, one file you can read before running.
Prefer a single piped command over the manual steps above? This probe downloads into a temp directory, checks compatibility, then removes itself. No config is created. No service is started. Nothing persists unless you choose to activate.
Sibil is only installed persistently if you choose to activate a trial, setup, or paid plan.
Uses the operational backend endpoint. The public trust surface is sibil.sh; compatibility probes are still issued by monitor.cordee.ovh.
Sibil Monitor is credible because the trust boundary is clear. The backend does not pretend to be your observability plane. The CLI remains the operational root, and the app is a controlled reading surface on top of it.
Install, inspect, and verify first. Start with a posture that cannot surprise the operator.
Actions only unlock when the machine owner enables them locally and the entitlement allows them.
Prefer the WebSocket relay for the first deployment pass. Use reverse proxy or VPN only when you need a direct surface.
A CLI token must be claimed by the authenticated account before the tunnel is accepted.
The app already exposes a CLI guide and bounded pre-configuration. The goal is not to improvise a terminal from your phone. The goal is to generate the right install path, the right flags, and a clean handoff to the server operator.
Choose tunnel or direct URL, detector mode, host, port, and whether service actions should remain disabled. The profile is exportable and readable.
Install the CLI, run `doctor`, claim the server, and keep the process alive with PM2. The assistant stays recipe-based rather than shell-based.
Inspection works immediately. Destructive capability comes later, under dual control: local enablement plus entitlement validation.
Sibil Monitor communicates its boundaries clearly — deployment model, access envelope, and the exact conditions under which control is permitted.
The CLI reads metrics, services, logs, and system state on your machine. Tunnel responses transit without becoming a telemetry warehouse.
A server cannot just appear because someone typed a token. Ownership is now claimed and verified before tunnel usage.
Plan limits are enforced locally by signed entitlements, not by optimistic UI assumptions. Paid access currently proceeds through secure Stripe Checkout.
Start with a safer read-only surface, then graduate to control only when the operational context justifies it.
Sibil Monitor is not trying to centralize your infrastructure. It gives you a cleaner operational surface while keeping the server as the real source of truth.
That distinction matters. The CLI stays where your infrastructure is. The app gives you a clean reading surface without becoming a telemetry warehouse.
Start with a clean VPS setup, continue with local-first mobile monitoring, or request a structured observability audit when an AI stack already has too many moving parts.
For one VPS that needs a clean first monitoring surface.
You leave with Sibil running and your VPS visible.
Full architecture audit and remediation roadmap are not included. This setup covers Sibil installation and connection only.
Request a setupMobile monitoring backed by a local CLI, signed entitlements, and control boundaries that stay explicit.
For builders operating agents, workers, providers, RAG, MCP integrations, and service chains that are hard to read.
The CLI collects local facts. The expert turns facts into decisions.
Request an auditYour backend-managed 3-day trial starts after the first successful VPS connection. Paid plans define module count, refresh cadence, and entitlement scope; they never bypass the local doctrine of the CLI.
Connect your first VPS, then evaluate the product for three full days before choosing ongoing coverage.
A compact monitoring surface for one machine that needs essential visibility and clean mobile access.
The core operational tier for active environments that need tighter cadence and a broader module surface.
Highest cadence, unlimited surface, and entitlement headroom when the server side is ready for more controlled action.