vpsFocus
For agencies running 10–30 client sites
A desktop app that deploys an isolated monitoring stack onto each client's VPS over SSH — analytics, server health, domain and certificate expiry — and collects it all into one place. The data stays on the client's server. We never see it.
Free, and installing needs no account. No card, no trial period.
The app talks to the servers directly. Our server knows your account and the domains you connected to paid features — nothing else.
Enter a host, a key and a domain. The app checks that the server is ready, generates the secrets, brings up Umami, Postgres and Caddy in an isolated Docker network, and issues a certificate. If the first install fails, it rolls the server back to how it was.
Before anything is installed, the app collects facts about the server: free space, busy ports, whether sudo needs a password, whether Docker is alive. Not one file is written — the script is piped to standard input, not saved to /tmp.
Umami runs on the client's server and listens on loopback only. The app reaches its panel through an SSH tunnel; the local port is not published either. Visitor data never leaves the client's machine.
It lives on the client's server and watches disk, memory, CPU, domain expiry and certificate expiry. Email and Telegram alerts are sent from that server — so they arrive even when the app is closed.
A stack update takes a database dump and a copy of the configs before touching anything. If a migration goes wrong, both come back. Backups are one button; so is removal, in two clearly separated flavours.
Sites grouped by server, a dashboard per site, an overview across all of them, server health, domain and certificate deadlines, open ports. Ten to thirty clients without ten to thirty browser tabs.
An external check asks what the agent asks: is the page there, is the string on it, does the JSON field have a value, does the redirect happen. A fifth kind asks where the name points — that one is only visible from outside. And Job Guard watches the checks that never answer at all: a backup or cron job reports to its own secret URL, and we write to you when the report does not come.
Add a read-only SQL query on a site's own tab and it becomes a card: a number, a line of text or a small table, sized and arranged by hand. It runs from the app through the same tunnel as analytics — no phpMyAdmin, no SSH console — and the answer stays on this screen: it is never saved or sent anywhere, not even to us.
Turn on mail for a site's domain and add addresses like support@ that forward to an inbox that already exists. The app reads the domain's DNS, prepares the one line it needs if the domain already sends mail, and calls Cloudflare's API with a key that stays on this machine. Mail never touches our infrastructure — it goes straight from Cloudflare to the inbox you chose.
The product is young, and it is more useful to say so plainly than to find out later.
Switching costs time, and that cost is what usually keeps people where they are. Here is what it actually takes.
The stack takes a port of its own and never claims 80 or 443. Your web server is not reconfigured, not restarted and not even asked about — it keeps serving the site while we install beside it. There is no maintenance window because there is nothing to take down.
Remove the stack from the Security screen: containers, volumes, the directory, the firewall rule we added and the log access we were given. Two modes — keep the analytics data or wipe it with everything else. What is left behind is the server as it was.
Analytics live in Postgres on your own VPS and dump to a file you keep. The domains you connect to paid checks are the only thing on our side, and disconnecting a check deletes the domain with it. There is no export to request and no account to close first.
Export your monitors from UptimeRobot or HetrixTools as CSV and import them in the app. The file is read on your machine: you see what it parsed, tick what to carry over, and only that reaches us. More monitors than your plan allows is the normal case — all of them are kept, the plan’s worth run, the rest wait paused. Import switches Remote on for 90 days, once per account; when it ends the plan goes back to free and your checks stay where they are.
Anything that runs on your client's own hardware is free. Anything that consumes our servers or paid API quotas is on the paid plan. That is the whole rule.
No. It lives in a Postgres on the client's server, inside an isolated Docker network. Our server stores your account and the domains of the sites you connected to a paid feature — a domain reaches us at that moment and not before. Installing needs no account at all.
Nothing: they never reach us. Keys, passwords, passphrases and every credential generated during provisioning live in your operating system's credential store. The server list on your disk holds only metadata, and nothing you could sign in with.
No. The stack listens on a port chosen at install time, and never touches ports 80 and 443 if something is already there. It does not reconfigure an existing web server either. That is a hard rule, not a setting: your client's site matters more than our install.
The install finishes on the server anyway — SSH without a pseudo-terminal sends the process no signals. The app finds out how it ended the next time you open the server screen. A failed first install rolls itself back, including removing Docker if we installed it.
The account drops back to the free plan. Nothing is deleted, and the stack on your servers keeps running: it does not need to reach us. What stops is the part that runs on our infrastructure — external uptime checks and the like. Sites and servers stay as many as you had.
One button downloads a Postgres dump plus the stack configuration as an archive. It is an ordinary dump — nothing about it is proprietary.
Adding a server, checking whether it is ready and installing the stack all work without an account. You only need one for what cannot work without our infrastructure — external uptime monitoring and domain reputation checks.