Web servers
How web servers are found, choosing which of their sites are monitored, adopting a server so Tenvara can run site operations, and everything on the server page.
A web server in Tenvara is a machine running the agent with a web server on it. The agent's Web server role finds it, reports what it serves, and once an administrator adopts the server, runs a fixed catalogue of site operations on it: creating sites, certificates, databases, SFTP, cron, deploys, backups and WordPress updates. Nothing is ever a shell line built from what someone typed, apart from a cron entry's command and a deploy script, both of which run as the site's own user.
What each platform supports
| Linux with nginx (Ubuntu 24.04, Debian 12) | Linux with Apache | Windows with IIS | |
|---|---|---|---|
| Reported and checked (services, runtimes, sites, certificates, disks, databases, HTTPS checks) | Yes | Yes | Yes |
| Site operations | Yes | No: reported and checked only | Static and .NET sites |
Site operations write nginx configuration, so an Apache server is listed as "Apache: reported and checked only" and refuses operations. On Windows Server (2019 or later) sites are static or .NET, databases are SQL Server Express and MySQL side by side, sites get FTP as well as SFTP, and certificates come from an upload or from win-acme when it is installed. Each site has an IIS tab for its application pool, bindings, applications, rewrite rules and web.config. See Windows hosting: IIS, SQL Server and MySQL. PHP, Laravel, WordPress and Node.js sites run on Linux.
Sites on any adopted server can belong to a hosting account, so the customer manages them in the hosting panel. See The hosting panel, resellers and site owners.
The web server list
Infrastructure > Web servers (in the Servers and storage group) lists every machine the agent found serving websites, with its customer, Health, what it is Serving, the web server and version, number of Websites (and how many are failing), Certificates expiring, Fullest disk, whether it is Adopted and its Last report. Filter by Customer, Health, Serving, Web server and Adopted.
The Serving column says what each machine really serves, checked by the agent on the server and from the internet:
| Badge | Meaning |
|---|---|
| Public website | It serves real content and answers from the internet. |
| Serving (public check pending) | It serves real content; the check from the internet has not run yet. |
| Internal only | It serves real content, but nothing answers from the internet. |
| Default page only | Only the web server's own welcome page answers. |
| Installed but not serving | A management page, errors or nothing answers; hover the badge for why. |
Only public websites (and adopted servers) count as web hosting: the others raise no web alerts and are left out of the hosting figures. The Views picker has a view for each badge, such as Public websites and Internal only. See Public website or internal only.
The Adopted column reads:
- Adopted: operations can run.
- Not adopted: reported only, waiting for an administrator.
- Reported only: an Apache server, which is checked but takes no operations.
Ignoring a server you do not look after
A machine with a web server you never want here (a box another provider runs, a web server left on by accident) can be ignored instead of adopted. Press Ignore on the server page, or select servers in the list and ignore them together, and give a reason if you like. An ignored server leaves the web server lists, counts, certificates and alerts, and later reports do not bring it back. Turn on the list's Ignored switch to see ignored servers with who ignored them, when and why, and Un-ignore one to bring it back. The device itself is not affected. Ignoring needs Infrastructure Manage.
Adopting a server
Until a server is adopted, its agent refuses every operation except a refresh ("this server has not been adopted"). Adopting needs the Administrator role.
- Open the server from Infrastructure > Web servers. Filter the list by Adopted to find the ones still waiting.
- Press Adopt (the page shows "Adopt to run operations" while it is not adopted).
- Check the settings in the dialog:
- Backup folder: where site backups and database dumps are kept on the server. Leave it empty for the server's own default, which the dialog suggests:
/var/backups/tenvara-siteson Linux,C:\Backups\tenvara-siteson Windows. A Linux server takes an absolute path; a Windows server takes a folder with a drive letter or a network share, and the other kind of path is refused. - ACME contact email: given to the certificate authority for expiry notices. Needed before certificates can be issued.
- ACME directory: the certificate authority to use. Let's Encrypt by default.
- Backup folder: where site backups and database dumps are kept on the server. Leave it empty for the server's own default, which the dialog suggests:
- Confirm. The page shows "Waiting for the agent to pick this up" until the agent confirms, usually within a minute.
Existing sites stay exactly as they are. Sites Tenvara did not create are shown as Discovered: they are reported, and checked once you choose to monitor them, but never changed. Adopting a server opens the picker to choose which of its sites to monitor.
Releasing and removing a server
From More actions on the server page, administrators can:
- Release the server: the agent refuses operations again. Its sites keep running and are still reported and checked, but scheduled backups and certificate renewals stop. When no managed site is on the server, tick Ignore it as well in the dialog and press Release and ignore to do both in one step.
- Remove it from Tenvara: its sites, certificates, databases, backups and operations history are forgotten. Nothing is deleted on the server. While the agent still runs there, the server comes back, not adopted, with its next report.
The server page

The header shows health and what the server is Serving, Create site and Refresh (ask the agent for a fresh report now, which also checks every binding again), and the facts: Device, Customer, Web server, OS, Kernel, Managed by (when a hosting panel runs the server), who adopted it and Last report. Then:
- Serving: why the server has its badge, and what each binding answered with (host name, scheme and port, the answer, the status and the page title). A public website offers to monitor its sites here.
- Websites: every site on the server with its runtime, status, Site check, maintenance state and certificate. Choose sites to monitor opens the picker, and Open in Sites jumps to Infrastructure > Websites filtered to this server. Tick several sites to Monitor, Stop monitoring or change their Check settings together.
- Recent operations, with All operations.
- Run a command: the break-glass shell, described below.
- Databases: every database the server reports, with engine, tables and size.
- Services: the web server, each PHP-FPM version, MariaDB or MySQL, SSH, Node.js site services, fail2ban and certbot's timer (on Windows: IIS, SQL Server, MySQL and the FTP service), with their state. Services are found by the unit that really runs them, so a database that runs under another name is never reported as stopped, and a service that is not installed shows as Not installed without an alert. With Manage permission you can restart, reload or start a service; nginx and PHP-FPM configuration is tested first where the agent can. Requests in flight may fail for a second or two while a service restarts.
- Runtimes and tools: PHP versions, Node.js versions, the database engine, wp-cli, certbot, Composer and git (on Windows: the .NET versions and the database engines).
- Disks: each mount and how full it is.
- Settings: backup folder, ACME contact and directory, the server's public addresses, whether Run a command is on, and Notes for the team (what runs here, who to call, quirks).
- Ignored websites: sites found on the server that someone ignored, with Un-ignore.
More actions (the three dots in the header) has Settings, Choose sites to monitor, Site check defaults, All operations, Sites on this server, Release and Remove from Tenvara.
If parts of the last report failed (for example the agent could not read the databases), the page says which under "Parts of the last report failed".
Server settings
Open Settings on the server page to change the backup folder, the ACME contact email and directory, the Public IPv4 address and Public IPv6 address (the addresses the internet reaches this server on directly, if it has one), PHP limits for sites (the most memory, upload size and time a site may set, the functions a site may enable and whether sites may change OPcache; see Nextcloud, PHP apps and per-site PHP settings), the notes, and Allow Run a command on this server. Only administrators change the backup folder, the ACME account and Run a command.
The Settings card shows the backup folder the server really uses, as the agent reports it, marked (default) when nobody chose one, and what it is: local copies kept on this server before changes, not off-site backups. Under it, it says whether the device's own backup covers that folder (on Windows, its drive or a folder above it; a share is never in the device's backup), with a link to the device page. See Deploys and site backups.
Servers a hosting panel manages
Tenvara recognises servers run by DirectAdmin, cPanel, Plesk and CloudPanel, and the server page says Managed by with the panel's name. Services are judged by the systemd unit that really runs, so a panel's own names for its database, Apache or PHP-FPM units are read correctly, optional includes a panel writes only when a feature is on are not listed as configuration errors, and the databases are read with the panel's own database administrator login, which the agent reads on the server and never sends.
Run a command (break-glass)
Some fixes need a shell: installing a package, changing a firewall rule. Run a command lets administrators run any shell command on the server as root, from its page. It is off on every server by default.
- An administrator opens the server's Settings and turns on Allow Run a command on this server.
- In Run a command, enter the Command (for example
systemctl status nginx --no-pager) and a Timeout (seconds). - Run it. The output streams back to the page.
Commands run through bash as root. The command, who ran it and its output go to the activity log. Turn the switch off again when you are done.
Warning: Run a command is root on a customer's server from the browser. Keep it off unless a fix needs it.
Choosing which sites are monitored
A server often answers for more names than anyone wants watched: API hosts and bindings whose home page is meant to answer 403 or 404, old names, test sites. So sites found on a server are listed but never checked or alerted on until someone chooses them. Sites Tenvara created are monitored from the start.
While a server has found sites nobody has chosen yet, its page says so (for example 1 site found, not monitored yet), without counting against its health.
- On the server page, click Choose sites to monitor.
- Search, and tick the sites to monitor. Each says what its home page answered, for example Home page answers 200 or / answers 403.
- Click Monitor all with a home page to tick every site whose home page answers with a page.
- Click Monitor with the number of sites. Sites you leave unticked are not monitored. A found site you never want listed can be ignored from its own page: it then leaves the site lists, counts and alerts, and later reports do not bring it back (Forget only removes it until the next report).

How sites are checked
The agent asks the server itself for each monitored site, using the site's domain, so DNS and redirects prove nothing either way. By default any HTTP answer counts as answering: a 401 from a password-protected site, a 403 from an API's root and a 503 from a site in maintenance all pass. A site is not answering only when nothing is listening, the connection times out, the TLS handshake fails, its certificate has expired, or what answers is not HTTP. The check records the status code, the time taken and the days left on the certificate.
Each site's check can expect more: a path, a status, a word on the page, a JSON field or a request header. See Creating and managing sites. The site shows why it passed or failed in plain words, for example Answered HTTP 403 in 41 ms or Nothing is listening: the connection was refused.
A monitored site that fails its check twice in a row raises an alert: is not answering when nothing answered, or failed its check when it answered but broke a rule. A server that is not adopted only ever warns.
Site check defaults
Settings for site checks come in layers, so you set them once:
- Web site checks in Settings > Infrastructure: the path, the status to expect, how to ask, how often, when to give up and how serious a failure is, for every customer or per customer.
- Site check defaults in the server's More actions menu: the same for the monitored sites on this server. Empty fields use the customer's settings.
- The site's own Check settings.
Related
Was this page helpful?
Thanks for the feedback.