Creating and managing sites

The site list#

Infrastructure > Websites opens on its All websites tab, which lists every website on every web server (the WordPress tab beside it is the WordPress estate, see WordPress sites): its domain and name, customer, server, runtime, status, Site check result, days left on its Certificate and Backups schedule. Filter by Customer, Server, Runtime, Status, Site check, Maintenance and Managed.

Sites created by Tenvara are managed and monitored from the start. Sites that were already in the server's configuration are Discovered: they are shown, and checked once someone chooses to monitor them (see Web servers), but operations are for managed sites only.

A found site you do not want listed at all can be ignored from its page (Ignore, with an optional reason): it leaves the site lists, counts and alerts for good, until someone presses Un-ignore. Forget only removes it until the next report.

A site's status is Active, Maintenance, Failing (it fails its site check), Provisioning while it is being made, or Failed if creating it went wrong.

Creating a site#

You need Infrastructure Manage and an adopted nginx server (or an IIS server for static and .NET sites).

1. Press Create site on Infrastructure > Websites or on the server's page.

2. Choose the Server.

3. Choose the Customer: whose site it is. A shared server can host several customers' sites.

4. Enter a Name, for example "Kestrel Physio".

5. Enter a Short name in lower case, used for the folder and the Linux user (for example kestrel-physio). It must start with a letter and be 2 to 30 characters.

6. Choose the Runtime:

   Runtime	What you get
   Static	Files served by nginx
   PHP	A PHP-FPM pool of its own
   Laravel	PHP, serving the public folder, with .env and storage kept across deploys
   WordPress	PHP, with WordPress installed and its own database
   Node.js	A Node.js service behind nginx
   Nextcloud	PHP with Nextcloud's documented nginx config (sync clients, CalDAV and CardDAV), 512 MB of memory and the functions its previews need

7. For PHP runtimes choose the PHP version; the server's installed versions are offered. For Node.js give a Node.js version (a major version such as 22 or an exact one such as 22.9.0; the server installs it if needed) and how it starts.

8. Enter the Domains, separated by spaces. The first is the primary. Point their DNS at the server before issuing a certificate.

9. Optionally set a Web root: a folder inside the release to serve, such as public or dist.

10. Optionally add Folders outside the site: folders the site's PHP may use besides its own, such as a data disk. They must exist; the site user is given access to them.

11. For WordPress, also give the Site title, Admin user (not admin, administrator or root) and Admin email. The admin password is generated on the server and shown on the site page once.

12. Press Create site.

The server creates a Linux user and group for the site, its folders, its PHP-FPM pool or Node.js service and an nginx vhost, and tests nginx before reloading it. Anything that fails is rolled back before the reload, so a bad site never takes the others down. Each Linux site runs apart from the others: its PHP-FPM pool or Node.js service runs with the site's own group, its home is closed to other sites, and nginx does not follow a link from one site into another's files. If the server does not have the acl package yet, it is installed first.

For Nextcloud and PHP apps that need more memory, longer requests or a data folder elsewhere, see Nextcloud, PHP apps and per-site PHP settings.

The site page#

Each site has a header with its status, Open site, the Check result (answering or not, the status and the time taken), the server, customer, runtime and last report, and these tabs:

• Overview
• Domains and TLS
• Database
• SFTP
• Deploy
• Backups
• Cron
• Settings (Linux sites): PHP settings, folders outside the site and the nginx include
• Logs
• WordPress (WordPress sites only)
• Files, DNS and Usage
• Operations: everything run on this site

The Overview tab shows the Site check (what it asks and expects, and how often) with the result for each domain, Access protection, On the server (short name, disk used, document root, configuration file, current release and when it was created), Maintenance mode, the Runtime with its PHP version, and Name and customer.

The site check#

A monitored site is checked every few minutes from its own server. By default any HTTP answer counts as answering, and a site with a home page expects a page. To check more, open Overview and click Check settings beside Site check.

1. Monitor switches checking and alerting on or off for this site.
2. Use the server's and the customer's defaults takes the settings from the layers above. Turn it off to set the site's own.
3. Pick a Template: Answers at all (any status on /), Home page (2xx or 3xx on /), API, any answer, API health path (200 on /health) or Custom.
4. Adjust what you need:
   • Path: the page asked for, from the site's own server with the site's domain.
   • Expected status: any, a status such as 200, a range such as 200-299 or classes such as 2xx-3xx, several with commas.
   • The page contains: text that must be in the answer.
   • JSON field and JSON field is: for an API, a field such as status or data.health, and the value it must have (empty for "is there").
   • Send a header and Header value: a request header, for an API that needs a key.
   • Ask with: GET, or HEAD for headers only (no text or JSON field then).
   • Every (minutes), Give up after (seconds) and whether A failure is a Warning or Critical.
5. Click Save.

A 401 from a password-protected site and a 503 from a site in maintenance still pass unless the check expects a particular status. An older agent that cannot check a rule (another path, HEAD, a header, text or a JSON field) leaves the site's result as unknown with Update the agent.

To change many sites at once, tick them in the server's Websites table and use Check settings.

Domains and certificates#

Open Domains and TLS.

Change domains#

1. Under Domains, type into Add domains and add them.
2. Use the primary button beside a domain to make it the Primary: checks, links and the certificate's name use it.
3. Remove domains you no longer need.
4. Press Save domains.

Up to 50 domains per site. Wildcards are not accepted. New domains need a certificate that covers them, so issue one once they are saved.

Issue or renew a certificate#

Certificates are issued over HTTP-01 with certbot on the server, so every domain's DNS must already point at the server, and the server needs an ACME contact email (set when adopting it).

1. Press Issue or renew.
2. Tick Renew even if it is not due only when you need it: certificate authorities limit how often the same names can be issued.
3. Confirm.

Every certificate also appears in Infrastructure > Certificates, with the source Website: see Every certificate in one list. Tenvara renews its own certificates from 30 days before they expire, once a day, and alerts you if a renewal fails. The private key never leaves the server.

Upload a certificate#

For a certificate bought elsewhere or issued by your own CA:

1. Press Upload.
2. Paste the Certificate chain in PEM form (BEGIN CERTIFICATE), the site's certificate first.
3. Paste the Private key in PEM form, without a passphrase.
4. Upload. The key goes to the server and is removed from Tenvara once installed.

Uploaded certificates are not renewed automatically; you are alerted before they expire.

Access protection#

Ask visitors for a password, let only some addresses in, or both. Useful for staging sites and previews. The ACME challenge path always stays open so certificates still renew.

1. On Overview, under Access protection, turn on Password (basic authentication) and enter a User name. The password is generated on the server when you save; reveal it once the change has finished.
2. Under Allowed addresses, list IP addresses or ranges such as 203.0.113.4 or 10.0.0.0/8. Empty lets everyone in.
3. Press Save protection.

Maintenance mode#

Turn Maintenance mode on and visitors get a 503 page while it is on. Access protection still applies. Turn it off again from the same place. A site in maintenance still passes its site check.

Changing the PHP version#

1. On Overview, under Runtime, choose a PHP version and press Switch.
2. Confirm Switch to PHP x.y.

The site gets a new PHP-FPM pool and the vhost points at it; nginx and PHP-FPM are tested before they reload, and the old pool is removed once the new one answers. The old version lets go of the site's socket before the new one starts, so the switch does not take other sites on that version down, and a failure puts the old pool back. Check the site afterwards: extensions differ between versions.

Changes are backed up first#

Every change that touches a site's files or its web server configuration (its web root, PHP or Node.js version, domains, access protection, and on Windows its IIS settings) backs the site's files up first, into the server's backup folder. The operation says so (Backed up first with the time), and the backup is listed on the site's Backups tab like any other. If the backup fails, nothing is changed; if the change fails after it, the settings are put back and the error names the backup to restore if you need the files back too.

Changing the web root to a folder that does not exist yet makes the folder inside the release, with the placeholder page in it, before the web server is pointed at it.

Name and customer#

Under Name and customer you can rename the site and change whose site it is. Shared servers host several customers' sites, and the customer decides where the site shows on customer pages and reports.

Deleting a site#

Administrators can delete a site from More actions on the site page:

1. Choose to delete the site.
2. Decide on Delete its files too. Otherwise they are kept in a deleted-sites folder on the server. Backups are not touched either way.
3. Decide on Drop its databases too.
4. Type the domain to confirm, then press Delete site (or Delete site and data).

For a managed site, the vhost, PHP pool or Node.js service, SFTP access, cron entries and its Linux user are removed from the server and the site stops answering. A site that was removed on the server by hand says Removed from the server outside Tenvara with the date, and its menu offers Remove from Tenvara: the record goes without anything being sent to the server, and its certificate checks go with it.

For a discovered site only the record in Tenvara is removed; nothing changes on the server, and the site comes back with the next report if it is still configured there.

Revealed passwords#

Passwords for databases, SFTP, basic authentication and WordPress are generated on the server and kept encrypted in Tenvara. Revealing one needs Infrastructure Manage and is written to the activity log.