Onserva asks to sit next to your production servers. That is a lot to ask, so here is exactly what it can and cannot do, and how each limit is actually enforced rather than merely intended.
Onserva is hosted separately from every machine it watches. Nothing about the monitoring depends on the health of the thing being monitored.
This is why silence is meaningful: if a server stops reporting, that absence is itself an alert. A machine cannot suppress its own alarm by failing, and an attacker who takes one cannot quietly switch off the watching either.
The agent installed on your server opens no port and accepts no connection. It makes outbound HTTPS requests and nothing else, so installing it adds no new way into your machine — for anyone, including us.
It runs as its own unprivileged user with no capabilities, and reads only the statistics the operating system already publishes about itself. It holds no credential of yours and needs no administrative rights to do its job.
Work you have authorised is collected in the reply to a check-in the agent was making anyway. That is why fixes need no inbound access and work perfectly well behind a firewall you have not changed.
Claude reads your readings and writes the explanation. What it cannot do is decide what happens next in any open-ended way: it is asked to choose from a fixed list of pre-tested actions, and the shape of the question makes anything outside that list impossible to express, not merely discouraged.
If nothing on the list genuinely fits, the answer is that the problem needs a person — which is treated as a complete, correct answer rather than a failure.
The list itself is short and deliberately expensive to extend: adding an action requires a change to the platform, a matching change to the agent, a test on a real machine, and a release. That friction is the point.
When you authorise a fix, what travels to your server is a key and a target — never a command. The agent maps that key to a command it was compiled with.
So even a completely compromised platform could not make one of your machines run something arbitrary. It could only ask for an action the agent already knew how to perform, against a target validated on both sides.
The part of the agent that can change anything is a separate program that runs with no network access at all. The half that talks to us has no privileges; the half with privileges cannot talk to us.
Technical customers can get at the real numbers: per-server alert thresholds, the full 90-day history, CSV and JSON exports, a webhook channel, and a read-only API that feeds Prometheus or Grafana. Every one of those is a window, not a lever — an API token can read the metrics of its own account and can write nothing, anywhere, because no write exists for it to call.
The request we will not honour, from anyone, is a shell — "just let us run one command". The day Onserva can relay an arbitrary command to your machine, everything else on this page stops being true. So the fixed allowlist applies to every account, on every plan, including our own.
That refusal is not a limitation we apologise for. It is the reason the rest of this page can be believed.
Nothing runs on your server until you press Authorise, every single time. There is no automatic mode, and no setting that turns one on.
The screen where you approve says what will happen and what it costs if it goes wrong — that a restart briefly interrupts what the program serves, for instance — above the button rather than after it.
Who proposed an action, who approved it, when it was sent, and exactly what the server said back all go into an append-only log.
Append-only is enforced by the database itself: attempts to edit or delete an entry are refused for every account, including ours. The record can grow, and that is all it can do.
Every customer belongs to their own organisation, and every row of data belongs to one. Which rows you can see is decided by PostgreSQL row-level security, evaluated on every query under your own identity.
This matters because it does not rely on our application remembering to filter correctly. A mistake in our code cannot show your servers to another customer — the database would refuse the query regardless.
We verify this rather than assume it: an automated check creates two separate tenants and asserts, against the real database, that neither can read or alter anything belonging to the other.
Every account must set up an authenticator app before it can reach any data, including ours. There is no way to opt out and no weaker tier.
Passwords are held by Supabase Auth, hashed, and never by us in any readable form.
When you ask Onserva to set up a new server, the sign-in you hand over is stored encrypted in a vault and deleted the instant the work begins — before the first command runs.
The recipe replaces it: it creates an ordinary account that signs in with your own key, verifies that key actually works, and only then switches off root sign-in and password sign-in for good. If any check fails, it stops and leaves your original access intact rather than locking you out.
The provisioning worker never runs on our platform or on any monitored machine, and holds credentials only in memory for the length of one job.
A security page that only lists strengths is a sales page. These are the real edges.
If you believe you have found a security issue in Onserva, please email hello@onserva.com with enough detail to reproduce it. We will acknowledge you within two working days, and we will not take action against anyone who reports something in good faith.