Documentation

Installing the app

The app runs on your own machine — Windows, macOS or Linux. It is not a cloud service: the list of servers is kept on your disk, and keys and passwords in your operating system's secure storage.

1. Download the installer from the download page.
2. Run it. Installers are not yet signed with a developer certificate, so Windows shows a SmartScreen warning and macOS shows Gatekeeper. The download page explains what to click.
3. Open the app. Adding a server and checking whether it is ready both work straight away, with no account.
4. Install the monitoring. No account is needed for that: the installation files are available to everyone, no plan limits the number of servers or sites, and everything free works without signing up.
5. An account is only needed for the features that cannot work without vpsFocus servers — today that is external site checks and Jobs. Sign up here or inside the app, then confirm your address with the link from the email: until it is confirmed, the paid features are unavailable — outage messages are sent to this address.

Connecting a server

What the server needs

• A Linux VPS running systemd — tested on Debian and Ubuntu.
• SSH access as root, or as a user with passwordless sudo. Provisioning runs unattended and would simply hang on a password prompt.
• One free port — provisioning picks which. Busy 80 and 443 are not a problem: the monitoring does not take them and runs next to your web server. The port is chosen from a list compatible with Cloudflare, and it goes into the analytics code on your site.
• About 2 GB of free disk and 1 GB of memory. The installer sets up Docker itself if it is missing.
• A domain or subdomain for the analytics panel. With 80 and 443 free, an A record pointing at this server is enough. With them busy, the certificate is issued over DNS-01: you will need either API access to your DNS (Cloudflare, Route 53, DigitalOcean) or a single CNAME pointing at the vpsFocus fallback server — the app tells you which one.

Step by step

1. Add the server. Host, port, user and how to sign in: a private key (ed25519, RSA or ECDSA in OpenSSH format, passphrase supported) or a password. PuTTY .ppk keys are not supported — convert one in PuTTYgen via Conversions → Export OpenSSH key. At first the app only checks the sign-in and writes nothing to disk; on the first connection it remembers the server's host key and checks it from then on.
2. Open "Setup & install" — a single card leads from there. It has four parts: connect, check, install and launch, a percentage, and one line saying what the app is doing right now.
3. The check runs by itself. The app downloads the installation files (no account needed, outdated ones are replaced automatically), finds the server address and looks at the server: busy ports, Docker, the firewall, memory and space, sites in the web server settings and certificates already issued. The check leaves not a single file behind: the script is passed over the connection and never written to disk. Findings are shown one by one, only what was actually counted; blockers (sudo asking for a password, a dead Docker daemon, not enough disk) have to be fixed, while busy 80 and 443 are not among them — the monitoring goes to another port. The full check report is under "All check results".
4. Answer three questions. The statistics address — the app fills in a subdomain of a site it found. The records at your registrar — an A record to the server address and, if 443 is taken and your DNS has no API, a CNAME to confirm the certificate; the app checks them itself every 10 seconds, and you don't have to wait: the certificate is issued on its own once the records spread. If a certificate for this address was found on the server, you can use it. And the firewall checkbox — whether to add a rule for the chosen port; that rule is the only change outside the monitoring's folder and Docker, and rolling back the installation removes it. The certificate email, the port and your own certificate are under "Advanced".
5. Install the monitoring. The app generates the secrets (Postgres password, the analytics session key and the admin password), stores them in your OS secure storage, and starts three containers on the server: Umami, Postgres and Caddy. You can leave the screen — the install runs on the server, and its progress is in the card and in a small card when you come back. If something goes wrong, the card says what happened and what to do, and the install rolls itself back.

The “Projects” home screen

One page for all your servers and sites: what is broken, where and how badly. The app gets the data when you open the screen and when you press “Refresh” — one visit per server, no more than six servers at a time; it does not re-read on a timer. Each section shows when its data was received. A server that did not answer stays on the screen in grey with the reason — “no data” is never shown as “all fine”.

• Status overview — how many sites and in what state, how many servers are reachable, the next deadline, visitors in the last 24 hours, and a “servers → sites → check results” diagram. Each band is one finding: “site is down”, “expiring soon”, “broken links”, “average speed”. The monitoring on the server rates them; the app only lays them out. When a server has more than eight sites, the ones without findings are collapsed into one node that opens on click.
• Servers — server status apart from its sites: a full disk is one line for the server, not red sites. The monitoring version and an available update are shown here too. Clicking a server shows only its sites under “Sites”.
• Sites — sites with problems first; on the right, details of the selected one: findings, speed, SEO, links, deadlines and links to the right screens.
• Deadlines in the next 90 days — domains, certificates, your plan and your own calendar entries.
• Site figures — speed (Google mobile score), SEO, broken links and the external uptime check on shared scales.
• Server resources — CPU, memory and disk with the notification threshold, disk growth over 24 hours, time since reboot, containers and failed services. The app reads containers and services over SSH, read-only; nothing is left on the server.
• Visitors — for 24 hours, 7 or 30 days: visitors, page views, bounces and average time per project, with a link to the site’s analytics. Search and AI robot requests are shown separately: they are requests from logs, not visits.
• Last 24 hours, backups and security check, notification channels — as the monitoring on each server sees them. The security check result is not stored anywhere: after restarting the app, run it again.

The “Needs attention” tab orders the same findings by priority: “Urgent”, “In the coming days” (a deadline or growth — certificate, disk, backup, errors), “Improvements” (speed, SEO, links, analytics) and “No data” (the check did not happen). The same finding on several sites is one item; “Ignore” on it first shows which sites it will be muted on. The “Findings map” is servers × check areas. “Last 7 days” shows finding counts per day: the app records them once a day on your computer, numbers only, no domains or server names, and they never go to our server. A day when the app was not opened is shown as “no data”, not zero.

Sites and analytics

1. Press “Look for sites” if the server already runs a web server: the app finds domains in its settings and among the certificates. Nothing on the server is changed or restarted. The list stays on your computer.
2. Add a site to the server: domain and name. No plan limits how many sites you may have, and the domain is sent to vpsFocus servers only when you connect the site to a paid feature.
3. Copy the analytics code into the site's <head>. Visitor data is collected on your server.
4. Site analytics opens in the app, and visitors of all sites for 24 hours, 7 or 30 days are in the “Visitors” section of the main “Projects” screen. A site has seven sections: overview, sources with channels, UTM tags and a separate “From AI services” block — people who came through a link in an answer from ChatGPT, Perplexity, Claude and others, pages with entries and exits, visitors (a world map by country, countries, cities, devices, browsers and “when they visit” by weekday and hour), visitor actions, behavior (returns, common paths, funnels) and visits — each with its pages in order, plus a live feed with its own map where countries with a visit in the last few minutes pulse. The map is drawn inside the app — it calls no map service. Clicking a row in any table filters the whole screen. The analytics panel is not exposed: the app reaches it through an SSH tunnel, and the local port is not published either.
5. Open the site's “Data” tab to add a read-only SQL query against its own database — on the server itself or in a Docker container by name; MySQL, MariaDB, PostgreSQL or SQLite. It runs through the same tunnel and turns into a card: a number, a short line of text or a small table, sized and ordered by hand. The connection needs a user that can only SELECT, and the screen writes the GRANT for you; a superuser is refused outright. The answer stays on this screen — it is not saved to disk and not sent anywhere.
6. On the Notification channels screen, choose where to write: email, Telegram, Slack, Discord or an address of your own (a webhook) — one is enough, and if you set up several the message goes to all of them. Slack and Discord need only an “incoming webhook” address: the screen tells you step by step where to get it. Email needs a mailbox the server will send through: the Gmail and Resend buttons fill in the server and port, and the steps next to them explain where to get an app password. If emails do not go out, your server's hosting provider may block mail ports — ask their support. Your own address is accepted only with https:// and only on the internet — the monitoring will not follow it to the server itself or into its internal network. Notifications are sent by the monitoring on your server, so they arrive even when the app is closed. Every block has a “Send a test” button that checks that channel alone.
7. On the Notifications screen, set what to write about and when: thresholds, message language, the weekly report. The settings are shared by all servers; if not every server should write, clear the checkbox for the extra ones in the “Which servers send notifications” block — such a server keeps watching but stays quiet.
8. To avoid being woken up for trifles, turn on “Quiet hours” there: from which hour until which, in your computer’s time zone. At night only what is breaking the site right now arrives at once: a key address does not answer, many server errors, the disk is running out of space, the database backup failed, a certificate or domain expires today — and the message that the problem is resolved. Everything else (expiring soon, a smaller backup, a certificate or domain fine again) arrives in the morning. Availability emails from our server ignore quiet hours.

How the analytics differs from Google Analytics

The analytics runs entirely on your server and uses no cookies. Visitor data goes nowhere, and the script weighs a couple of kilobytes and does not slow the site down. That is why some reports familiar from Google Analytics are not here.

• No gender, age or interests. Google works out gender, age and interests by following a person across the web through its accounts and ad networks. The analytics on your server does not collect this.
• No search phrases. Search engines do not tell a site which phrase a visitor searched for — Google Analytics does not get it either. You see which search engine a person came from; the phrases themselves are free in Google Search Console.
• No session replay or heatmaps. Recording mouse movements creates a heavy stream of data and captures the behaviour of a specific person. Instead there is the Visits section: which pages a person opened, in what order.
• People are counted approximately. Without cookies a visitor is recognised by browser and address. A person who visits from a phone and a computer counts as two visitors. Counting starts over on the first of every month, so over a period longer than a month there are slightly more visitors than people.
• No link to your ads. Google Ads accepts conversions only from its own tag. If you need automated bidding, add its tag alongside — the vpsFocus tag does not get in its way.
• No history before install. Data is collected from the moment the analytics code appears on the site. History cannot be moved over from Google Analytics.
• Some visitors are invisible. Some ad blockers hide analytics, this one included. It happens less often than with Google Analytics, because the script loads from your own domain.

Button clicks are not counted on their own: give a button a data-umami-event="Sign up" attribute and every click shows up in the Actions section. A ready-made text for the AI assistant that built your site is there too.

The monitoring watches disk, memory and CPU, plus domain and certificate expiry. It raises an alarm only for things that will not fix themselves: disk space or the file limit (inodes) running out (there can be free space while no new file can be created — usually because of a folder with a huge number of small files), a certificate or domain about to expire. The server’s root partition is counted.

On the Server health screen the app also asks the server over SSH which services have failed and how much memory and CPU each Docker container uses (CPU is the current reading). This is read-only, no file is left on the server, and there are no alerts on this data: it has no history. Some services fail harmlessly (cloud-init, for example) — the screen says so.

External checks and Job Guard

They run from vpsFocus servers, not from yours: that way an outage is noticed even if your whole server goes down. That is also why they are paid — those servers have to be paid for. The plan counts checks, not sites: a site can have several — the home page, /api/health, the login page. There is no limit on sites or servers on any plan.

Every check has a profile — the same options as key addresses in Diagnostics:

• Page — the address answers with a code below 400.
• Text — a string you name is present in the response body. Case matters: search for it exactly as it appears on the page.
• JSON — the response parses as JSON and the field you name is not empty. The value itself is not compared: otherwise a changing counter would raise false alarms.
• Redirect — the address redirects, with the code you expect. Where it leads is not checked from outside, and the screen says so plainly. The target is verified by the key address check on the server itself.
• Port — a port on the domain accepts connections: mail (25, 465, 587, 993), SSH (22), a game server, your own service. Only the connection is checked — no response code and no certificate date. A database port is not worth checking from outside: the check passes only if the database is open to the internet, and the screen warns you about it.
• DNS — the domain resolves to the addresses you pinned. Only the external check has this profile: such a change cannot be seen from inside the server. The alarm comes after three failed checks in a row, because DNS changes do not spread instantly.

An external check sends no headers and no access keys — they stay with you. Pages behind a password are checked by the monitoring on your server (key addresses in Diagnostics): there headers are supported, and they are kept in a file only the monitoring reads.

A port on the server — free, from the inside. A database, Redis or any other service that should not be visible from the internet is watched by the monitoring on the server itself: in Diagnostics a key address has the kind “Port on the server”. The monitoring reads the server's list of ports — whether a service holds the port — and writes when the service disappears and when it comes back. The screen also says where the service listens: “this server only” or “accepts connections from the network”. A held port means the service is running, not that it answers correctly; a service in a container without a published port is not visible from here. It needs monitoring version 0.30.0 or newer, no account.

Job Guard watches what never answers at all — a nightly backup, a sync, an export. After each run the job sends a short signal to its own secret address; you say how often it runs and how late it may be, and if the signal does not arrive on time, you get an email. The app gives you a ready-made line and shows where to add it. The schedule is a period plus an allowance for lateness, not a cron expression. "The job reported an error" and "no signal" are different messages: for the first, look at the job's log; for the second, at cron. A job that has never sent a signal also counts as missing. Keep in mind: anyone who knows the address can send a "done" signal to it.

Maintenance mode. Turn it on before you update a server: it silences emails, not checks. The outage is still recorded and shown on the screen. If it continues after the maintenance ends, you get an email; if it ended during maintenance, you do not.

A server goes down — one email. When several sites of the same server stop answering at once, you get one email listing them instead of one per site. To make that possible, the outage email waits five minutes — one check interval — for its neighbours. A site that comes back within those minutes is left out. Certificates, DNS and Job Guard still email right away. The email does not name the server: the name is stored only in your app.

Why the site was down. Every outage on the Availability screen has a "Show the server" button: what was happening on the server at that hour — samples, web-server errors, reboots, deploys. At the top is a short summary of what happened around the same time: "the whole server was not answering", "there was a deploy 7 minutes before the outage", "the monitoring warned the disk was running out of space". These are coincidences in time, not a proven cause, and times are counted from the moment the check noticed the outage: it notices after three failures in a row, roughly 10–15 minutes after the start.

Check from the server. While a check says "not answering", there is a "Check from the server" button under it: the app asks the monitoring to open the site's key addresses from the server itself and reads the web-server log for the last 15 minutes. Opens from inside — the site works, but requests from outside do not reach it: the network, a firewall or DNS. Does not open from inside either — the trouble is on the server. The app cannot reach the server at all — it is switched off or unreachable as a whole. The check needs key addresses (the Diagnostics screen); without them the app says so. It runs only from your computer: vpsFocus servers have no access to the monitoring on your server.

Server containers. The outage breakdown and the Diagnostics screen have a "Check containers" button: the app asks Docker over SSH which containers the server has, when each started, how many times it restarted and whether it was stopped for lack of memory. Pressed on an outage breakdown, it adds "a container started around the outage" to the summary at the top. Read-only: not a single file stays on the server, and the list goes nowhere. The monitoring itself has no access to Docker — this is safer for the server.

Status page

A public page at https://vpsfocus.xyz/status/<name>: whether your sites are working now and how they did over the last 90 days. Give the link to your clients or visitors — fewer “is it down?” questions. The page is built from external availability checks, so it is in the paid plan. Set it up in the app: “All servers” → “Status page”.

• What the page shows: the title you chose; for every site — the name you chose, its state now (“working”, “not responding”, “maintenance until 15:00”, “not being checked”) and a 90-day bar; the availability percentage; when it was updated. The page refreshes itself every minute.
• What the page never shows: the addresses and paths of your checks, port and DNS checks (they would reveal how the server is set up), your maintenance note, our menu, and cookies.
• First confirm that the domain is yours — a page cannot be created before that. The app shows a TXT record to add at your domain registrar or wherever your DNS is managed. Many panels ask only for the start of the name — _vpsfocus — and add the domain themselves; typing the full name gives an extra _vpsfocus.example.com.example.com. A new record takes a while to show up: if “Check” does not find it, wait 5–10 minutes. If the domain is connected under “Domain mail” through Cloudflare, the app adds the record itself — after showing exactly what it will write.
• Do not delete the record after it is checked. Once a week we check that the domain is still yours. If the record is gone, you get an email, and 7 days later the page stops showing the sites of that domain; put the record back and they come back. The deadline also appears in the app’s calendar.
• The percentage is not an availability guarantee. It counts only the time the site was checked, without maintenance windows. Grey on the bar means “vpsFocus did not check this site” — for example, the check was paused. If the page does not open at all, the problem is on our side, not with your site.
• If the plan ends, the page says “paused” instead of disappearing; it comes back with the plan. A deleted or renamed page does not free its address right away: for 90 days it points to the new address or stays yours.
• Search engines do not index the page: it is your page, not ours, and does not belong in search results under our domain.
• Do not pass yourself off as someone else. We remove a page that pretends to be another organisation — it will say “this status page has been removed”, and the app shows why. Until it is restored, it cannot be deleted, and new pages and changes are not available. Every page has a “Report abuse” link.

Domain mail

A site's domain gets a "Mail" tab. It turns on Cloudflare Email Routing for that domain and lets you add addresses — support@, say — that forward to an inbox you already use. It is free and needs no vpsFocus account: the app talks to Cloudflare directly, with a key that stays on this computer, and mail goes from Cloudflare straight to the inbox you chose, bypassing vpsFocus servers.

The domain needs to be delegated to Cloudflare's name servers, with Cloudflare serving its DNS in full — a partial (CNAME-only) setup cannot host Email Routing. Mail belongs to the domain, not to the site or the server: removing either from the app does not touch it, and shop.example.com and example.com share the same mail because they share the same domain.

First: the domain in Cloudflare

Mail can only be set up for a domain that is already connected to Cloudflare. If it is not there yet, start with that: in the app's Domain mail section press "Add a domain to Cloudflare", then "Connect a domain", and enter the name servers Cloudflare shows at your registrar. The domain becomes active within half an hour to a day — Cloudflare sends an email. Create the key after that.

Creating the key

In the app, open the Domain mail section (the "All servers" menu → "Settings") and press "Create a key in Cloudflare". It opens Cloudflare's own token page with everything already filled in — there is nothing to change there: press "Continue to summary" at the bottom, then "Create Token", copy the key with "Copy" and paste it into the app. The key is stored only in this computer's secure storage and is not sent to vpsFocus servers. If one Cloudflare account holds domains of different owners, keep in mind: the key sees the forwarding addresses of every domain in the account.

Turning mail on for a domain

Once connected, the Domain mail section lists every domain in the account with its mail state: waiting for Cloudflare, mail off, mail works. Click a domain to open its page: everything about mail — turning it on, addresses and the check — is in this one window. First the app reads the domain's DNS and answers with one of three things:

• Can turn it on. It shows what Cloudflare will add; you confirm and the domain is ready in a minute or two.
• Fix the records first. The usual case when the site already sends mail — order confirmations, say. The app shows what it will change: add Cloudflare to the SPF record without breaking it and, if there is one, delete the old mail record (MX). Once you confirm, it does this itself.
• The domain points to another mail server. If you receive mail on the domain (Google Workspace, Microsoft 365, your own server), the app changes nothing: turning routing on would take mail away from those inboxes. If you do not, tick the box and the app deletes the old record itself.

Creating an address is one form: a name and where to forward it. If that inbox has never received mail through this Cloudflare account before, Cloudflare sends it a confirmation link — the address is marked "waiting for confirmation" until it is clicked, then it starts working on its own.

Below the addresses is a "Check that mail arrives" block: "Write a test email" opens your mail app with an email to the new address ready to send. Send it preferably from another mailbox. The app cannot see your mailbox and cannot confirm delivery by itself: "Works" means Cloudflare accepted the setup, and whether the email arrived only shows in the mailbox.

Moving mail to another service later

The app does not manage that move — Email Routing forwards mail rather than hosting it, so there is no inbox to export. To switch providers by hand, start in Cloudflare under Email → Email Routing → Settings: Email Routing locks the MX, SPF and DKIM records it added, and the DNS page will not let you change them until you disable Email Routing for the domain or unlock its records there. Then remove whatever Email Routing records are left, point MX at the new provider, and replace Cloudflare's include in the SPF record with the one it asks for. Check mail delivery to and from the domain again once the new records have propagated.

Bots & AI

The server’s Bots & AI section shows who really visits the site: search engines, AI search bots, bots a person sends by asking an AI about a page, and bots that gather text to train neural networks. Analytics does not see them — it counts only people with a browser; this section counts from the web server’s logs. At the top is the answer to whether the site is visible to AI: “AI bots are coming”, “none yet”, “blocked in robots.txt” or “unknown”.

• Counters only. The monitoring keeps which bot, which site and how many times a day. It stores neither log lines, nor User-agent strings, nor visitor addresses, and the counters are not sent anywhere.
• “Called itself”, not “was”. A bot’s authenticity is not checked. If the log format does not record who came (the User-agent field), the screen says “unknown”, not “did not come”.
• A visit is not a promise. What a bot did with what it read cannot be seen in logs, and the screen does not promise the site will appear in AI answers. Sites behind Cloudflare do not see every bot: Cloudflare stops some.
• Scanners are shown as a number. If the site answered a scanner “200” for /.env or /.git, the screen sends you to Security, where the check tells you whether the file is still served.
• Robots the server refuses. If the server refuses a search or AI bot (codes 403, 429, 444) in more than half of its requests over a week, the screen says so: “is refused: 403, 120 of 140 requests” — what it means, where such a rule usually sits (a security plugin, a web server rule, a rate limiter) and a task for your AI assistant. A refusal on robots.txt comes first. We change nothing ourselves. Refusing training bots can be your own choice — they get a note only.
• “Bot stopped visiting”. A Cloudflare refusal never reaches the server’s logs. So the screen also tells you about a regular visitor that stopped coming: it came on 5 of 7 days and not once in the last 3. This is counted only if logs are kept for at least 10 days. There are no separate notifications about it — only the screen and a line in the weekly report.
• Cloudflare settings. If the domain is connected in Domain mail, the screen tells you right away whether Cloudflare blocks AI bots (the “Block AI bots” setting). This is read-only. Keys created earlier lack the Bot Management Read right — the screen suggests replacing the key; mail keeps working with the old key.
• Robot load. The robots’ share of requests and traffic over the chosen period, by kind: “robots — 62% of requests and 80% of traffic”. This is the load on the server itself: what Cloudflare served from its cache is not included. If the log format does not record response size, the traffic share is “unknown”.
• Ignoring robots.txt. Monitoring checks the addresses requested by search engines and training robots against the site’s robots.txt rules read by the latest SEO check: “GPTBot visits closed sections: 340 requests, for example /admin/”. Robots launched by a person’s question to an AI are not listed — their companies do not oblige them to follow robots.txt. The robot’s name is not verified. We block nothing: you can close a robot with a Cloudflare or web server rule — there is a task for your AI assistant for that.

Is the server exposed

The server’s Security section tells you in plain words what is open on the server and what the risk is: password and root login, databases reachable from outside, ports Docker opens past the firewall, the firewall itself, security updates not installed, a pending restart, how many times a password was guessed in the last day, whether the clock is kept accurate, how long site logs with visitor addresses are kept, whether any container has rights to the whole server, whether site backups are fresh (if the backup folder is set in the site profile on the Compliance screen), and whether the sites serve a .env file or a .git folder. Each item says what it means and how to close it.

• Read-only. The app reads the settings over SSH in one session; nothing on the server is changed and not a single file is left behind — not even the package lists are refreshed. The only traces are records in the server's system log: the SSH login, as with any login, and — if you log in as a user other than root — each command run through sudo (that is how sudo works). The monitoring is not needed: you can run the check right after adding the server. After the first successful install the app runs it by itself, in the same SSH session, and shows the result under the install; your sites are checked when you press the button on the Security screen.
• Nothing leaves. The result is not sent anywhere and is not saved to disk — it stays on screen while the app is open. The app asks your sites for .env and .git from your computer, the way a browser does; the contents are neither shown nor stored.
• “Could not check” is not “fine”. Without administrator rights (sudo without a password) some items are unavailable, and the screen says so. There is no green “the server is secure”: the check sees the server from the inside, and the bottom of the screen lists what it does not look at.

Compliance checklist

The "Compliance" section in a server's menu lists what laws and common sense expect from a website: cookies and trackers before the visitor agrees, legal notice and privacy policy, accessibility, site and server security. The same checklist is open on this website.

• Free and without an account: every item explains why it matters, how to check it yourself, what to give an AI and how to fix it, with a link to the rule. Country tags (EU, Germany, Austria, UK, Switzerland, USA, California) and topic tags, plus a site profile — where it operates, whether it sells online, has forms, a newsletter, an AI chatbot, visitor posts or its own payment form — hide what does not apply; the backup folder on the server can be set there too. Besides cookies and pages, the checklist covers shops (the withdrawal button, withdrawal terms, the order button, prices and discounts), reviews and visitor posts, AI chatbots, opting out of data sale in the US and scripts on the payment page.
• "Done" and "not applicable" marks with a comment, who marked it and when, and a progress bar at the top. They are kept on your server in /opt/vpsfocus/compliance.json, so the team sees one progress; without a connection to the server a mark is not saved.
• AI prompt — for each item, and the AI prompt button at the top builds one for everything shown: paste it into ChatGPT, Claude, Gemini or an AI code editor. If the assistant has a browser it opens the site itself and clicks nothing in the banner; if not, it asks you for what it needs.
• What the app checks itself: server items — from the Security check, accessibility — from the PageSpeed measurement. If you marked an item as done and a check later finds the problem again, "found again" appears next to the tick; the app never removes your tick.
• Paid — the check from the vpsFocus server. On request the site is opened from outside, like a visitor sees it: plain requests and a browser that clicks nothing in the consent banner. It finds cookies and trackers before consent, Google Fonts, embedded videos and maps, the banner, its reject button and a link to change the choice later, advertising that loads despite the "do not sell my data" signal (GPC — the home page is opened a second time with it), http content on https pages, session cookies without the Secure and HttpOnly flags, and lists a chat widget it found and third-party scripts to compare with the payment page, and checks TLS, the https redirect, headers, security.txt, SPF and DMARC, links to the legal notice and policy, the withdrawal button and withdrawal terms, the "Do Not Sell" link on the home page and an outdated link to the closed EU dispute platform. It opens the home page and a few pages linked from it, legal pages first; it never goes into the cart or checkout; the site's service files are not probed. The site address reaches us only at the moment of the check; the latest result is kept for "new / fixed" next time.
• These are technical checks, not legal advice. An item says what was found and points to the rule, but does not decide whether the site is lawful. "Could not check" is grey, not green.

Updates, backups, removal

• Monitoring updates. The "Update to version…" button is on the server's "Setup & install" screen, in the "Monitoring version" block under the "Monitoring on the server" summary. A new version is never downloaded on its own: the button first downloads it to your computer, then installs it on the server, and the whole process is shown with the same card as the install. You can leave the screen or even close the app — the update runs on the server by itself, and the next time you open this screen the app shows how it ended. Before anything changes, a database dump and a copy of the configs are taken. If the update goes wrong, both come back. With several servers, the "Updates available" block on the account screen has "Update" for each one, and "Update all" goes through them in turn: a server that is offline, busy with another copy of the app or already up to date is skipped, and the queue stops only if an update failed after the data copy. The queue lives while the app is open.
• Backups. "Download a backup" on the server's Backups screen saves the analytics database and the monitoring settings into an archive on your computer. The archive contains passwords — store it accordingly.
• A smaller copy. If an automatic database copy was made but holds less than half of the previous one, the monitoring sends a warning and shows “then → now” on the Backups screen. It is not an error: the database may have shrunk after old statistics were cleaned up. If you deleted nothing, make sure no data is missing.
• Removal. The collapsed "Install again or remove the server" block at the bottom of the "Setup & install" screen. Two different actions. "Remove from the app" drops the server from your app only. "Wipe the monitoring" removes the monitoring together with all the analytics it collected, and this cannot be undone.
• App updates. They arrive on their own and are checked against a signature. An unsigned update is refused.

Calendar

The calendar icon in the app's left strip sits above the account. It gathers the important dates of all your servers and sites in one place: when to renew a domain, when a certificate expires, when to pay for the VPS.

• Domain and certificate expiry dates land here by themselves — from every server with monitoring installed. The app reads them at most once every six hours (the monitoring checks them at the same pace) and when you press “Refresh”. If a server does not answer, the calendar keeps the previous dates and says when they were read. Your vpsFocus plan's end date appears too, if you are signed in.
• Everything else goes in as reminders: paying the hosting provider, subscriptions, your own tasks. A reminder can repeat (every month or year) and warns you a chosen number of days ahead. If a month has no such day, the reminder moves to its last day.
• Colour is a state: a dot on an event, a frame around a day in the month grid. Red — overdue or less than a week left, amber — time to prepare, grey — upcoming, dashed — done or past. Missed things do not disappear: an overdue event stays at the top until you mark it. The dot on the calendar icon lights up only when something needs attention.
• The timeline above the entries: one row per event, with a bar running from today to the due date. The solid part of the bar is the time when the calendar is already reminding you, and the days left are written on the right. Overdue items sit left of the “today” line. Switch between 30 days, 90 days and a year; click a row to jump to the entry.
• What you can do with an event: mark it “Done” (“Renew” for a domain or certificate), snooze it for 1, 3 or 7 days, hide an automatically found one. “Check now” asks the monitoring to check the domains again — that is how you see the renewal went through. If you pressed “Renew” but the server still sees the old date, the calendar says so plainly.
• Export: “Export .ics” saves a file that opens in Google Calendar, Apple Calendar and Outlook. There is no subscription by URL and no sync — the calendar is not sent to vpsFocus servers.

Reminders live on your computer, and reminders about a specific server live on that server, so the whole team sees them (see “Working as a team” below). There are no pop-up notifications: the calendar reminds you with a dot inside the app.

Share a result

When your site gets faster or a check comes back clean, a “Share” button appears next to the result. It draws a picture for social media: the main number, a short line, your site's domain and a small vpsFocus signature at the bottom.

• When the button shows up: a mobile speed score of 90 or more, or up by 15 points or more (ending at 50 or above) — “Performance”; all SEO checks passed, or five or more fixed since the last check — “SEO audit”; not a single broken link with at least 20 pages crawled — “Broken links”; the site up without downtime for 7 days in a row or more — the external check details in “Availability” (external checks are on the paid plan). If there is nothing to be proud of yet, or nothing has been checked, there is no button.
• What you can choose: the size — 1200 × 630 (X, LinkedIn, Telegram) or a 1080 × 1080 square; light or dark colours; whether to show the domain. The server's name and address never appear on the picture.
• What next: “Save picture” gives a PNG file, “Copy picture” puts it in the clipboard (where your system supports it), “Copy text” gives a ready-made post to go with it.
• The picture is drawn on your computer and is not sent anywhere until you post it yourself — not to vpsFocus's servers, not anywhere else. We don't count button presses.

AI assistant (MCP)

Your AI assistant — Codex, Cursor, VS Code or Claude Code — can read what the app shows and help you fix your site right in your code: “what is wrong with SEO on my site”, “why was the site down last night”, “which pages are slow”. The “MCP” item is in the All servers menu, under Settings.

• Read only. The assistant sees what you see on the screens: the SEO audit, broken links, speed, outages and what happened around them, errors, server health, deadlines, backups, analytics. It cannot start a check, change anything or install anything.
• You decide what it sees. Tick the kinds of data and the servers. Visitor analytics is off until you turn it on: it is data about people. A server you untick does not exist for the assistant.
• What it never gets: passwords, keys and tokens, notification channel addresses, visitor IP addresses and query strings from the logs.
• It works inside the app and answers only programs on this computer, with a key. Close the app and there is no one to answer. Nothing extra to install.
• Nothing goes through vpsFocus servers. Data goes from your server to the app — just as for the screens — and on to the assistant you connected. No account is needed, except for external uptime checks, which live in the account anyway.

How to connect

1. Open “MCP” and turn on “Allow AI to read vpsFocus data”.
2. In “Connect”, pick your assistant and press “Copy”. The text under it says where to paste: for Codex — ~/.codex/config.toml, for Cursor — ~/.cursor/mcp.json, for VS Code — the user mcp.json (the “MCP: Open User Configuration” command), for Claude Code — a terminal command.
3. Restart the assistant and ask it about your site.

The setup contains a key. Do not put it into a project file — it may end up in git — and do not send it to anyone. If the key leaked, or you simply want to disconnect every assistant at once, press “Issue a new key”. What the assistant asked and when is in “Request history” on the same screen; the answers themselves are not stored.

The assistant sees text from your site — page titles, paths, log lines. Strangers write some of it too, so treat the assistant's advice like any outside advice: look at what it suggests changing in your code.

Working as a team

Several people can work with the same server, each from their own copy of the app — with no shared account and no syncing through vpsFocus servers. Access is bounded by the thing you already use for it: SSH.

What it takes

• SSH access to the server for each person: root, or a user with passwordless sudo — the same thing provisioning needs. Anyone with that access can already read the monitoring's passwords on the server; the app grants no new rights. To revoke access, revoking SSH is enough.
• One app version across the team. An older copy cannot read the project list and settings from the server and overwrites them with its own, stale ones. The app notices the trace an older copy leaves and warns about it on the main screen.
• One vpsFocus account per team — but only if you use external availability checks, the one feature that needs an account at all. Installing, analytics, sites and domain mail all work without one, for any number of people.

How it works

A developer adds the server to their own copy of the app the normal way. If the monitoring is already installed, the app notices on its own and takes the passwords from the server — nothing needs reinstalling, and nothing on the server changes. From there they see what the person who installed the monitoring sees: analytics, projects, checks, errors, SEO.

Shared state lives on the server and is the same for everyone: the project list, key addresses, notification settings — mail, Telegram, the Slack, Discord and webhook addresses, maintenance mode — and the monitoring's passwords, plus calendar reminders about the server and its sites and the “done” marks on the server's events — a domain a colleague renewed will not stay red for you. One person's change is visible to the rest the next time they open the screen. A server reminder is saved straight to the server: without a connection to it, the change is refused rather than queued.

Personal state stays on each computer and never spreads across the team: your own activity log, the site database connections on the "Data" tab, the Cloudflare key for domain mail, the note of when you last pulled a backup, general calendar reminders not tied to a server, the “snooze” and “hide” marks, and the “MCP” settings with their key and request history.

Whoever saves last wins — but not everywhere the same way. Lists the screen reloads from the server fresh each time — measurement pages, log paths, key addresses — behave exactly like that: edits are rare, and the last one saved wins. The project list and notification settings are more careful: a change is applied on top of what is actually on the server the moment you save, not on top of what was open on your screen an hour ago. If a colleague changed a value you never touched, your save leaves it alone, and the screen tells you which values it left as they were.

Inviting a colleague

The simplest way is an invite code. The “Invite a colleague” button is in the top right corner of the app: on a server’s screens it opens that server’s invite, elsewhere it first asks which server to share. The same item is in the server menu’s “Server” group and under the installation result: the app prepares a message with a download link and the code, and you send it yourself — in a messenger or by email. One code, one server. Your colleague pastes the code into the “Server address” field on the “Add server” screen: the address, port and name fill in on their own, and all that's left is to sign in with their own SSH access.

• The code is not access to the server. It holds only the address, the SSH port, the server's name and its key fingerprint — no passwords, keys or monitoring tokens. Without their own login, your colleague cannot connect. It's better to set up a separate sign-in for them; if you share yours, send the login and password separately from the code.
• The server's key is checked against the invite. If the server answers with a different key, the app does not connect and does not add the server to the list; a different key can't be accepted on that screen — a new code is needed. Before signing in, the app shows in large type which address you are connecting to: a code from a stranger can lead to someone else's server.
• The code never passes through vpsFocus. The app builds it on your computer and you send it yourself; neither the address nor the name of the server reaches our server.
• You can invite people to a server where the monitoring is already installed. If an older version installed it, the app first asks you to update it: the old one doesn't give the server the shared ID that team work relies on.

Someone leaves the team

Revoking SSH is enough to stop someone connecting to the server — through the app or any other way. But part of the monitoring's settings is shared across the whole team rather than tied to one server: the outgoing mail password, the Telegram bot token, the Slack, Discord and webhook addresses, the Google key, the backup storage keys. Whoever leaves carries those in memory, so when someone leaves the team:

1. revoke their SSH access to the servers;
2. if they had their own sign-in to the vpsFocus account, change the account password and sign it out everywhere;
3. change the outgoing mail password, the bot token, the Google key and the backup storage keys, and create the Slack and Discord addresses anew (delete the old ones where you created them) — an ordinary settings save on any server in the team spreads the new values to the rest on its own.

Restoring a copy onto another VPS

Moving to a new server is an ordinary copy restore, as described above, plus moving external checks to the new server where the app offers to do it: to vpsFocus, the old and the new server are different servers.

Common problems

"No internet connection" or "Can't reach the server"

When it starts, the app checks that it can sign in to each of your servers. Nothing runs on the server itself — it only signs in. If the check takes longer than a second and a half, a window with the list of servers appears; you don't have to wait for it — "Don't wait" closes the window and the check finishes on its own.

• "No internet connection" — none of the servers answered, or Windows reports there is no network. Check your Wi-Fi or cable; if a VPN is on, try without it. The calendar and settings work offline too.
• "Can't reach the server" — your internet works, but the server doesn't answer: it is off or unreachable. Check it in your hosting panel.
• A grey dot next to a server in the list on the left — there is no connection to that server, or signing in failed; hover over it to see which. The other servers work as usual: one server that is off doesn't hold up the app.

If the network drops while you work, a "No internet connection" bar appears at the top. Whatever is already open stays available.

Why the data doesn't refresh by itself

The app remembers what it has loaded until you close it: you can switch to another screen and back instantly, without asking the server again. It asks the server again only when you press "Refresh" or change something yourself — add a site, save a setting, start a check. There are two exceptions: the server status dots in the list on the left refresh every five minutes, and the calendar checks domain and certificate dates with your servers every six hours — as often as the monitoring itself checks them.

Next to "Refresh" you can see when the data was fetched: "Fetched at 14:32". If the report has its own time — say, the SEO audit ran at night — it is shown separately: "Checked by the monitoring at 03:00 · fetched at 14:32". If a refresh fails, the earlier data stays on screen with an explanation of what happened above it.

The server already runs a web server

That is the normal case. The app does not change the settings of nginx, Apache or Caddy and does not take ports 80 and 443: the monitoring runs on a free port next to them. That port goes into the analytics code and updates do not change it — it is written into every site.

"sudo asks for a password"

Provisioning runs unattended and would hang on the prompt. Give the user passwordless sudo, or connect as root.

The certificate is not issued

First look at how yours is being issued.

• Over an A record (80 and 443 free): almost always the same cause — the record does not point at this server yet, or has not propagated. Check that the domain resolves to the server's address and try again.
• Over DNS-01 with a provider key (ports busy): check that the token is allowed to edit records in that exact zone. The token is stored on your server in the .env file, readable by root only, and is not sent to vpsFocus servers.
• Over the vpsFocus fallback server: make sure the _acme-challenge CNAME for your domain points at the name the app gave you. Until it propagates the challenge cannot pass.

None of this breaks the installation: the monitoring is already running by that step, the app says so — "the monitoring is running, no certificate yet" — and Caddy keeps trying on its own. Let's Encrypt limits how many attempts you get per week, so there is no need to restart the install dozens of times in a row.

"The server's key has changed"

The host key differs from the one remembered on the first connection. That happens when a server is rebuilt or reinstalled — and it is also exactly what an intercepted connection looks like. Do not continue until you know which one it is.

The app tells you right at startup and marks the server with a red dot. If you're sure the server is yours, open it, press "Check connection" and accept the new key.

Windows warns when installing

Installers are not signed with a developer certificate yet. The download page explains how to get past the warning.

"Confirm your email address"

Until the address is confirmed, everything that works through vpsFocus servers is unavailable: connecting sites to external checks and other paid features. Installing is not affected — the installation files are available to everyone, and the monitoring is installed without an account at all. The letter can be sent again from your account page here or from the account screen in the app.

The analytics panel does not answer

After a server reboot the containers need a moment to come up. If that does not help, open the server's "Setup & install" screen: it shows whether the monitoring is running and which version it is.

Did not find an answer

Write to support@vpsfocus.xyz: what you did, what the screen showed (a screenshot or the error text together with its “Technical detail”) and which system the server runs. Do not send passwords, keys or notification channel addresses — they are not needed for an answer.