docs: add Email section — client setup + Baruwa retirement notice

Replaces the three Outlook 2016 articles (WHMCS 2, 3, 9 — ~62k views) with one client-agnostic setup guide. Outlook 2016 went end of life in October 2025, and the two archiving articles documented a feature the current Outlook doesn't have. Server settings are taken from the live autoconfig endpoint rather than the old articles: IMAP 993/SSL, POP3 995/SSL, SMTP 587/STARTTLS, username is the full address. cPanel settings verified against cpanel01. Adds a Baruwa retirement notice covering the move to Proxmox Mail Gateway in November 2026. Deliberately frames this as a platform change rather than describing our current outbound filtering posture — see the PR discussion. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: add cPanel section; drop the outbound-filtering page
2026-08-01 14:51:09 -07:00 · 2026-08-01 14:47:44 -07:00 · 2026-08-01 14:36:30 -07:00 · 2026-06-29 01:31:02 +00:00 · 2026-06-29 01:30:55 +00:00 · 2026-06-28 18:29:33 -07:00
58 changed files with 2897 additions and 237 deletions
@@ -30,3 +30,6 @@ GEMINI.md

 # local-only screenshot creds
 tools/screenshots/.env
+
+# Admin capture-script discovery artifacts (scratch only)
+tools/screenshots/_admin-*-links.json
@@ -7,6 +7,23 @@ import { fileURLToPath } from 'node:url';
 // https://astro.build/config
 export default defineConfig({
  site: 'https://kb.anhonesthost.com',
+  // Send section-only URLs to the first article in that section. Without these,
+  // hitting e.g. /whp/admin/ would render the Apache directory listing because
+  // there is no index.html in that folder.
+  redirects: {
+    '/whp/': '/whp/getting-started/welcome/',
+    '/whp/getting-started/': '/whp/getting-started/welcome/',
+    '/whp/how-to/': '/whp/how-to/add-a-domain/',
+    '/whp/site-builder/': '/whp/site-builder/overview/',
+    '/whp/local-dev/': '/whp/local-dev/overview/',
+    '/whp/reference/': '/whp/reference/service-hostnames/',
+    '/whp/add-ons/': '/whp/add-ons/overview/',
+    '/whp/admin/': '/whp/admin/overview/',
+    '/domains/': '/domains/transferring-a-domain-to-us/',
+    '/support/': '/support/remote-support/',
+    '/cpanel/': '/cpanel/nameservers/',
+    '/email/': '/email/set-up-your-email-client/',
+  },
  vite: {
    resolve: {
      alias: {
@@ -24,6 +41,9 @@ export default defineConfig({
        // Inline-SVG brand mark + "Knowledge Base" label.
        // Inlining lets the SVG's currentColor follow the active theme.
        SiteTitle: './src/components/SiteTitle.astro',
+        // Wraps Starlight's default <Head> to add a click-to-zoom lightbox
+        // (medium-zoom) that targets article content images.
+        Head: './src/components/Head.astro',
      },
      customCss: [
        '@fontsource-variable/inter',
@@ -50,6 +70,10 @@ export default defineConfig({
              badge: { text: 'Beta', variant: 'tip' },
              items: [{ autogenerate: { directory: 'whp/site-builder' } }],
            },
+            {
+              label: 'Local development',
+              items: [{ autogenerate: { directory: 'whp/local-dev' } }],
+            },
            {
              label: 'Reference',
              items: [{ autogenerate: { directory: 'whp/reference' } }],
@@ -60,11 +84,27 @@ export default defineConfig({
            },
            {
              label: 'Admin',
-              badge: { text: 'Draft', variant: 'caution' },
+              // badge removed once content was verified against the real UI
              items: [{ autogenerate: { directory: 'whp/admin' } }],
            },
          ],
        },
+        {
+          label: 'cPanel hosting',
+          items: [{ autogenerate: { directory: 'cpanel' } }],
+        },
+        {
+          label: 'Domains',
+          items: [{ autogenerate: { directory: 'domains' } }],
+        },
+        {
+          label: 'Email',
+          items: [{ autogenerate: { directory: 'email' } }],
+        },
+        {
+          label: 'Support',
+          items: [{ autogenerate: { directory: 'support' } }],
+        },
        // Future products only appear once they have content.
      ],
      pagefind: true,
@@ -13,6 +13,7 @@
        "@fontsource-variable/inter": "^5.2.8",
        "@fontsource-variable/jetbrains-mono": "^5.2.8",
        "astro": "^6.3.1",
+        "medium-zoom": "^1.1.0",
        "sharp": "^0.34.5"
      },
      "devDependencies": {
@@ -4359,6 +4360,12 @@
      "integrity": "sha512-9Yubnt3e8A0OKwxYSXyhLymGW4sCufcLG6VdiDdUGVkPhpqLxlvP5vl1983gQjJl3tqbrM731mjaZaP68AgosQ==",
      "license": "CC0-1.0"
    },
+    "node_modules/medium-zoom": {
+      "version": "1.1.0",
+      "resolved": "https://registry.npmjs.org/medium-zoom/-/medium-zoom-1.1.0.tgz",
+      "integrity": "sha512-ewyDsp7k4InCUp3jRmwHBRFGyjBimKps/AJLjRSox+2q/2H4p/PNpQf+pwONWlJiOudkBXtbdmVbFjqyybfTmQ==",
+      "license": "MIT"
+    },
    "node_modules/micromark": {
      "version": "4.0.2",
      "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.2.tgz",
@@ -17,6 +17,7 @@
    "@fontsource-variable/inter": "^5.2.8",
    "@fontsource-variable/jetbrains-mono": "^5.2.8",
    "astro": "^6.3.1",
+    "medium-zoom": "^1.1.0",
    "sharp": "^0.34.5"
  },
  "devDependencies": {
@@ -0,0 +1,15 @@
+# Static-HTML site hardening for kb.anhonesthost.com.
+# Lands in dist/ at build time and is uploaded with the rest of the site.
+
+# Never expose a directory listing to visitors.
+Options -Indexes
+
+# Astro emits both /path/ (with index.html) and /path.html for every route.
+# Default to the trailing-slash form; Apache MultiViews can sometimes serve
+# /path.html for /path/, which Pagefind doesn't index — disable it.
+Options -MultiViews
+
+# Send anything that doesn't resolve to a file to /404.html.
+# Starlight builds a real 404 page; this just makes Apache serve it.
+ErrorDocument 404 /404.html
+ErrorDocument 403 /404.html
@@ -0,0 +1,34 @@
+---
+import Default from '@astrojs/starlight/components/Head.astro';
+---
+
+<Default><slot /></Default>
+
+<script>
+  // Lightbox: click-to-zoom on article images. Loaded once per page; auto-reattaches
+  // after Starlight client-side navigation.
+  import mediumZoom from 'medium-zoom';
+  import 'medium-zoom/dist/style.css';
+
+  const SELECTOR = '.sl-markdown-content img:not(.no-zoom)';
+  let zoom: ReturnType<typeof mediumZoom> | null = null;
+
+  function refresh() {
+    if (!zoom) {
+      zoom = mediumZoom(SELECTOR, {
+        background: 'rgba(10, 22, 40, 0.92)',
+        margin: 32,
+      });
+    } else {
+      zoom.detach();
+      zoom.attach(SELECTOR);
+    }
+  }
+
+  if (document.readyState === 'loading') {
+    document.addEventListener('DOMContentLoaded', refresh, { once: true });
+  } else {
+    refresh();
+  }
+  document.addEventListener('astro:after-swap', refresh);
+</script>
@@ -0,0 +1,17 @@
+---
+title: Page not found
+description: That URL doesn't exist on our knowledge base.
+template: splash
+editUrl: false
+hero:
+  title: '404'
+  tagline: That URL doesn't exist on our knowledge base.
+  actions:
+    - text: Go to the knowledge base home
+      link: /
+      icon: right-arrow
+      variant: primary
+    - text: WHP getting started
+      link: /whp/getting-started/welcome/
+      variant: secondary
+---
@@ -0,0 +1,67 @@
+---
+title: Why is my site getting a 403 error?
+description: A 403 Forbidden on cPanel hosting is almost always file permissions or file ownership. Here's how to check and fix both.
+sidebar:
+  order: 3
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+A **403 Forbidden** means the web server found your file but refused to serve it. On our cPanel servers that's nearly always one of two things: permissions that are wrong, or files owned by the wrong user.
+
+We run **suEXEC**, which makes your site's code run as *your* account rather than a shared web-server user. That's a security benefit — one account can't read another's files — but it does mean the server is strict about ownership and permissions.
+
+## The correct values
+
+| Item | Permissions |
+| --- | --- |
+| Folders | `755` |
+| Files | `644` |
+
+Anything **more permissive** (a folder at `777`, a file at `666`) is refused by suEXEC. This surprises people, because loosening permissions is the instinctive fix for a permissions error — here it makes things worse, and it's a genuine security risk.
+
+## Fixing it in cPanel
+
+The File Manager handles this without needing a terminal:
+
+<Steps>
+
+1. Sign in to cPanel and open **File Manager**.
+
+2. Navigate to the site's folder. For your primary domain that's normally `public_html`.
+
+3. Select the folder or file, then click **Permissions** in the toolbar.
+
+4. Set folders to `755` and files to `644`. To apply to everything beneath a folder at once, tick the **recurse into subdirectories** option and choose whether it applies to files or folders — you'll need one pass for each, since they take different values.
+
+</Steps>
+
+## When ownership is the problem
+
+Permissions are only half of it. Files also have to be owned by your account.
+
+- **Uploaded over FTP or SFTP?** Ownership is almost certainly fine — the files were created as you.
+- **Pulled the site down over SSH** with `git clone`, `wget`, `curl`, or unpacked an archive as another user? Ownership may be wrong, and no amount of `chmod` will fix that. The files need `chown` back to your account.
+
+If you suspect ownership, [open a ticket](https://secure.anhonesthost.com/submitticket.php) — it's a one-command fix from our side and safer than guessing.
+
+<Aside type="caution">
+  Be careful with recursive commands over SSH. A `chmod -R 777` or a `chown` aimed at the wrong path can break your whole account, and in the case of `777` will leave the site returning 403 anyway. If you aren't confident, ask us.
+</Aside>
+
+## If permissions and ownership are both correct
+
+Other causes of a 403:
+
+- **No index file.** A folder with no `index.html` or `index.php`, on a server with directory listing disabled, returns 403.
+- **An `.htaccess` rule** denying access — either one you added, or one a security plugin wrote.
+- **A security plugin or firewall** blocking your IP after failed logins. Try from a different network or your phone on mobile data; if that works, it's an IP block.
+
+## Related
+
+- [Get your free SSL certificate](/cpanel/free-ssl-certificate/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,58 @@
+---
+title: Get your free SSL certificate
+description: Every cPanel account includes free Let's Encrypt certificates through AutoSSL. Here's what has to be in place and what to do if one doesn't issue.
+sidebar:
+  order: 2
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+Your cPanel hosting includes free SSL certificates from **Let's Encrypt**, issued automatically by cPanel's AutoSSL service. There's nothing to buy and nothing to install by hand.
+
+## What has to be true first
+
+AutoSSL can only issue a certificate once both of these are in place:
+
+<Steps>
+
+1. **The domain is added to your cPanel account** — as the primary domain, an addon domain, or a subdomain.
+
+2. **DNS points at our server.** Let's Encrypt validates a certificate by fetching a file from wherever the domain currently resolves. If it still points at your old host, validation fails and no certificate is issued.
+
+</Steps>
+
+Check where a domain currently resolves at [whatsmydns.net](https://www.whatsmydns.net/).
+
+## When it issues
+
+AutoSSL runs on a schedule — **once every 24 hours**. So after adding a domain and pointing DNS at us, a certificate normally appears within a day without you doing anything.
+
+Renewals are automatic too. Let's Encrypt certificates are valid for 90 days and AutoSSL renews them well before expiry, so a working site stays working.
+
+<Aside type="tip">
+  Need it sooner than the next daily run? Confirm DNS is pointing at us, then [open a ticket](https://secure.anhonesthost.com/submitticket.php) — we can trigger AutoSSL by hand and usually have the certificate in place shortly after.
+</Aside>
+
+## If a certificate doesn't appear
+
+Work through these in order — the first two cover most cases:
+
+- **DNS isn't pointing here yet.** The most common cause by far. Verify at whatsmydns.net that the domain resolves to our server's IP.
+- **It hasn't been 24 hours.** Give the scheduled run a chance before assuming something is broken.
+- **The domain isn't actually in your account.** Check cPanel → **Domains**. A domain you own but haven't added is invisible to AutoSSL.
+- **A redirect is intercepting validation.** Forced redirects — especially domain-wide ones in `.htaccess` — can stop Let's Encrypt from reaching the validation file.
+- **CAA records are blocking issuance.** If your DNS has a CAA record naming a different certificate authority, Let's Encrypt is refused. It must permit `letsencrypt.org`.
+
+## Making your site actually use it
+
+An issued certificate doesn't automatically mean visitors get HTTPS. Once it's in place, make sure your site loads over `https://` and redirects visitors from `http://`. In WordPress, that's usually setting both the **WordPress Address** and **Site Address** to the `https://` version under **Settings → General**.
+
+## Related
+
+- [What are my nameservers?](/cpanel/nameservers/)
+- [Why is my site getting a 403 error?](/cpanel/fix-a-403-error/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,49 @@
+---
+title: What are my nameservers?
+description: The nameservers to set at your registrar so your domain points at your cPanel hosting with us.
+sidebar:
+  order: 1
+---
+
+import { Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+Nameservers tell the internet which company is in charge of your domain's DNS. To use your hosting with us, set these at whichever registrar your domain is registered with.
+
+## Shared and reseller hosting (cPanel01)
+
+```text
+ns1.cpanel01.cloud-hosting.io
+ns2.cpanel01.cloud-hosting.io
+```
+
+Both shared and reseller accounts on cPanel01 use the same pair.
+
+<Aside type="note">
+  **On WHP instead?** WHP servers each have their own nameservers, so there's no single pair to publish here. Yours are shown in WHP on the **Dashboard** page under **Server Information** — see [Add a domain](/whp/how-to/add-a-domain/).
+</Aside>
+
+## Setting them
+
+Nameservers are changed at your **registrar** (whoever you bought the domain from), not in cPanel. Look for a section called *Nameservers*, *DNS*, or *Domain settings*, choose the "custom nameservers" option, and enter both values above.
+
+If your domain is registered with us, tell us the change you need and we'll make it for you.
+
+## How long does it take?
+
+Nameserver changes propagate across the internet gradually — usually within a few hours, occasionally up to 48. You can watch progress at [whatsmydns.net](https://www.whatsmydns.net/).
+
+During that window some visitors reach the new server while others still reach the old one. That's expected, and it's why we recommend leaving your old hosting active until propagation finishes.
+
+<Aside type="caution">
+  Changing nameservers moves **all** of your DNS to us — website, email, and anything else. If your email is hosted somewhere other than your website, tell us before you switch so we can recreate those mail records here first. Otherwise mail delivery stops when the change takes effect.
+</Aside>
+
+## Related
+
+- [Flush your DNS cache](/domains/flush-your-dns-cache/) — if you still see the old site after propagation.
+- [Transferring a domain to us](/domains/transferring-a-domain-to-us/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,74 @@
+---
+title: Send WordPress email from your own domain
+description: Stop WordPress sending as user@server and send from an address on your domain instead, using an SMTP plugin and a real mailbox.
+sidebar:
+  order: 4
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+If your WordPress site sends mail — contact forms, order confirmations, password resets — you may notice it arrives from something like `user@host.server-host.tld` rather than your own domain.
+
+That's deliberate. PHP's built-in mail function is configured to send as the account that owns the site, which makes it much harder for a compromised script to forge mail as someone else. The side effect is unbranded — and often poorly delivered — email.
+
+The fix is to send through a real mailbox on your domain using SMTP.
+
+<Aside type="tip">
+  This also improves **deliverability**. Mail sent through an authenticated mailbox on your domain passes SPF and DKIM checks; mail sent by PHP as `user@server` frequently doesn't, and lands in spam.
+</Aside>
+
+## Step 1 — Create a mailbox to send from
+
+<Steps>
+
+1. In cPanel, open **Email Accounts** under the **Email** section.
+
+2. Create an account for the site to send as — `noreply@yourdomain.com` is the usual choice.
+
+3. Use the **password generator** and copy the password somewhere temporarily — you'll need it in a moment, and you won't be shown it again.
+
+4. Set a **mailbox quota**. People reply to `noreply` addresses regardless of the name, and without a quota those replies accumulate against your hosting space indefinitely.
+
+</Steps>
+
+## Step 2 — Install an SMTP plugin
+
+WordPress needs a plugin to route mail through SMTP instead of PHP. Any of the well-maintained ones work:
+
+- [WP Mail SMTP](https://wordpress.org/plugins/wp-mail-smtp/)
+- [Easy WP SMTP](https://wordpress.org/plugins/easy-wp-smtp/)
+- [Post SMTP](https://wordpress.org/plugins/post-smtp/)
+
+## Step 3 — Configure it
+
+In the plugin's settings, choose the **Other SMTP** / custom option and enter:
+
+| Setting | Value |
+| --- | --- |
+| **SMTP host** | Your server's hostname (for example `cpanel01.cloud-hosting.io`) |
+| **Encryption** | TLS |
+| **Port** | `587` |
+| **Authentication** | On |
+| **Username** | The **full** email address — `noreply@yourdomain.com`, not `noreply` |
+| **Password** | The password you generated |
+| **From address** | The same mailbox address |
+
+<Aside type="caution">
+  Use port **587 with TLS**, or **465 with SSL** if your plugin prefers implicit TLS. Don't use port **25** without encryption — it sends your mailbox password across the network in the clear, and many networks block it outright.
+</Aside>
+
+Two details that account for most failures: the username has to be the **whole** address, and the **From** address must match the mailbox you authenticated as. A mismatch gets rejected or treated as spoofing.
+
+## Step 4 — Send a test
+
+Every one of these plugins has a test-email feature. Use it before assuming it works, and send to an address at a different provider (Gmail, Outlook) rather than another mailbox on your own domain — that exercises the path real recipients take.
+
+## Related
+
+- [What are my nameservers?](/cpanel/nameservers/)
+- **On WHP?** See [Create an email account](/whp/how-to/create-an-email-account/) — the mailbox part differs, the plugin setup is the same.
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,80 @@
+---
+title: Flush your DNS cache
+description: Your site moved or its DNS changed, but your computer still loads the old version? Clear the DNS cache your device has saved locally.
+sidebar:
+  order: 2
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+When you visit a site, your computer saves ("caches") the answer to *which server is this domain on?* so it doesn't have to ask again every time. That's normally invisible and helpful — but right after a domain moves to a new server or its DNS records change, your device can keep using the old answer and show you the old site.
+
+Devices are supposed to re-check after a short while, but some record lifetimes stretch to hours or even days. Clearing the cache by hand skips the wait.
+
+## First, confirm it's actually your computer
+
+Before changing anything locally, check whether the new DNS has actually gone out to the world. Look your domain up at [whatsmydns.net](https://www.whatsmydns.net/) — it queries servers in many countries at once.
+
+- **Most locations show the new value** — the change has propagated, and a stale local cache is the likely culprit. Continue below.
+- **Most locations still show the old value** — the change hasn't propagated yet. Flushing your own cache won't help; give it time.
+
+<Aside type="tip">
+  A quick sanity check: open the site in a **private / incognito window**, or on your phone using mobile data instead of Wi-Fi. If it looks correct there, the problem is local to your computer.
+</Aside>
+
+## Windows
+
+<Steps>
+
+1. Press the **Windows key**, type `Command Prompt`, and open it.
+
+2. Type this and press **Enter**:
+
+   ```text
+   ipconfig /flushdns
+   ```
+
+3. You should see *"Successfully flushed the DNS Resolver Cache."*
+
+</Steps>
+
+## macOS
+
+<Steps>
+
+1. Open **Terminal** (in **Applications → Utilities**, or press `Cmd` + `Space` and search for "Terminal").
+
+2. Type this and press **Enter**:
+
+   ```bash
+   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
+   ```
+
+3. Enter your administrator password when prompted, then press **Enter**. Nothing is printed when it works — no news is good news.
+
+</Steps>
+
+<Aside type="note">
+  Both commands matter on macOS: the first clears the lookup cache, the second restarts the service that answers DNS queries. Running only the first often appears to do nothing.
+</Aside>
+
+## Still seeing the old site?
+
+Your computer isn't the only thing that caches DNS. Work outward:
+
+- **Your browser** keeps its own cache. Do a hard refresh (`Ctrl` + `Shift` + `R`, or `Cmd` + `Shift` + `R` on a Mac) or try a private window.
+- **Your router** caches DNS too. Restarting it clears that.
+- **Your internet provider's resolvers** cache as well, and you can't clear those — they expire on their own schedule. If everything else is clean, this is usually what's left. It typically resolves within a few hours.
+
+If it's still wrong well after the record's lifetime should have expired, it may not be a caching problem at all — get in touch and we'll look at the actual DNS records.
+
+## Related
+
+- [Manage DNS records](/whp/how-to/manage-dns-records/)
+- [Add a domain](/whp/how-to/add-a-domain/)
+- [Clear your site's cache](/whp/how-to/clear-your-cache/) — for when *content* is stale rather than DNS.
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,60 @@
+---
+title: Transferring a domain to us
+description: What happens after you start a domain transfer — the confirmation emails, how long it takes, and the nameserver check to do afterwards.
+sidebar:
+  order: 1
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+You've started a domain transfer to us — here's what happens next, and the one thing worth checking once it lands.
+
+## Before the transfer will go through
+
+Your current registrar has to let the domain go first. At the registrar you're leaving, make sure you've:
+
+- **Unlocked the domain.** Registrars set a transfer lock by default to prevent unauthorised moves.
+- **Turned off WHOIS / domain privacy.** Privacy services can hide the administrative address the confirmation email needs to reach.
+- **Got the EPP code** (sometimes called the auth code or transfer key). Your registrar provides this, usually by email or in the domain's settings.
+
+<Aside type="caution">
+  Domains can't be transferred within **60 days** of being registered, or within 60 days of a previous transfer. That's an ICANN rule, not a registrar policy — nobody can waive it.
+</Aside>
+
+## Confirming the transfer
+
+<Steps>
+
+1. **Watch for confirmation emails.** You'll get one or both of:
+
+   - a message from **your previous registrar**, confirming the domain is moving away from them;
+   - a message from **NameCheap**, who we use to resell domains, confirming it's moving to our account.
+
+   They go to the domain's registered contact address — which may not be the address you use with us. If nothing arrives, check that address and its spam folder.
+
+2. **Click the confirmation link** in the email. Nothing moves until you do; an unconfirmed transfer just sits until it expires.
+
+3. **Wait for it to complete.** Once confirmed, the transfer usually finishes in **1 to 12 hours**, depending on how quickly the losing registrar releases it. Your account page updates to reflect the domain once it's done.
+
+</Steps>
+
+## After it completes: check your nameservers
+
+This is the step people miss. Some registrars — **GoDaddy** most notably — reset a domain's nameservers when they release it. If that happens, the domain transfers to us successfully but still points at the old host, so your site or email can appear to break for no obvious reason.
+
+Once the transfer shows as complete, confirm the domain's nameservers match the ones for your hosting. If you're on WHP, your server's nameservers are listed on the **Dashboard** page under **Server Information** — see [Add a domain](/whp/how-to/add-a-domain/) for where to set them.
+
+<Aside type="tip">
+  A transfer moves *registration*, not *hosting*. Your site's files and email stay wherever they already live. If you're also moving hosting to us, that's a separate step — ask us and we'll help sequence the two so nothing goes dark.
+</Aside>
+
+## Related
+
+- [Add a domain](/whp/how-to/add-a-domain/)
+- [Manage DNS records](/whp/how-to/manage-dns-records/)
+- [Flush your DNS cache](/domains/flush-your-dns-cache/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,91 @@
+---
+title: Set up your email
+description: Connect Outlook, Apple Mail, Thunderbird, or your phone to your mailbox — with the server settings for both WHP and cPanel hosting.
+sidebar:
+  order: 1
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+You can read your mail in any standard email app. Most will configure themselves once you enter your address and password — and if yours doesn't, the settings are below.
+
+<Aside type="tip">
+  **Just want to check your mail?** You don't need to set anything up. Webmail works in any browser with no configuration — ask us for your webmail address if you don't have it.
+</Aside>
+
+## Let your app configure itself
+
+Try this first. It works in most modern clients, including Outlook, Apple Mail, and the mail apps on iOS and Android.
+
+<Steps>
+
+1. Add a new account in your email app.
+
+2. Enter your **full email address** (`you@yourdomain.com`) and its password.
+
+3. Choose **Next** or **Sign in** and let the app look up the settings.
+
+</Steps>
+
+If the app finds everything, you're done. If it asks for server details, use the table below.
+
+## Server settings
+
+Use your **full email address** as the username — not just the part before the `@`. That single detail accounts for most setup failures.
+
+### WHP hosting
+
+| Setting | Value |
+| --- | --- |
+| **Incoming (IMAP)** | `mail01.cloud-hosting.io`, port **993**, SSL/TLS |
+| **Incoming (POP3)** | `mail01.cloud-hosting.io`, port **995**, SSL/TLS |
+| **Outgoing (SMTP)** | `mail01.cloud-hosting.io`, port **587**, STARTTLS |
+| **Username** | Your full email address |
+| **Authentication** | Required, for outgoing as well as incoming |
+
+<Aside type="note">
+  `mail01` is an example. Your server's mail hostname is shown in WHP on the **Dashboard** page under **Server Information**, and the **Email** page has a **Setup Instructions** button with the exact values for your account.
+</Aside>
+
+### cPanel hosting
+
+| Setting | Value |
+| --- | --- |
+| **Incoming (IMAP)** | `cpanel01.cloud-hosting.io`, port **993**, SSL/TLS |
+| **Incoming (POP3)** | `cpanel01.cloud-hosting.io`, port **995**, SSL/TLS |
+| **Outgoing (SMTP)** | `cpanel01.cloud-hosting.io`, port **465**, SSL/TLS |
+| **Username** | Your full email address |
+| **Authentication** | Required, for outgoing as well as incoming |
+
+Port **587 with STARTTLS** also works for outgoing if your app prefers it.
+
+## IMAP or POP3?
+
+Choose **IMAP** unless you have a specific reason not to.
+
+- **IMAP** keeps mail on the server and mirrors it to every device. Read a message on your phone and it shows as read on your laptop. This is what you want when you use more than one device.
+- **POP3** downloads mail to one device and, by default, removes it from the server. Mail then exists only on that machine — if it dies, so does your mail.
+
+<Aside type="caution">
+  Take care switching an existing account from POP3 to IMAP. If POP3 has been deleting messages from the server as it downloaded them, those messages exist only in your local app — and they won't reappear when you switch. Back up first, or ask us to check before you change anything.
+</Aside>
+
+## Common problems
+
+**Incoming works, outgoing fails.** Almost always because outgoing authentication is off. Many apps leave it unticked by default. Find the option — usually *My outgoing server requires authentication* — and enable it with the same username and password.
+
+**Password rejected.** Use the full email address as the username. If it still fails, reset the mailbox password and try again — and watch for autocorrect capitalising the first letter on phones.
+
+**Certificate warnings.** Connect using the server hostname in the table above, not your own domain. A certificate is issued for the server's name, so connecting as `mail.yourdomain.com` can trigger a mismatch warning even though everything works.
+
+**Old mail missing after setup.** If the account was previously POP3, see the caution above before assuming anything is lost.
+
+## Related
+
+- [Create an email account](/whp/how-to/create-an-email-account/) — WHP
+- [Send WordPress email from your own domain](/cpanel/wordpress-email-from-your-domain/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,53 @@
+---
+title: Changes to spam filtering
+description: We're moving spam filtering from Baruwa to Proxmox Mail Gateway. What's changing, when, and what you need to do.
+sidebar:
+  order: 2
+  badge: Notice
+---
+
+import { Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+We're changing the platform that filters spam for our mail customers.
+
+**Baruwa**, which we've used for years, reaches end of life in **November 2026** — its developers are stopping support and security updates. Rather than run mail filtering on software that no longer receives fixes, we're moving to **Proxmox Mail Gateway**.
+
+## What this means for you
+
+**For most customers, nothing changes and there's nothing to do.** Your address stays the same, your mailbox and its contents are untouched, and your email app keeps working without reconfiguration. Filtering continues throughout — we're changing what does it, not whether it happens.
+
+If you're one of the customers who uses the Baruwa web interface directly — to review quarantined mail, or to manage your own allow and block lists — that's the part that changes, since Proxmox Mail Gateway has its own interface. **We'll contact you individually** to move you across and show you the equivalent screens. You don't need to do anything in the meantime.
+
+<Aside type="tip">
+  Worth doing now, whoever you are: if you've built up allow or block lists in Baruwa that matter to you, take a copy. We'll migrate what we can, but having your own record makes it easy to confirm nothing was missed.
+</Aside>
+
+## Timeline
+
+| When | What happens |
+| --- | --- |
+| Now | Baruwa continues to run. We begin moving customers across. |
+| Before November 2026 | Affected customers are contacted individually and migrated. |
+| November 2026 | Baruwa reaches end of life and is retired. |
+
+We'll update this page as the migration progresses.
+
+## Questions we expect
+
+**Will I lose quarantined mail?** Anything currently held in quarantine stays available until your migration. If something in there matters, release it to your inbox rather than leaving it quarantined.
+
+**Do I need to change my email settings?** No. Server names, ports, and passwords are unaffected — see [Set up your email](/email/set-up-your-email-client/) if you're configuring a new device.
+
+**Is my mail less protected during the change?** No. Filtering runs continuously through the migration; there's no window where mail is unfiltered.
+
+**I'd rather opt out of filtering entirely.** Talk to us and we'll go through the options and the trade-offs.
+
+## Related
+
+- [Set up your email](/email/set-up-your-email-client/)
+- [Create an email account](/whp/how-to/create-an-email-account/)
+
+## Questions about your account?
+
+<Support />
@@ -0,0 +1,68 @@
+---
+title: Remote support with RustDesk
+description: Install and configure the RustDesk client so our support team can connect to your device and help directly.
+sidebar:
+  order: 1
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+Sometimes the fastest way to sort something out is for us to see your screen — configuring an email client, reproducing an error we can't recreate from our side, or walking through a setting together.
+
+We use **RustDesk**, an open-source remote-desktop tool, running on our own relay server rather than a third-party service. Nothing is installed permanently and nothing runs in the background: you start it when you want help and close it when you're done.
+
+<Aside type="caution">
+  We will never ask you to install remote-support software out of the blue. If someone contacts you claiming to be from AnHonestHost and asks for remote access to your computer — especially about a payment, a refund, or a "problem with your account" — stop and [open a ticket](https://secure.anhonesthost.com/submitticket.php) to check it's really us. Only ever run this at the end of a conversation *you* started with us.
+</Aside>
+
+## Install the client
+
+Download RustDesk for your device from the official releases:
+
+- **Windows, macOS, and Android** — [github.com/rustdesk/rustdesk/releases/latest](https://github.com/rustdesk/rustdesk/releases/latest). Pick the `.msi` for Windows, the `.dmg` for macOS, or the signed `.apk` for Android.
+- **iOS / iPadOS** — [RustDesk on the App Store](https://apps.apple.com/us/app/rustdesk-remote-desktop/id1581225015).
+
+## Point it at our server
+
+We run our own ID and relay server, which is faster and keeps your session off shared public infrastructure. You only need to do this once.
+
+<Steps>
+
+1. Open **Settings**. On desktop that's the **three dots** next to your ID; on mobile it's the settings icon.
+
+2. On desktop, choose **Network**. (On mobile, skip straight to the next step.)
+
+3. Choose **ID/Relay server** and enter:
+
+   | Field | Value |
+   | --- | --- |
+   | **ID server** | `rustdesk.cloud-hosting.io` |
+   | **Relay server** | `rustdesk.cloud-hosting.io` |
+   | **API server** | `https://rustdesk.cloud-hosting.io` |
+   | **Key** | `UmpkeFe76AKt8vw8Pj0YCSbxIcYLsqqfPGYzLRl+PgA=` |
+
+4. **Save**, then go back to the **Home** screen.
+
+</Steps>
+
+## Starting a session
+
+The support operator needs two things from the Home screen:
+
+- **Your ID** — a nine-digit number that stays the same for your device.
+- **Your one-time password** — shown beneath the ID, and regenerated each time.
+
+Give both to your support operator over the phone, or in your ticket.
+
+<Aside type="tip">
+  If you send them in a ticket rather than over the phone, **leave your computer on with RustDesk running** — the one-time password only works while the client is open, and we can't connect to a sleeping machine.
+</Aside>
+
+## Ending a session
+
+Close the RustDesk window when you're finished. With it closed, no connection is possible — the one-time password from your session is already spent, and a new one is generated next time you open it. You can uninstall the client entirely if you'd rather.
+
+## Still stuck?
+
+<Support />
@@ -15,10 +15,10 @@ import Support from '~/content/partials/support-link.mdx';
 Archival email keeps a long-term, searchable copy of your mail **outside** the live mailbox. It's useful when:

 - You need to retain mail beyond your live mailbox's storage cap.
- Compliance or policy requires you keep email for a fixed window.
+- Compliance or policy requires you keep email long-term.
 - You want a recovery option for mail you accidentally delete from the live mailbox.

-It's powered by our [Bichon](https://anhonesthost.com/bichon/) archival service.
+It's powered by the open-source [Bichon](https://github.com/rustmailer/bichon) archival service.

 ## How it's different from backups

@@ -33,8 +33,8 @@ You can use both — they cover different problems.
 ## What's included

 - **Per-mailbox archive.** Enable on the mailboxes that need it, not the whole account. Your plan has an **archival slots** quota; the Email page shows current usage (e.g. `Archival: 0 of 0 mailboxes archived (no archival slots in your plan)` if you haven't added the add-on yet).
- **14-day quick-restore window.** Accidentally deleted mail is recoverable without staff help.
- **Configurable longer retention.** Set retention to match your policy.
+- **Retained for the life of your account.** We keep your archive for as long as you have an active account with us — there's no 14-day limit or fixed expiry window.
+- **Self-service restore.** Mail you accidentally delete from the live mailbox stays in the archive, so you can find and recover it yourself without staff help.
 - **Independent password reset on the archive.** Grant audit access without disturbing the live mailbox.

 ## How to enable
@@ -0,0 +1,93 @@
+---
+title: Optimized Webserver (OpenLiteSpeed + LSCache)
+description: Run your sites on OpenLiteSpeed with server-level full-page caching for dramatically faster page delivery — ideal for WordPress and other dynamic CMS sites.
+sidebar:
+  order: 5
+---
+
+import { Aside } from '@astrojs/starlight/components';
+import PaidAddon from '~/content/partials/paid-addon-callout.mdx';
+import Support from '~/content/partials/support-link.mdx';
+
+<PaidAddon />
+
+The Optimized Webserver add-on moves your sites from standard Apache/PHP onto our shared **OpenLiteSpeed** pool with the **LiteSpeed Cache (LSCache)** engine. LSCache is a server-level full-page cache built directly into the web server — cached pages are served in a few milliseconds, before PHP ever runs.
+
+This is an **account-level** add-on: purchase it once and you can put as many of your hosted sites on the premium backend as you like — no per-site charge.
+
+## Why use it
+
+### Dramatically faster cacheable pages
+
+LSCache operates at the web-server layer, not inside WordPress or PHP. When a page is cached, the response is served in a few milliseconds with no PHP execution and no database queries. For a WordPress site that normally takes 300–800 ms to generate a page, cached hits feel instant to visitors.
+
+### Built for dynamic CMS sites — especially WordPress
+
+OpenLiteSpeed works directly with the official [LiteSpeed Cache plugin for WordPress](https://wordpress.org/plugins/litespeed-cache/). The plugin manages cache purging automatically: publish a post, update a page, or complete a WooCommerce order and the right cache entries are dropped so visitors see fresh content immediately.
+
+### Handles traffic spikes efficiently
+
+Because cached hits skip PHP and the database entirely, the server can absorb a burst of traffic without proportionally increasing CPU or memory load. Sites on the standard backend can stall under sudden spikes; on LSCache, most of that load is absorbed before it reaches PHP.
+
+### HTTP/3 and QUIC
+
+OpenLiteSpeed has native HTTP/3/QUIC support. Visitors on modern browsers get the lower-latency transport automatically — no configuration needed.
+
+### Efficient memory profile on shared hosting
+
+Our shared OpenLiteSpeed pool is tuned for multi-tenant use. You get the performance benefits without needing a dedicated server or a much larger container allocation.
+
+## When you may NOT want it
+
+<Aside type="caution">
+  Read this section before switching. The performance gains are real, but not every site benefits equally — and there are a few cases where the standard backend is the right choice.
+</Aside>
+
+- **Purely static sites or very low-traffic sites.** If your site serves a handful of visitors a day, the standard backend is already fast enough. You won't see a meaningful difference, and the add-on cost won't pay off.
+- **Highly personalised or uncacheable output.** Sites that generate unique content per visitor on every request (custom dashboards, paywalled pages with per-user state, complex session-driven flows) can't benefit much from a full-page cache. LSCache has smarts for partial caching, but if the majority of your pages can't be cached, the speed gains are limited.
+- **You haven't tested your site on it.** We don't auto-migrate sites. You opt each site in yourself, verify everything looks right — plugins, checkout flows, member areas — and only then commit. Cache behaviour can surface edge cases (stale content after a post update, logged-in users seeing cached guest pages) that need a plugin configuration tweak. Test before you rely on it.
+- **Cold cache after switching.** The first time each page is requested after you switch, it runs through PHP as normal (the cache starts empty). Subsequent hits are served from cache. Don't judge performance on the very first load.
+- **Don't stack full-page cache plugins.** If you already run a second full-page caching plugin (W3 Total Cache, WP Super Cache, WP Fastest Cache, etc.) alongside LSCache, they'll conflict. Disable any other full-page caching plugin when you switch; LSCache replaces it, not supplements it. Object-cache and CDN integrations are fine.
+
+## How to enable it
+
+### Step 1 — Purchase the add-on
+
+The Optimized Webserver add-on is purchased from the [client portal](https://secure.anhonesthost.com/clientarea.php). Go to **Services → My Services**, open your hosting plan, then **Upgrade/Downgrade → Optimized Webserver**. Once confirmed, the option becomes available in WHP within a few minutes.
+
+### Step 2 — Switch individual sites onto it
+
+Enabling the add-on at the account level doesn't automatically move any of your sites. You opt each site in one at a time:
+
+1. In WHP, go to **Sites** and click **Edit** on the site you want to switch.
+2. Under **PHP / Backend**, choose one of the **LiteSpeed PHP** options.
+3. Save. The site container is recreated on the OpenLiteSpeed pool — there is a brief moment of downtime (usually under 30 seconds) during the switchover.
+
+For a full walkthrough, see [Switching a site's backend](/whp/how-to/switching-site-backend/).
+
+### Step 3 — Install (or verify) the LiteSpeed Cache plugin
+
+For WordPress sites, install the free [LiteSpeed Cache plugin](https://wordpress.org/plugins/litespeed-cache/) from the WordPress plugin directory if it isn't already active. It handles cache purging on content changes automatically. Default settings work well for most sites; advanced tuning options are in the plugin's settings panel.
+
+<Aside type="note">
+  If you were previously running another full-page caching plugin, deactivate (don't just disable caching — actually deactivate) it after switching. Leaving two full-page caches active causes unpredictable behaviour.
+</Aside>
+
+## Cancelling
+
+To cancel the Optimized Webserver add-on you must first **move all your sites back to a standard backend**. The panel will block cancellation while any site is still using a LiteSpeed PHP option.
+
+Switch each affected site back via **Sites → Edit → PHP / Backend**, then cancel the add-on from the [client portal](https://secure.anhonesthost.com/clientarea.php).
+
+For the site-switching steps, see [Switching a site's backend](/whp/how-to/switching-site-backend/).
+
+## Related
+
+- [Clear your site's cache](/whp/how-to/clear-your-cache/) — what to do when a change doesn't show up right away.
+- [Add-ons overview](/whp/add-ons/overview/)
+- [Resource upgrades](/whp/add-ons/resource-upgrades/) — if you need more CPU or RAM rather than a faster cache layer.
+- [Site Monitoring](/whp/add-ons/monitoring/) — pair with Optimized Webserver to catch any cache-related issues early.
+
+## Still stuck?
+
+<Support />
@@ -20,6 +20,7 @@ Add-ons are **optional extras** you can layer onto your base hosting plan. Each
 - **[Archival email](/whp/add-ons/archival-email/)** — long-term, searchable retention of your mail outside the live mailbox.
 - **[Resource upgrades](/whp/add-ons/resource-upgrades/)** — extra CPU, RAM, or storage without changing plans.
 - **[Email upgrades](/whp/add-ons/email-upgrades/)** — extra mailboxes or larger per-mailbox storage caps.
+- **[Optimized Webserver](/whp/add-ons/optimized-webserver/)** — run your sites on OpenLiteSpeed with server-level LSCache for dramatically faster page delivery.

 ## How billing works

@@ -0,0 +1,120 @@
+---
+title: Backups
+description: How WHP's automatic backups work, the default-target requirement, full-server backups vs customer data backups, and managing backup targets.
+sidebar:
+  order: 6
+---
+
+import { Aside } from '@astrojs/starlight/components';
+import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
+import Support from '~/content/partials/support-link.mdx';
+
+<SuperAdmin />
+
+WHP backs up **customer data** (sites and databases) when an admin has configured a default backup target. WHP does **not** back up the full server — that's a separate concern.
+
+## Two different things called "backup"
+
+It's worth being precise:
+
+- **Customer data backups** — what WHP does. Site files (per user, per domain) and databases. Configured per server via backup targets. These start automatically once a default target exists.
+- **Full server backups** — backing up the host OS, `/etc`, container images, the WHP install itself, etc. **WHP does not do this.**
+
+### Full server backups
+
+| Where WHP runs | Who owns full-server backups |
+|---|---|
+| **Our Virtual Dedicated Server (VDS)** plans | Included. AnHonestHost snapshots the VDS at the platform level. |
+| **Anywhere else** | The server operator. WHP doesn't ship a full-server backup mechanism — you'll need to set up something at the OS / hypervisor level. |
+
+If you're running WHP on your own infrastructure, plan accordingly. WHP's configuration isn't all in `/etc` — there are config and state files in the WHP install directory, in Docker volumes for the platform containers (HAProxy, MySQL, Postgres, Valkey, the WAF), and in service-specific paths elsewhere on the host. The safest approach is a **full-server backup** (image snapshot or filesystem-level backup) rather than trying to enumerate paths.
+
+## Sign in as super admin
+
+<AdminSignIn />
+
+## How customer auto-backups start
+
+**Customer auto-backups don't run until at least one default backup target exists.** A fresh WHP install has no targets and no schedule — every user's backup status is "no targets available" until an admin sets one up.
+
+Once a default target is configured, the platform begins automatic daily backups for every customer with sites or databases. Customers see their own backup history under the [Backups](/whp/how-to/backups/) page in their account.
+
+## The Backup Management page
+
+Sidebar → **Backups**. The admin view of this page mirrors the customer view, with extra controls:
+
+- **Stat tiles** — Total Backups, Total Size, Sites, Databases. Server-wide totals across every account.
+- **Create New Backup** — fires an on-demand backup. Admin form adds a **User** dropdown so you can backup any customer's account, not just your own.
+- **Backup Targets** — the table of destinations available on the server. The **Global** column distinguishes shared targets from per-account targets.
+
+### Backup targets
+
+Each target row has:
+
+- **Name** — your label for the destination.
+- **Type** — S3 (and other supported types) — built-in support for S3-compatible storage (AWS S3, Cloudflare R2, MinIO, etc.).
+- **Connection** — the endpoint URL and bucket / path.
+- **Retention** — how long backups are kept (default 5 days).
+- **Max Backups** — cap on the number of snapshots retained (default 10).
+- **Global** — `Yes` if every account can use this target, `No` if it's bound to a single account.
+- **Actions** — **Test** (verify credentials and write a probe object), **Edit**, **Delete**.
+
+### Adding a global backup target
+
+Click **+ Add Backup Target** and fill in:
+
+1. **Name** — descriptive label.
+2. **Type** — pick S3 (or whichever storage backend you want).
+3. **Endpoint URL** — for non-AWS S3 (Cloudflare R2, MinIO, Wasabi, etc.), point at the provider's endpoint.
+4. **Bucket / path**.
+5. **Access key / Secret** — the credentials WHP will use.
+6. **Retention / Max Backups** — server-wide defaults for any account that uses this target.
+7. **Global** — leave **on** so every account can use it as their default destination.
+
+Click **Test** before saving to confirm WHP can reach the bucket. A good target round-trips a probe object in under a second.
+
+<Aside type="tip">
+  Keep one global target as the default. Customers who want their own offsite (e.g. their own S3 bucket) can add a per-account, non-global target — visible in the same table for the admin, but only usable by that one customer.
+</Aside>
+
+### Per-customer (non-global) targets
+
+Customers can add their own backup targets from the customer-side Backups page. Those show up here with **Global: No** plus a note linking them to the owning account. Admins can edit or delete those on the customer's behalf when they need help.
+
+### Triggering an on-demand backup for a user
+
+In the **Create New Backup** form:
+
+1. Pick the customer in the **User** dropdown.
+2. Pick a **Backup Type** (Sites / Databases / both).
+3. Pick a **Backup Target**.
+4. **Start Backup**. Progress is visible in the run history below.
+
+This is the right path when a customer asks for a fresh backup right before a risky migration.
+
+## Verifying customer backups are succeeding
+
+The Total Backups and Total Size tiles climb over time on a healthy server. If they sit flat:
+
+- Confirm at least one target exists with **Global: Yes**.
+- Open the run history (lower on the page) and look for failed entries — the error message usually points at credentials or quota.
+
+## Troubleshooting
+
+**No backups are running for any customer.** Confirm at least one **Global: Yes** target exists and that its **Test** button returns success. Without a global default, the scheduler doesn't fire.
+
+**One target is failing.** Click **Test** on the target row. The most common causes are rotated credentials, an incorrect endpoint URL (R2 / MinIO often need an explicit endpoint different from AWS's default), or the bucket lifecycle policy deleting backups before the retention window.
+
+**Customer says their backup is too old.** Check **Max Backups** on the target — if it's lower than their backup cadence × retention window, older backups get pruned.
+
+**Backup ran but `tar` step failed mid-stream.** Disk pressure on the host is a common cause. Check **Disk Usage** (admin sidebar) and consider raising the target's retention so fewer backups stack up on the host before upload.
+
+## Related
+
+- [Backups](/whp/how-to/backups/) — the customer-facing side.
+- [Server settings & services](/whp/admin/server-settings/) — including Backup Upload host service.
+
+## Still stuck?
+
+<Support />
@@ -1,95 +1,108 @@
 ---
 title: Coraza WAF rules
-description: Tune the Coraza web-application firewall rules running in front of your sites — toggle modes, mute false positives, audit blocks.
+description: Set the global WAF mode, tune individual rules, audit blocked requests, and add per-host overrides.
 sidebar:
  order: 3
-  badge:
-    text: Draft
-    variant: caution
 ---

 import { Aside } from '@astrojs/starlight/components';
 import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
-import Draft from '~/content/partials/draft-callout.mdx';
-import SignIn from '~/content/partials/signing-in.mdx';
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
 import Support from '~/content/partials/support-link.mdx';

 <SuperAdmin />

-<Draft />
+[Coraza](https://coraza.io/) is an open-source web-application firewall (WAF) that runs as a sidecar in front of your sites. The **Coraza Rules** page in the admin sidebar gives you a UI to set the global mode, tune individual rules, and audit blocked requests — all without rebuilding the sidecar image.

-[Coraza](https://coraza.io/) is an open-source web-application firewall (WAF). It runs as a sidecar in front of your sites and inspects incoming requests against rule families like OWASP Core Rule Set v4 (CRS). The admin WHP gives you a UI to manage the rules and audit what's been blocked.
+![Coraza Rules page — Firing rules tab](~/assets/screenshots/whp/admin-coraza.png)

-## Three operating modes
+## Global WAF mode

-The WAF runs in one of three modes, set per-site or server-wide:
+A coloured pill at the top of the page shows the **Global WAF mode** with a **change** link:

- **Off.** No inspection. Requests pass through untouched.
- **Detect-only.** Inspect every request and log matches, but pass them through. Use this when rolling out the WAF for the first time or when validating a rule change.
- **Enforce.** Inspect every request and **block** any that match an enforcing rule. This is the production setting once you've validated detect-only.
+- **Off** — no inspection. Requests pass untouched.
+- **Detect** — inspect and log matches; do not block. Use during a roll-out or while validating a rule change.
+- **Enforce** — inspect and block anything that matches an enforcing rule.

-The WAF is fail-open: if the Coraza sidecar itself is unhealthy, traffic still flows.
+The WAF is **fail-open**: if the Coraza sidecar is itself unhealthy, traffic still flows.

-## Sign in to WHP
+## Sign in as super admin

-<SignIn />
+<AdminSignIn />

-## Where it lives
+## The three tabs

-Sidebar → **Security → Coraza Rules**. The page lists rule families (CRS 901, 911, 913, 920–922, 930–934, 941–944, 949, 950–956, 959, 980) and per-rule controls.
+### Firing rules
+
+The default view. Each row is a rule that has matched at least one request in the selected time window (toggle **Last 24h** or **Last 7d** at top right).
+
+Columns:
+
+- **Rule ID** — the CRS or custom rule identifier. **view** opens the rule definition. **Ask AI** opens an explanation of what this rule catches.
+- **Hits** — how many times the rule fired in the time window.
+- **Top hosts** — the top customer domains that triggered this rule (with per-host hit counts).
+- **Top URIs** — the most common request paths that triggered it (helpful for distinguishing scans from real traffic).
+- **State** — per-rule override of the global mode. Options: `(default → enforce)`, `(default → detect)`, `(default → score)`, `off`. Picking anything other than `(default → …)` overrides the global mode for that rule.
+- **Per-host** — opens a **Hosts (N)** drawer to set per-host overrides for that rule.
+
+<Aside type="tip">
+  Rule changes apply on the next request. The page reloads the sidecar via SIGHUP after every save (~10ms — no traffic blip).
+</Aside>
+
+### CRS catalog
+
+The full OWASP Core Rule Set catalogue (v4 families: 901, 905, 911, 913, 920–922, 930–934, 941–944, 949, 950–956, 959, 980). Use this when you want to look up a rule that *hasn't* fired yet — for example, to pre-mute a rule you know will produce false positives on a specific app.
+
+### Activity
+
+A timeline / log of every WAF block in the audit window. Use it to:
+
+- Confirm a customer report (cross-reference the **X-Request-Reference** UUID on the visitor-facing 403 page).
+- Spot bursts of activity from the same source IP.
+- Tune source-of-truth back-end queries — the audit is read from `security.db`.

 ## Common tasks

 ### Roll a new site onto the WAF

-<Aside type="tip">
-  Always start in **Detect-only** for a new site. Move to **Enforce** only after you've watched the logs and confirmed no legitimate traffic is being matched.
-</Aside>
-
-1. Open **Security → Coraza Rules**.
-2. Find the site and set mode to **Detect-only**.
-3. Drive normal traffic for at least 24 hours.
-4. Open the **Audit log** and filter to that site. Confirm no legitimate request is matching an enforcing rule.
-5. Switch the site to **Enforce**.
+1. Set the rule's **State** to `(default → detect)` for that site via the Per-host drawer.
+2. Drive normal traffic for at least 24 hours.
+3. Open the **Activity** tab and filter to that host. Confirm no legitimate request is matching an enforcing rule.
+4. Flip the host to **enforce**.

 ### Mute a noisy rule

-When a rule is firing on legitimate traffic for one site:
+1. Find the rule in **Firing rules**.
+2. Click **Per-host → Hosts (N)** to add a per-site mute, OR change the rule's **State** column to mute it globally.

-1. Click the audit-log row to see the rule_id and the matched request.
-2. From the **Coraza Rules** page, find the rule by ID.
-3. Pick **Ignore for this site** (per-site mute) or **Ignore globally** (server-wide mute).
-4. Save. The rule stops firing on the next request.
-
-Per-site is almost always the right scope. Use global mute sparingly — it weakens the WAF for every site.
+Prefer per-host. Global mute weakens the WAF for every site.

 ### Audit a block

-Customer reports a request was wrongly blocked? The branded 403 page that visitors see includes an **X-Request-Reference** UUID. Cross-reference it:
+Customer reports a request was wrongly blocked? The branded 403 page includes an **X-Request-Reference** UUID. Cross-reference it:

-1. In the **Audit log**, search for the UUID.
-2. The audit row shows the matched rule_id, the source IP, the URL, and the offending parameter.
+1. In the **Activity** tab, search for the UUID.
+2. The row shows the matched rule ID, source IP, URL, and offending parameter.
 3. Decide whether to mute the rule (see above) or leave it — many "false positives" turn out to be real attempts.

-## Things to know
+## Implementation notes

- **Rule changes apply on the next request.** No service restart needed for tuning.
- **Adding or removing rules requires a full reload** of `coraza-spoa`, not just a SIGHUP. The panel handles this for you; if you edit rule files by hand, `docker restart coraza-spoa`.
- **Real source IPs are in the audit log.** Even though haproxy fronts the WAF, we propagate the real client IP through the SPOE messages.
- **`SecRuleRemoveById` plus a new rule needs a full restart**, not just a config reload. Again, the panel handles this when you change rules through the UI.
+- **Source of truth: `security.db`.** All rule edits go through the panel and write to that SQLite file; manual file edits won't survive a regeneration.
+- **Reload mechanism.** Rule edits apply via SIGHUP to `coraza-spoa`; adding or removing whole rule files requires a full container restart, which the panel performs when the change needs it.
+- **Real source IPs are in the audit log** — even with HAProxy in front of the WAF, the real client IP is propagated through the SPOE messages.

 ## Troubleshooting

-**A rule shows enabled but doesn't fire.** Check that the site is in **Detect-only** or **Enforce** mode. A site in **Off** mode bypasses every rule, including enabled ones.
+**A rule shows enabled but doesn't fire.** Check that the host is in **detect** or **enforce** mode. A host in **off** bypasses every rule.

-**The audit log is empty.** Confirm `coraza-spoa` is healthy on the **Services** page. If it's restarting in a loop, check the container logs — most often a malformed rule file or a missing include.
+**The Activity log is empty.** Confirm `coraza-spoa` is healthy on the **Services** tab of Server Settings. If it's restarting in a loop, check the container logs — usually a malformed rule file or a missing include.

-**Edits revert on restart.** Make sure you're editing through the panel; manual edits to files outside the panel-managed path are overwritten by config regeneration.
+**Edits revert on restart.** Make sure you're editing through the panel; manual edits outside the panel-managed path are overwritten.

 ## Related

 - [Server settings & services](/whp/admin/server-settings/)
- [Site Monitoring rules](/whp/admin/site-monitoring/)
+- [AI Monitor, Issues & Ignore Rules](/whp/admin/site-monitoring/)

 ## Still stuck?

@@ -0,0 +1,202 @@
+---
+title: Data-drive encryption (LUKS)
+description: Optional LUKS2 encryption of the /docker data volume on new server installs. Encrypts customer data, databases, and container state at rest; adds a manual unlock step after every reboot.
+sidebar:
+  order: 7
+---
+
+import { Aside } from '@astrojs/starlight/components';
+import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
+import Support from '~/content/partials/support-link.mdx';
+
+<SuperAdmin />
+
+WHP can encrypt the **`/docker` data volume** — where customer site files,
+databases, container state, and SSL material live — using LUKS2 (the same
+disk-encryption layer used by every mainstream Linux distribution).
+
+When enabled, anyone who walks off with the physical disk (or images it
+offline) sees only ciphertext. The encryption key never lives on disk in
+plaintext.
+
+<Aside type="caution" title="Available only on new server installs">
+  Data-drive encryption must be enabled when the server is **first
+  provisioned**. There is no in-place "encrypt this existing server"
+  workflow today — switching a live server to encrypted storage requires a
+  manual data migration and is currently handled as a custom engagement.
+  Open a [support ticket](https://secure.anhonesthost.com/submitticket.php)
+  if you're considering this for an existing server.
+</Aside>
+
+## What changes if you enable it
+
+The trade-off is one extra manual step every time the server reboots.
+
+**At install time:**
+- A strong passphrase (32 hex characters) is generated and **shown to you
+  once** in the install banner. You're responsible for saving it before
+  install completes — there is no recovery if it's lost.
+
+**On every reboot (planned or unplanned):**
+- The `/docker` volume comes up **locked**. The regular WHP control panel
+  at `:8443` is offline until you unlock it.
+- The host itself boots normally — SSH, networking, monitoring, etc.
+  remain reachable.
+- You unlock via either:
+  - **Web:** browse to `https://<server>:8444/`, sign in with the server's
+    `root` credentials, and paste the LUKS passphrase. The form redirects
+    you back to the regular panel after the volume mounts and services
+    come up (around 30 seconds end-to-end).
+  - **SSH:** run `/root/whp/scripts/whp-unlock-data-drive` and enter the
+    passphrase at the prompt. Same outcome.
+
+**While unlocked:**
+- The server runs identically to a non-encrypted server. No performance
+  penalty noticeable for typical hosting workloads.
+
+<Aside type="caution" title="Plan for the reboot overhead">
+  Customer sites are unreachable from the moment the server reboots until
+  someone unlocks `/docker`. **Plan reboots accordingly** — and make sure
+  the right people have both the root credentials and the LUKS passphrase
+  before the first reboot.
+</Aside>
+
+## The security model in plain English
+
+LUKS protects you against **data at rest** being read by someone without
+the passphrase. Specifically:
+
+- **Stolen or lost disk:** the device is unreadable without the passphrase.
+- **Disk RMA / drive replacement:** you can return drives without secure
+  erase; the data on them is ciphertext.
+- **Offline forensic imaging:** an attacker who can power off the server
+  and copy the disk gets ciphertext.
+
+It does **not** protect against:
+
+- **A live, running server being compromised** — once `/docker` is
+  unlocked, the data is plaintext in memory and accessible to anyone with
+  root on the host. (This is the same as any other Linux server.)
+- **Lost passphrase** — there is no recovery key, no master override, no
+  vendor reset. Losing the passphrase means losing the data.
+
+If your threat model is "compliance / customer expectations around
+data-at-rest encryption," LUKS covers it. If it's "attacker has live
+shell on the server," LUKS does nothing additional — you need separate
+controls (access policy, monitoring, segmentation).
+
+## The unlock surface in detail
+
+The unlock daemon (`whp-locked-unlock.service`) is a small standalone
+HTTPS server that runs **independently** of the main control panel
+(Apache + PHP-FPM). It exists for exactly one purpose: prompt for and
+validate the LUKS passphrase, then hand off to the helper that opens the
+volume and starts the customer-facing services.
+
+- **Port:** `8444` (separate from the regular panel on `:8443` / `:8080`)
+- **TLS:** if your server has a real Let's Encrypt certificate for its
+  hostname (the usual case on AnHonestHost-managed installs), the daemon
+  uses that. If not, it uses the same self-signed cert that the regular
+  panel falls back to.
+- **Authentication:** the server's root credentials via PAM (same login
+  as the regular control panel), **plus** the LUKS passphrase. Both must
+  be correct.
+- **Rate limit:** five failed attempts per IP per five minutes triggers a
+  short lockout. You can unlock from another IP, from SSH, or wait for
+  the window to expire.
+- **Auto-stop:** once the unlock succeeds, the daemon exits cleanly. It
+  comes back automatically on the next reboot.
+
+After the web unlock, the regular control panel at `:8443` becomes
+reachable within ~30 seconds (the time it takes Docker, Apache, and the
+boot orchestrator to start the customer containers).
+
+## Header backup — critical for recovery
+
+The LUKS2 header is a small region (~16 MB) at the start of the
+encrypted device that holds the keyslot data. If that region gets
+corrupted (bad sectors, partition table accident, careless `dd`), the
+data is unrecoverable **even with the correct passphrase**.
+
+WHP keeps a header backup automatically:
+
+- **Initial backup** at `/etc/whp/luks-header.backup`, created during the
+  install.
+- **Daily refresh** via cron — only writes a new file when the header
+  has actually changed (i.e. on passphrase rotation).
+- **Rolling 30-day history** at `/var/lib/whp/luks-headers/`.
+- **Off-host upload** if you've configured an rclone remote named
+  `whp-system-backup`. We strongly recommend setting this up so the
+  header isn't only on the same disk it's protecting.
+
+In a header-corruption scenario, restoring is a one-command operation
+using the saved backup, then unlocking with your passphrase as normal.
+
+## Rotating the passphrase
+
+If you need to change the LUKS passphrase (staff rotation, suspected
+compromise of the saved copy, etc.), do it in this order:
+
+1. **Add the new passphrase** as a second keyslot — the volume now
+   accepts either one.
+2. **Verify the new passphrase works** with a non-destructive test.
+3. **Remove the old passphrase** from its keyslot.
+
+The full command sequence is documented in the operator runbook on the
+server itself (`/root/whp/docs/LUKS_RUNBOOK.md`). After any keyslot
+change, the daily header backup picks up the new header SHA and uploads
+a fresh copy on its next run.
+
+## Things to know before you commit to it
+
+- **Lost passphrase = lost data.** This is the single most important
+  thing to plan around. Treat the passphrase the way you'd treat a
+  payment-processor master key.
+- **Every reboot needs someone awake.** Auto-restart watchdogs, kernel
+  updates that trigger a reboot, and power events all become events
+  that require manual intervention. If your team can't respond within
+  your acceptable downtime window, this isn't the right fit.
+- **Server-side backups still matter.** Encryption protects against
+  data theft. It does not protect against data loss. Your customer
+  backup configuration and the LUKS header backup are independent
+  concerns — both need to be in place.
+- **Boot drive is unencrypted.** The OS, the control panel itself, and
+  the LUKS configuration file all live on the unencrypted boot drive.
+  This is intentional — it lets the unlock UI come up and lets you SSH
+  in for recovery before `/docker` is available.
+
+## When LUKS is **not** the right choice
+
+- Servers where unattended reboots are operationally required (e.g.
+  automated kernel updates with reboot on a recurring schedule with no
+  human in the loop).
+- Servers where the only "threat" is the existing AnHonestHost
+  operational controls — if your compliance posture doesn't ask for
+  data-at-rest encryption specifically, the operational overhead may
+  not be worth it.
+- Existing servers with live customer data on them — wait for the
+  retrofit workflow rather than attempting a manual migration without
+  guidance.
+
+## Setting this up on a new server
+
+If you're spinning up a fresh server and want data-drive encryption,
+mention it in the provisioning ticket and we'll configure it as part of
+the install. We'll send you the generated passphrase through a secure
+channel and confirm you have it stored before the server is handed over.
+
+For technically-inclined customers running WHP themselves, the install
+flag is documented in the operator runbook that ships on every server at
+`/root/whp/docs/LUKS_RUNBOOK.md`.
+
+## Related
+
+- [Server settings & services](/whp/admin/server-settings/) — restart
+  individual services after an unlock, view system info.
+- [Backups](/whp/admin/backups/) — independent of LUKS; both should be
+  configured.
+- [Admin overview](/whp/admin/overview/) — other super-admin features.
+
+## Still stuck?
+
+<Support />
@@ -1,43 +1,68 @@
 ---
 title: Admin overview
-description: What WHP super admin unlocks — server-wide controls for services, security rules, monitoring, and users.
+description: What WHP super admin unlocks — server-wide controls for services, mail, DNS, security, monitoring, and users.
 sidebar:
  order: 1
-  badge:
-    text: Draft
-    variant: caution
 ---

 import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
-import Draft from '~/content/partials/draft-callout.mdx';
 import Support from '~/content/partials/support-link.mdx';

 <SuperAdmin />

-<Draft />
-
 ## What super admin unlocks

-The same WHP panel you'd use on a customer account scales up: customers with **super admin** access also see server-wide pages for managing services, firewall rules, monitoring policy, and users. The customer-facing sections (Sites, Domains, Email, etc.) work the same way; the admin sections sit alongside them, gated to admins.
+WHP's super admin role exposes server-wide pages alongside the customer-facing nav. The customer pages (Sites, Domains, Email, etc.) work identically for everyone; the admin pages sit alongside them and are gated to the super admin only.

-Today, super admin is most commonly handed to customers running a [Virtual Dedicated Server](https://anhonesthost.com/vds) — they get full server control as part of the plan.
+**Today, the only super admin is the `root` user on the server.** There's no UI to add another super admin — if you need additional people to have super admin, share the root credentials via your usual secret-sharing flow (or [open a ticket](https://secure.anhonesthost.com/submitticket.php) if you need a different model).
+
+This typically applies to customers running a [Virtual Dedicated Server](https://anhonesthost.com/vds) — they get full server control as part of the plan and sign in to WHP as `root`.
+
+### Signing in as super admin
+
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
+
+<AdminSignIn />
+
+## Admin-only sidebar sections
+
+When you sign in as a super admin, these sections appear in addition to the customer-facing nav:
+
+- **AI Monitor** — the admin dashboard, plus **Issues**, **Site Reports**, and **Ignore Rules**.
+- **Security Management** — security policy across the server.
+- **Coraza Rules** — Web-application firewall (WAF) rule tuning, audit, and global mode.
+- **User Management** — create WHP users, set account types, manage existing users.
+- **User Resources** — per-user CPU/RAM/disk allowances and current usage.
+- **Delegated Users** — list of contractor / sub-account access grants.
+- **Active Sessions** — every signed-in browser across the server.
+- **Server Settings** — System, Services, Mail, DNS, Network & SSL, Security tabs.
+- **Disk Usage** — server-wide disk consumption breakdown.
+- **Announcements Management** — edit the announcements that appear on every customer's dashboard.
+- **Update Management** — apply WHP platform updates.
+- **Docker Management** — see and manage every container on the host.
+- **Valkey Admin** — server-wide Valkey configuration.
+- **Container Boot & Health** — boot-order and per-container health.
+- **Site Disable Audit** — record of sites disabled / re-enabled.
+- **Account Suspensions** — suspended customer accounts.

 ## What's in this section

- **[Server settings & services](/whp/admin/server-settings/)** — restart services, manage modules and runtimes, edit server-wide configuration.
- **[Coraza WAF rules](/whp/admin/coraza-waf/)** — view, tune, and tune out web-application-firewall rules across all your sites.
- **[Site Monitoring rules](/whp/admin/site-monitoring/)** — manage the rules that drive Site Monitoring alerts.
- **[Users & delegated access](/whp/admin/user-management/)** — create sub-users, delegate panel access, manage SFTP/SSH users.
+- **[Server settings & services](/whp/admin/server-settings/)** — the six tabs under Server Settings: system info, restart services, mail-server config, DNS / nameservers, HAProxy + SSL, and integration API keys.
+- **[Coraza WAF rules](/whp/admin/coraza-waf/)** — set the global WAF mode, tune individual rules, and audit blocked requests.
+- **[AI Monitor, Issues & Ignore Rules](/whp/admin/site-monitoring/)** — the three pages that drive the Site Monitoring add-on.
+- **[Users & delegated access](/whp/admin/user-management/)** — create accounts, set account types, delegate access, and handle suspensions.
+- **[Backups](/whp/admin/backups/)** — configure the default backup target so customer auto-backups start running. Full-server backups are a separate, plan-dependent concern.
+- **[Data-drive encryption (LUKS)](/whp/admin/data-drive-encryption/)** — optional at-rest encryption of the `/docker` data volume. Available only on new server installs; adds a manual unlock step after every reboot.

 ## Things to know before you change server-wide settings

 - **One change can affect every site on the server.** Where customer-side pages scope changes to one site, admin pages typically scope to the whole server.
 - **Service restarts are visible to live traffic.** Restart Apache or PHP-FPM during a quiet window when possible.
- **Backups still apply.** Server-level changes don't bypass the [backups](/whp/how-to/backups/) you have configured; you can roll back the data side, but service-config changes you made by hand aren't snapshotted unless you back up `/etc` somewhere on your own.
+- **Customer backups don't cover server config.** The [customer backups](/whp/how-to/backups/) you've configured snapshot site files and databases, not server-level changes you make by hand. Server config lives in several places — not just `/etc` — so the right safety net is a **full-server backup**. On AnHonestHost-managed plans and VDS we handle that for you; running WHP elsewhere, the operator is responsible. See [Backups](/whp/admin/backups/) for the full picture.

 ## Related

- [What is containerized hosting?](/whp/getting-started/what-is-containerized-hosting/) — the differences between container plans and full server access.
+- [What is containerized hosting?](/whp/getting-started/what-is-containerized-hosting/) — differences between container plans and full server access.

 ## Still stuck?

@@ -1,74 +1,132 @@
 ---
 title: Server settings & services
-description: Restart Apache, PHP-FPM, MySQL; manage PHP modules and runtimes; edit server-wide configuration.
+description: Restart services, configure mail server, manage DNS / nameservers, HAProxy + system SSL certificates, and integration API keys.
 sidebar:
  order: 2
-  badge:
-    text: Draft
-    variant: caution
 ---

 import { Aside } from '@astrojs/starlight/components';
 import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
-import Draft from '~/content/partials/draft-callout.mdx';
-import SignIn from '~/content/partials/signing-in.mdx';
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
 import Support from '~/content/partials/support-link.mdx';

 <SuperAdmin />

-<Draft />
+The **Server Settings** page lives in the admin sidebar and has six tabs along the left rail. Each tab is a different surface area of the server you can inspect or change.

-This page covers the server-wide controls available in the WHP admin sections — restarting services, managing PHP modules and versions, and adjusting server-level configuration.
+![Server Settings — System tab](~/assets/screenshots/whp/admin-srvset-system.png)

-## Sign in to WHP
+## Sign in as super admin

-<SignIn />
+<AdminSignIn />

-## Restarting services
+## The six tabs

-The admin **Services** page lists the long-running services that run on the server: Apache (front-end web), PHP-FPM (one or more pools), MySQL or MariaDB, the mail stack, and any add-on services like Valkey or PostgreSQL if you've enabled them.
+### System

-Each service has a status indicator and **Restart**, **Stop**, and **Start** controls. Restart is the safe default for picking up new configuration.
+Read-only system summary plus two simple change controls:
+
+- **System Information** — Hostname, Operating System, Kernel, Timezone, Uptime, Load Average, Disk Usage, Memory Usage.
+- **Hostname Settings** — change the server's FQDN. Restart the relevant services after a hostname change.
+- **Timezone Settings** — change the system timezone (affects cron timing, backup schedules, log timestamps).

 <Aside type="caution">
-  Restarting a service drops in-flight connections. For Apache and PHP-FPM, this means active web requests will fail to complete; for MySQL, in-flight transactions roll back. Pick a low-traffic window if you can.
+  Changing the hostname affects the certificates and DNS records that reference it. Plan for the related re-issuance and DNS propagation before changing it on a live server.
 </Aside>

-## Managing PHP modules and runtimes
+### Services

-WHP can run multiple PHP runtimes side-by-side (PHP 8.3, 8.4, etc.). With super admin you can:
+Service status and restart controls.

- Install additional PHP runtimes via the **PHP Versions** admin page.
- Add or remove extensions per runtime — common ones (mbstring, intl, opcache, imagick, redis, etc.) are toggles; less common ones may require a [support ticket](https://secure.anhonesthost.com/submitticket.php).
- Edit a runtime's `php.ini` from the **PHP Configuration** sub-page, then reload PHP-FPM to pick it up.
+- **Service Status** — health pills for the host-side services:
+  - **Apache** and **PHP-FPM** on the host serve the **WHP control panel itself**, not customer sites. Customer sites run inside their own per-site containers, separate from these host services.
+  - **Docker** — the host's Docker daemon. If this is down, no customer container will start.
+  - **ProFTPD** — host FTP service (used by FTP-enabled customer accounts).
+  - **Backup Upload** — the host-side uploader that streams backups to your configured backup targets.
+- **Restart Services** — checkboxes per service plus **Restart Selected Services**.
+- **Docker Container Management** — status of the core platform containers (Mysql, Haproxy manager, Memcache, Postgresql) and a per-container **Execute Operation** picker (e.g. restart a single container).

-Switching a site to a different PHP version is done on the customer side — open **Sites → your site** and pick from the **Container Type / PHP Version** dropdown. The runtimes available there come from this admin list.
+<Aside type="caution">
+  Restarting host Apache or PHP-FPM kicks the **control panel** offline briefly — customers can't sign in to WHP for a few seconds. It does **not** affect customer sites (those are in their own containers). For MySQL, in-flight transactions in the MySQL container roll back. Pick a quiet window when you can.
+</Aside>
+
+### Mail
+
+Two panels:
+
+- **Mail Server** — set the **Mail Server Hostname** (used for MX records on new domains and as the IMAP host for archival). Configure the Mail Server API (URL, Username, Password) that WHP uses to provision mailboxes. Toggle **Enable Mailserver API Debug Logging** when troubleshooting; it writes mailserver API requests/responses to the PHP error log.
+- **Outbound Email (SMTP)** — configure SMTP for outbound system alerts and customer AI Monitor notifications. Toggle **Enable Outbound Email** and provide the relay's credentials.
+
+### DNS
+
+Two panels:
+
+- **WHP Nameserver Configuration** — set the primary and secondary nameserver hostnames and IPs. These are baked into every customer's DNS zone, so changing them affects every domain you host.
+- **Network DNS Settings** — set the upstream resolvers the server uses (defaults to Cloudflare `1.1.1.1` and Google `8.8.8.8`).
+- **DNS Configuration Settings** — default TTL for new DNS records (60–86400 seconds).
+
+<Aside type="caution">
+  Changing nameserver hostnames or IPs invalidates the zone delegation for every customer domain pointed at the old values. Migrate slowly; expect lag in the order of TTL × propagation window.
+</Aside>
+
+### Network & SSL
+
+Operational controls for HAProxy and system-service certs:
+
+- **HAProxy Configuration Management** — **Regenerate** (rebuild config for every active site), **Reload** (apply config without restart), **Health Check** (probe HAProxy).
+- **HAProxy API Key** — Bearer token used to authenticate against the HAProxy Manager API. After rotating, restart the HAProxy container.
+- **System Service SSL Certificates** — request a Let's Encrypt cert for system-level services like the WHP panel itself and FTP, by picking the service and the domain name.
+
+<Aside type="caution" title="Panel SSL + HSTS — VM rebuild and cert change gotcha">
+
+  The WHP panel always sends `Strict-Transport-Security: max-age=31536000; includeSubDomains` on every HTTPS response. That header is part of the panel's defence-in-depth — once a browser has visited the panel over HTTPS, it will refuse to fall back to HTTP and will refuse to accept an untrusted certificate (no clickable "proceed anyway" escape).
+
+  **When this bites you:** any time the panel's certificate fingerprint changes for the **same hostname**. Most common cause: rebuilding the VM. A fresh `setup.sh` run regenerates the self-signed `/etc/pki/tls/certs/localhost.crt`. Your browser still has the year-long HSTS rule cached from the previous VM, so it refuses to connect to the new cert. Both Chrome and Firefox enforce HSTS at the browser level.
+
+  **Recovery options for the admin who's locked out of their own panel:**
+
+  1. **Use the IP directly instead of the hostname.** HSTS is scoped to host names, not IP addresses. Hit `http://<server-ip>:8080/` or `https://<server-ip>:8443/`, log in, then go straight to **Network & SSL → System Service SSL Certificates** and issue a real Let's Encrypt cert for the panel's hostname. Reload the page and the hostname URL works again.
+  2. **Clear the HSTS rule in your browser.**
+     - **Chrome / Edge:** `chrome://net-internals/#hsts` → *Delete domain security policies* → enter the panel hostname → *Delete*.
+     - **Firefox:** start a private window for the panel hostname, OR close Firefox, open `<profile>/SiteSecurityServiceState.txt`, and remove the line beginning with the panel hostname.
+  3. **Issue a real Let's Encrypt cert before the next rebuild.** Once `whp02.example.com` has a real cert that survives rebuilds (e.g., the LE private key is preserved across rebuilds, or the cert is re-issued as part of post-install automation), the HSTS rule has nothing to argue with.
+
+  Issuing a Let's Encrypt cert for the panel hostname is a first-day operation for every new server, and it's how you avoid having to recover from this scenario on rebuild #2.
+</Aside>
+
+### Security
+
+API keys for **external integrations** like WHMCS. Not customer-facing.
+
+- **Create New API Key** — Key Name, Rate Limit (requests per hour), Permissions (User Management, Resource Management, SSO Access, System Statistics, AI Monitor Management), an optional IP whitelist, and Notes.
+- **Existing API Keys** — list of issued keys with their permissions and rate limit. Revoke by removing the row.

 ## Server-wide configuration files

-For settings that aren't exposed in the panel, you can SSH to the server and edit configuration directly:
+The host runs the WHP control panel and orchestrates customer containers. Most customer-affecting configuration lives **inside** containers, not on the host. A short map:

- **Apache:** `/etc/httpd/conf.d/` for per-app drop-ins; per-site vhosts are generated from WHP and live in a directory the panel manages. **Don't** edit generated vhosts by hand — they'll be overwritten on the next config regeneration.
- **PHP-FPM pools:** `/etc/php-fpm.d/` for runtime pool tweaks. Pool defaults are templated by WHP; edits to per-site pools are overwritten on regeneration.
- **MySQL/MariaDB:** `/etc/my.cnf.d/`. The defaults are tuned for the server's resource profile; large-tweak changes are usually best left to a ticket so we can advise.
+- **Control-panel Apache:** `/etc/httpd/conf.d/` on the host configures the WHP panel's own Apache. Editing here changes how the panel serves; it doesn't change how customer sites serve.
+- **Control-panel PHP-FPM:** `/etc/php-fpm.d/` on the host configures the panel's PHP. Same scope.
+- **MySQL:** the MySQL instance runs as a container. Files under `/etc/my.cnf.d/` on the host are surfaced to customer database connections — they're effectively client-facing settings, not host settings.
+- **HAProxy:** runs as a container with its own volume. Reload via the **Network & SSL** tab; don't hand-edit files in the container.

-After editing, reload the relevant service from the WHP **Services** page (or via systemctl on the box).
+### Customer-side container customisation

-## Common admin tasks
+If a customer needs a non-standard runtime, library, or service inside their site's container — that's done by **building a custom Docker image** and adding it as a container type option in WHP, not by editing host-level config.

-**Drop a hot file cache.** From the **Services** page, click **Reload** on PHP-FPM. This is the right move after editing `php.ini` or an extension list.
+The pattern is documented in our cloud-container repos. See <a href="https://repo.anhonesthost.net/cloud-hosting-platform/">repo.anhonesthost.net/cloud-hosting-platform/</a> for the cloud-apache-container and cloud-node-container examples — they show the layout, build, and how to publish an image so it appears in the **Container Type** dropdown on the Sites page.

-**Free disk space on a full server.** Check `/var/log/` first — log rotation may be lagging. WHP rotates app logs into the per-site `logs/` directory; server-level logs in `/var/log` are yours to rotate via `logrotate` config in `/etc/logrotate.d/`.
-
-**See what's eating resources.** The admin **Resource usage** page shows aggregate CPU, RAM, disk I/O, and per-process drilldowns. For deeper inspection, SSH in and use `top`, `htop`, or `iotop`.
+<Aside type="tip">
+  Cloud container images are a one-time setup per stack you want to support. Once published, every site using that container type benefits automatically — no per-site shell access required.
+</Aside>

 ## Troubleshooting

-**Service won't restart.** The Services page surfaces the systemd error; if it's `failed (exit-code)`, check `journalctl -u <service>` on the box for the underlying message. The most common cause is a syntax error in a config file you just edited.
+**A service won't restart.** Check `journalctl -u <service>` (for systemd-managed services) or `docker logs <container>` (for containerized ones). The most common cause is a syntax error in a config file you just edited.

-**PHP module toggle has no effect.** PHP modules need a PHP-FPM **reload** to be picked up. The toggle should do this automatically; if it doesn't, click Reload manually.
+**Edits to a generated vhost keep disappearing.** That file is generated. Put your customisation in a per-app drop-in under `/etc/httpd/conf.d/`, or open a ticket about adding a stable include hook.

-**Edits to a generated vhost keep disappearing.** That file is generated. Put your customisation in a per-app drop-in under `/etc/httpd/conf.d/` instead, or open a ticket about adding a stable include hook.
+**Mailserver API debug log too noisy.** Toggle **Enable Mailserver API Debug Logging** off on the **Mail** tab once you've finished diagnosing.

 ## Related

@@ -1,94 +1,112 @@
 ---
-title: Site Monitoring rules
-description: Configure Site Monitoring across every site on the server — global ignore lists, alert routing, and severity tuning.
+title: AI Monitor, Issues & Ignore Rules
+description: The three admin pages that drive the Site Monitoring add-on — AI Monitor dashboard, Issues, and Ignore Rules.
 sidebar:
  order: 4
-  badge:
-    text: Draft
-    variant: caution
 ---

 import { Aside } from '@astrojs/starlight/components';
 import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
-import Draft from '~/content/partials/draft-callout.mdx';
-import SignIn from '~/content/partials/signing-in.mdx';
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
 import Support from '~/content/partials/support-link.mdx';

 <SuperAdmin />

-<Draft />
+[Site Monitoring](/whp/add-ons/monitoring/) is the customer-facing alerting add-on. The admin side exposes three pages — together they let you tune what gets monitored, what surfaces as a customer-visible issue, and what gets suppressed.

-[Site Monitoring](/whp/add-ons/monitoring/) is the customer-facing alerting product. With super admin access, you can manage the rules that drive those alerts at the server level — including a server-wide ignore list, alert routing, and severity tuning.
+## Sign in as super admin

-## Sign in to WHP
+<AdminSignIn />

-<SignIn />
+## AI Monitor (admin dashboard)

-## Where it lives
+Sidebar → **AI Monitor → Dashboard**. The operational heartbeat of the whole monitoring pipeline.

-Sidebar → **Site Monitoring** (admin view). The page shows two perspectives:
+![AI Monitor admin dashboard](~/assets/screenshots/whp/admin-monitor-admin.png)

- **Customer feed** — what your site owners see when they sign in.
- **Admin tools** — the rule library, global ignore list, and alert configuration.
+Panels:
+
+- **AI Log Monitor Status** — overall on/off plus three sub-statuses:
+  - **Minute-cadence poll** — the cron that scans logs every minute.
+  - **Health API** — the internal API that exposes per-container health.
+  - **HAProxy stats** — the proxy stats feed used for error-rate tracking.
+- **Stat tiles** — Last Run, Errors Tracked, Remediations, API Calls Today (with a rate-limit denominator).
+- **Health Check Timeline (last 7d)** — every state transition (`cpu`, `swap`, `haproxy`, etc.) with its severity and an **AI Diagnosis** explanation.
+
+Use this page to confirm the pipeline is healthy and to drill into recent state changes. The AI Diagnosis text gives a plain-language summary of *why* a transition happened — useful for context before you act.
+
+## Issues
+
+Sidebar → **AI Monitor → Issues**. The customer-visible findings, server-wide.
+
+![Issues page](~/assets/screenshots/whp/admin-issues.png)
+
+Four stat tiles at the top:
+
+- **Critical** — open critical-severity issues.
+- **Warning** — open warning-severity issues.
+- **Auto-resolved (review)** — issues the monitor closed on its own that may still need a human glance.
+- **Active suppressions** — issues currently muted by an Ignore Rule.
+
+Filter row: Scope (All / specific user), Status (Open / Closed / All), Severity, Source, Signature prefix.
+
+Bulk actions: **Mark Fixed**, **Ignore**, **Delete**.
+
+Each row has its own quick-actions: **Fix** (close it) and **Ignore** (create an ignore rule from this row's match criteria).
+
+## Ignore Rules
+
+Sidebar → **AI Monitor → Ignore Rules**. Match criteria that prevent matching findings from becoming customer-visible issues.
+
+![AI Monitor Ignore Rules page](~/assets/screenshots/whp/admin-ignore-rules.png)
+
+Each rule has these fields:
+
+- **Scope** — `user` (just one customer) or `global` (every customer).
+- **Target** — the user or domain the rule applies to.
+- **Match** — a comma-separated set of `field=value` predicates (e.g. `cat=degraded & title~"Beaver Builder cache files missing"`). Match fields combine with **AND** semantics — every predicate must match.
+- **Reason** — a short note for future-you explaining why the rule exists.
+- **Hits / Last hit** — how often the rule has matched, and when.
+- **Enabled** — toggle without deleting.
+
+<Aside type="tip">
+  Prefer **per-user** ignores over global. Global rules silence the finding for everyone on the server.
+</Aside>

 ## Common tasks

-### Add a global ignore rule
+### Mute a known-noisy finding for one customer

-When a signature is noisy for every site (for example, a known scanner you allow on your own infrastructure):
+1. Open **Issues**, find the row.
+2. Click the row's **Ignore** action — that pre-fills an Ignore Rule with the matching criteria scoped to that user.
+3. Add a **Reason** so future-you (or someone else on the team) understands why it exists.
+4. Save. Future matching findings will be suppressed; the **Active suppressions** tile will tick up.

-1. Open **Site Monitoring → Global Ignore Rules**.
-2. Click **Add Rule**.
-3. Define the match condition (rule_id, source IP/CIDR, URL pattern, or a combination).
-4. Add a short note so future-you remembers why this exists.
-5. Save. Matching events stop firing alerts immediately.
+### Investigate an "Auto-resolved (review)" issue

-<Aside type="caution">
-  Global ignore rules silence every site on the server. Prefer per-site ignore (set in the customer-facing Site Monitoring page) when the noise is site-specific.
-</Aside>
+These are issues where the underlying signal recovered before a human looked at them. Open the row to see the AI Diagnosis and the original detection. If the resolution looks legitimate, click **Mark Fixed**; if you're suspicious, leave it open and add a comment for context.

-### Tune severity for a rule
+### Tune brute-force detection

-If a rule is set to **critical** but you've decided it's really informational in your environment:
+Brute-force rules live in **Coraza Rules** (rule families CRS-913 / 921 / 942 / 949) rather than AI Monitor. AI Monitor surfaces the *effects* (error spikes) once a brute-force pattern fires, but the matching itself is in the WAF — see [Coraza WAF rules](/whp/admin/coraza-waf/).

-1. Find the rule in **Site Monitoring → Rules**.
-2. Open the rule and change its severity to one of: informational / warning / critical.
-3. Save. The severity change applies to new events from that rule.
+## Routing alerts

-Severity matters because **SMS notifications fire only on critical**. Downgrading from critical to warning silences SMS without silencing the rule.
-
-### Route alerts somewhere other than the default
-
-Default routing: alerts go to the contact email on the account. You can:
-
- **Add additional email recipients** — useful for a shared ops alias.
- **Enable SMS for critical alerts** — wire your phone number on the **Alert Routing** page.
- **Forward to a webhook** — for integration with Slack, PagerDuty, or your own incident pipeline.
-
-## Brute-force detection
-
-Brute-force detection is a separate rule family and has its own per-site sensitivity. From the admin view, you can adjust:
-
- The window in which repeated failures count.
- The threshold at which the rule fires.
- Whether the rule auto-blocks the source IP (recommended) or only alerts.
-
-## Things to know
-
- **Ignore lists don't stop logging.** They only suppress alerts. The events still appear in the audit feed so you can see what's actually happening.
- **Rules apply on the next log scan**, typically within a minute.
- **A muted rule for one customer doesn't affect others.** Per-site ignore is scoped tightly.
+Customer email alerts are sent via the SMTP relay configured on **Server Settings → Mail → Outbound Email (SMTP)**. Toggle **Enable Outbound Email** off there if you need to silence outbound notifications for a maintenance window.

 ## Troubleshooting

-**No alerts arriving for a known event.** Check the **Global Ignore Rules** list and any per-site ignores. Also confirm the rule's severity isn't set to informational (no email or SMS by default).
+**Pipeline shows "stale" — Last Run more than a few minutes ago.** Check the cron's container on **Server Settings → Services → Docker Container Management**. The monitor poll is `whp-monitor-poll`.

-**SMS not firing on critical.** Confirm SMS is enabled in **Alert Routing** and the phone number is verified.
+**Issues appearing for a known noisy site.** Add an Ignore Rule scoped to that user.
+
+**No customer alerts arriving.** Confirm Outbound Email is enabled and the SMTP relay is reachable from the server.

 ## Related

- [Site Monitoring add-on](/whp/add-ons/monitoring/) — what the customer sees.
- [Coraza WAF rules](/whp/admin/coraza-waf/) — request-level firewall, complements monitoring.
+- [Site Monitoring add-on](/whp/add-ons/monitoring/) — the customer-facing side.
+- [Coraza WAF rules](/whp/admin/coraza-waf/) — request-level firewall.
+- [Server settings & services](/whp/admin/server-settings/) — SMTP relay config for outbound alerts.

 ## Still stuck?

@@ -1,95 +1,144 @@
 ---
 title: Users & delegated access
-description: Create sub-users, delegate panel access, and manage SFTP/SSH users at the server level.
+description: Create WHP users, set account types, change passwords, plus delegated user access and account suspensions.
 sidebar:
  order: 5
-  badge:
-    text: Draft
-    variant: caution
 ---

 import { Aside } from '@astrojs/starlight/components';
 import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
-import Draft from '~/content/partials/draft-callout.mdx';
-import SignIn from '~/content/partials/signing-in.mdx';
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
 import Support from '~/content/partials/support-link.mdx';

 <SuperAdmin />

-<Draft />
+Four admin pages collectively control who can sign in and what they can do on the server:

-WHP super admin lets you give other people scoped access to the server — your dev team, a contractor, or a junior admin — without sharing your own credentials.
+- **User Management** — create / change-password / delete WHP users.
+- **User Resources** — set CPU / RAM / disk allowances per user.
+- **Delegated Users** — list of contractor / sub-account grants on customer sites.
+- **Account Suspensions** — suspended accounts.

-## Three kinds of access
+## Sign in as super admin

-| Type                | What they can do                                                                 | Where they sign in                      |
-| ------------------- | -------------------------------------------------------------------------------- | --------------------------------------- |
-| **WHP sub-user**    | Sign in to WHP with their own credentials. You control which sections they see.  | Same `:8443` URL as you.                |
-| **Delegated panel access** | A read-only or scoped-write view onto a specific site, for a contractor. | Same WHP, but scoped to that one site.  |
-| **SFTP / SSH user** | File access (and optionally SSH) without WHP at all.                             | SFTP client / SSH terminal.             |
+<AdminSignIn />

-## Sign in to WHP
+## User Management

-<SignIn />
+Sidebar → **User Management**.

-## Create a WHP sub-user
+![WHP User Management page](~/assets/screenshots/whp/admin-user-mgmt.png)
+
+### Create New User
+
+Every user created here is a **customer account**, not a super admin. (Super admin is the `root` user on the server, and there's no UI to add another.)
+
+Fields:
+
+- **Username** — UNIX-safe username; also becomes the SFTP user and home-directory name (`/docker/users/<username>`).
+- **Password** — strong password. The user can change it later from the panel.
+- **Account Type** — pick the scope of features this customer should see:
+  - **Full Hosting** — sites, databases, domains, DNS, email. The default for normal customers.
+  - **Domain/DNS Only** — domains and DNS records only (no sites, databases, or email).
+  - **Mail/DNS Only** — email plus domains/DNS (no sites or databases).
+
+Click **Create User** to provision the account. The user's home directory and SFTP credentials are set up immediately.

 <Aside type="tip">
-  WHP sub-users are the right model when someone needs to manage parts of the server alongside you. Use **delegated access** instead if they only need one site, or **SFTP/SSH** if they only need files.
+  Pick the smallest account type that does the job. You can change it later from the **Actions** column in the user list.
 </Aside>

-1. Open **Users → WHP Users → Add User** in the admin sidebar.
-2. Set a username, a strong password, and an email (used for password reset and 2FA).
-3. Choose a **role**: pick from the predefined roles (Admin, Site Manager, Read-only, etc.) or build a custom role with specific pages enabled.
-4. (Optional) Enable **Require 2FA** so they have to set up an authenticator app on first login.
-5. Save. Share the credentials with them out-of-band; don't email passwords.
+### Change User Password

-## Delegated access for a single site
+Pick the user from the dropdown, enter a new password, click **Change Password**. The user is forced to sign in again on next visit; any in-flight panel sessions are still live until you also revoke them via **Active Sessions**.

-Use the customer-facing **Delegated Users** page (sidebar → **Delegated Users**, available on every account) when a contractor only needs to work on one site:
+### User Accounts table

-1. Open **Delegated Users → Add**.
-2. Pick the site they should have access to.
-3. Set their permission scope: view-only, manage-files, manage-DNS, etc.
-4. Send them the panel URL. They sign in with their own credentials and see only that site.
+Columns: **Username**, **UID** (UNIX uid), **Account Type**, **Home Directory**, **Actions** (Account-Type dropdown + Delete).

-This is the right path for, say, a freelance designer who needs to upload assets but shouldn't see your other sites or your DNS.
+To change a user's account type, change the dropdown in the row and the change applies immediately. The **System** badge on a row marks an internal/system user (such as `root`, `whp`, `daemon`, `www-data`, `nobody`, the various `systemd-*` users, etc.).

-## SFTP / SSH users
-
-Pure file access without WHP. Created from the admin **Users → SFTP/SSH** page:
-
-1. Open **Users → SFTP/SSH → Add**.
-2. Set the username, password (or paste their public SSH key), and which directories they have access to.
-3. Pick whether to grant interactive SSH or restrict to SFTP only.
-4. Save. They can now connect with their preferred SFTP/SSH client.
+**System users are protected.** The panel refuses to delete any user on the protected list — `delete_user` in `web-files/libs/usermgmt.php` checks `is_protected_user($username)` first and returns *"Cannot delete protected system user"* without touching the OS user. Password changes are blocked the same way, with one exception: `root`'s password can be changed (the rest of the protected list cannot).

 <Aside type="caution">
-  Interactive SSH is powerful — anyone with it can run arbitrary commands inside the container or VM. Restrict to SFTP-only unless they specifically need a shell.
+  Deleting a non-system user removes their home directory and every site, database, and mailbox associated with them. There is no undo. Use **Account Suspensions** instead for temporary disablement.
 </Aside>

-## Managing existing users
+## User Resources

-The user list shows last sign-in, role, and 2FA status. Common actions from each user's row:
+Sidebar → **User Resources**. Configure CPU and memory allowances per user.

- **Disable** — keeps the user but blocks sign-in.
- **Delete** — removes the user.
- **Force password reset** — invalidates their current password; they receive an email link.
- **Revoke sessions** — kicks them out of any active panel sessions immediately.
+![User Resources admin page](~/assets/screenshots/whp/admin-user-resources.png)

-When someone leaves your team, **revoke sessions first** (so they're out *now*), then disable or delete the user.
+Each row shows current allocation vs. usage:
+
+- **Max CPU** / **CPU Used** — in 0.25-core increments.
+- **Max Mem** / **Mem Used** — in 256 MB increments.
+- **Disk** / **Used** — total disk allocation and current consumption (with %).
+- **Email** — mailbox slot count.
+- **Mail MB** — total mail storage cap.
+- **Arch.** — archival email slots used / total.
+- **Cont.** — currently-running container count.
+
+Use the **Actions** column to edit a user's caps. Changes apply on the next container restart for that user's sites.
+
+<Aside type="note">
+  Memory-usage tracking isn't available in some Docker environments. The **Active sites** count reflects running containers.
+</Aside>
+
+## Delegated Users
+
+Sidebar → **Delegated Users**. Customers can use the Delegated Users page on their own account to grant a contractor scoped access to one of their sites. The admin view shows every active delegation across the server.
+
+From the admin view you can:
+
+- **Audit** — see who has cross-account access at a glance.
+- **Edit** — modify scope, permissions, or expiry on any delegation for an independent customer. Useful when a customer asks support to fix a grant they set up incorrectly.
+- **Revoke** — remove a delegation outright.
+
+If a customer reports a delegation issue, this page is where you confirm the grant exists, inspect its scope, and adjust it on their behalf.
+
+## Account Suspensions
+
+Sidebar → **Account Suspensions**. The list of suspended customer accounts.
+
+A suspension takes a customer's sites offline without deleting any data — the customer can be reinstated by removing the suspension. Useful for non-payment, terms-of-service issues, or maintenance hold.
+
+The page lists who's suspended, when, by whom, and why. Reinstate from the action button on each row.
+
+### How the suspension page is served
+
+The "site suspended" page is served by **HAProxy** itself, not by a separate backend. When you suspend an account, WHP rewrites the HAProxy config to point that account's frontends at a 503 errorfile (`/usr/local/etc/haproxy/errors/503.http`) and reloads HAProxy.
+
+**If a suspended site is still serving the real content** (or is throwing a network error instead of the suspended page), it almost always means HAProxy didn't pick up the config reload. Check, in order:
+
+1. **HAProxy container is running.** **Server Settings → Services → Docker Container Management** → confirm `Haproxy manager` shows **Running**.
+2. **HAProxy reload succeeded.** Either re-trigger from **Server Settings → Network & SSL → Reload Configuration**, or check the HAProxy container logs (`docker logs haproxy-manager`) for a reload error — usually a syntax error in the generated config from the suspension action.
+3. **Errorfile is in place.** The 503 page lives at `/usr/local/etc/haproxy/errors/503.http` inside the container.
+
+## Active Sessions
+
+Sidebar → **Active Sessions**. Every active panel session across the server, with last activity time, IP, and a **Terminate** button. Use this when offboarding someone — kick them out of any active sessions *first*, then change their password or delete the user.
+
+## When someone leaves your team
+
+1. **Revoke active sessions** for that user via **Active Sessions**.
+2. **Change their password** in **User Management** (locks them out even if they save their cookies).
+3. **Downgrade or delete** the user in **User Management**.
+4. Audit **Delegated Users** for any cross-account delegations that should also be revoked.

 ## Troubleshooting

-**Sub-user can sign in but the page they expect is missing.** Their role doesn't include that section. Edit the role and tick the right page.
+**"Cannot delete protected system user".** Expected — system users (root, daemon, www-data, mail, the `systemd-*` users, etc.) are blocked at the panel level to prevent breaking the host. If you really need to remove a user, confirm it's a customer account first.

-**SFTP user can connect but uploads land in the wrong directory.** Check their **Home directory** in the SFTP/SSH user page — it determines what they see as `/`.
+**Created user can't sign in.** Confirm the password meets the strength rules. If the user is signing in for the first time, they may be hitting the password-change-on-first-login flow.

-**A delegated user can't see DNS records.** Delegated access defaults to file-only. Edit their permissions to include DNS Management.
+**Suspended customer's sites are still serving real traffic.** The suspension page is served by HAProxy — see "How the suspension page is served" above. Most often it's an HAProxy reload that didn't happen; check the container logs.

 ## Related

- [Server settings & services](/whp/admin/server-settings/)
+- [Server settings & services](/whp/admin/server-settings/) — including the suspension backend service.
+- [AI Monitor, Issues & Ignore Rules](/whp/admin/site-monitoring/)

 ## Still stuck?

@@ -41,7 +41,10 @@ A [Virtual Dedicated Server](https://anhonesthost.com/vds) is our VPS-class prod

 A VDS suits you when you want full admin control of the server — kernel-level tweaks, custom services, your own systemd units, or you simply prefer to manage the OS yourself. You get a real virtual machine with root access, and WHP still gives you the friendly panel on top.

+A VDS also opens up server-wide options that don't apply to shared containers, like opt-in [data-drive encryption](/whp/admin/data-drive-encryption/) for compliance or peace-of-mind scenarios.
+
 ## Related

 - [Add-ons overview](/whp/add-ons/overview/)
 - [Service hostnames](/whp/reference/service-hostnames/)
+- [Data-drive encryption (LUKS)](/whp/admin/data-drive-encryption/) — optional, new-server-only
@@ -27,24 +27,25 @@ import Support from '~/content/partials/support-link.mdx';

 <Steps>

-1. In the sidebar, click **Domains**.
-   ![WHP Domains page](~/assets/screenshots/whp/whp-domains.png)
+1. In the sidebar, click **Domains & DNS**. You'll see a searchable list of the domains on your account.
+   ![WHP Domains & DNS page](~/assets/screenshots/whp/whp-domains.png)

-2. Under **Add New Domain** on the left, type your domain (for example, `example.com`). Don't include `http://` or `www.` — just the bare domain.
+2. Click **Add Domain** in the top right. In the dialog, type your domain (for example, `example.com`) — just the bare domain, with no `http://` or `www.`
+   ![Add Domain dialog](~/assets/screenshots/whp/whp-dns-add-domain.png)

-3. Click **Add Domain**.
+3. Click **Add Domain** to confirm. The domain appears in the list with a green **Active** status.

 </Steps>

-WHP creates the standard set of DNS records automatically for the new domain:
+WHP creates a DNS zone with the standard set of records automatically for the new domain:

 - **A record** for the apex domain → your server's IP
 - **CNAME** for `www` → the apex
 - **NS records** for the nameservers
 - **MX record** → the mail server
- **TXT record** for SPF
+- **TXT records** for SPF and DKIM

-You can review and tweak any of these from the **DNS Management** panel on the right side of the Domains page (select the domain from the dropdown).
+You can review and tweak any of these — click **Manage DNS** next to the domain to open the records editor. See [Manage DNS records](/whp/how-to/manage-dns-records/) for the full walkthrough.

 ## Point your DNS at us

@@ -54,7 +55,7 @@ There are two paths depending on where the domain is registered:

 **Registered elsewhere.** At your registrar, do one of the following:

- Set the **nameservers** to the values shown on the Domains page (recommended — gives us full DNS control, easier to support), **or**
+- Set the **nameservers** to the values shown in **Manage DNS** (the **NS** records) — recommended, as it gives us full DNS control and is easier to support — **or**
 - Keep your existing nameservers and add an **A record** pointing the domain to the IP shown on the **Dashboard** page under Server Information.

 ## Verify it worked
@@ -76,6 +77,7 @@ Once DNS resolves, visiting your domain in a browser will reach WHP — though y

 ## Related

+- [Manage DNS records](/whp/how-to/manage-dns-records/)
 - [Create a site](/whp/how-to/create-a-site/)

 ## Still stuck?
@@ -2,14 +2,14 @@
 title: Backups
 description: Run on-demand and scheduled backups of your sites and databases, and confirm they're succeeding.
 sidebar:
-  order: 4
+  order: 5
 ---

 import { Steps, Aside } from '@astrojs/starlight/components';
 import SignIn from '~/content/partials/signing-in.mdx';
 import Support from '~/content/partials/support-link.mdx';

-WHP keeps automatic backups of your sites and databases. The **Backup Management** page lets you trigger an on-demand backup, add a scheduled backup, manage where backups are sent, and review history.
+The **Backup Management** page lets you trigger an on-demand backup, add a scheduled backup, manage where backups are sent, and review history.

 ## What's backed up

@@ -18,6 +18,10 @@ WHP keeps automatic backups of your sites and databases. The **Backup Management

 Default retention on built-in backup targets is **5 days, up to 10 backups**.

+<Aside type="note">
+  Automatic backups only run once the server admin has configured at least one **default backup target**. On our managed shared plans this is set up for you. On a VDS, the server operator picks the target — until they do, the **Backup Targets** table on your Backups page will be empty and you won't see scheduled backups firing.
+</Aside>
+
 ## Sign in to WHP

 <SignIn />
@@ -83,6 +87,14 @@ Don't do a full restore unless you genuinely need to — it rewrites your live s

 **"No targets available" when starting a backup.** Your account has no backup targets attached. Open a ticket; we'll get one wired up.

+## What's *not* in customer backups
+
+Customer backups cover your sites and databases — they don't cover the underlying server, the OS, or system-level config. Full-server backups are a separate concern:
+
+- On our managed plans, **AnHonestHost handles full-server backups** for the host.
+- On a Virtual Dedicated Server (VDS) we provide, **full-server snapshots are included** at the platform level.
+- If WHP is running somewhere else (your own infrastructure), full-server backups are the server operator's responsibility — WHP itself doesn't provide a host-level backup tool.
+
 ## Related

 - [Archival email add-on](/whp/add-ons/archival-email/)
@@ -0,0 +1,71 @@
+---
+title: Clear your site's cache
+description: Seeing an old version of a page after making a change? Here's how to clear cached content so your updates show up.
+sidebar:
+  order: 7
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+If you've changed something on your site but still see the old version — an updated page, a new image, a price, a published post — it's almost always **caching**: a saved copy of the page is being shown to make your site fast. Clearing the cache tells the system to build a fresh copy.
+
+There are two places a saved copy can live: in **your browser**, and on the **server** (if your site uses our [Optimized Webserver](/whp/add-ons/optimized-webserver/) add-on with LiteSpeed Cache). Work through the steps below in order — the first one fixes most cases.
+
+<Aside type="note">
+  When you're **logged in** to WordPress, we never serve you a cached page — you always see your site exactly as it is right now. So if a change looks missing while you're logged in, it's almost certainly your browser holding an old copy. Start with a hard refresh.
+</Aside>
+
+## Start with a hard refresh
+
+A normal refresh often reloads the page from your browser's own saved copy. A *hard* refresh forces your browser to fetch everything fresh from the server.
+
+<Steps>
+
+1. Open the page that looks out of date.
+
+2. Do a hard refresh:
+   - **Windows / Linux:** press `Ctrl` + `Shift` + `R`
+   - **Mac:** press `Cmd` + `Shift` + `R`
+
+3. Still seeing the old version? Open the same page in a **private / incognito window** (which ignores your browser cache entirely). If it looks correct there, the issue was just your browser — clear your browser cache and you're done.
+
+</Steps>
+
+## Purge the server cache
+
+If your site is on the **Optimized Webserver** add-on, pages are also cached at the server by LiteSpeed Cache. Most of the time this clears itself automatically — publishing a post, updating a page, or completing an order purges the right pages for you. Occasionally (after a large change, a theme edit, or a bulk update) you may want to clear it by hand.
+
+For WordPress sites, you do this from the free **LiteSpeed Cache** plugin:
+
+<Steps>
+
+1. Sign in to your site's **WordPress admin** (`yourdomain.com/wp-admin`).
+
+2. In the left menu, go to **LiteSpeed Cache → Toolbox**.
+
+3. On the **Purge** tab, click **Purge All**. This drops every cached page; the next visitor to each page gets a freshly built copy.
+
+</Steps>
+
+<Aside type="tip">
+  There's also a shortcut in the black toolbar at the top of every WordPress admin page: the **LiteSpeed Cache** menu has a **Purge All** option you can use without leaving the page you're on.
+</Aside>
+
+<Aside type="caution">
+  The very first visit to each page after a purge runs at normal (uncached) speed while the fresh copy is built — then it's fast again. Don't judge your site's speed on that first load right after purging.
+</Aside>
+
+## If that didn't fix it
+
+- **Your site isn't WordPress**, or you don't have the LiteSpeed Cache plugin — there's nothing for you to purge directly. Contact us and we'll clear the server-side cache for you.
+- **You purged everything and still see the old version** — give it a moment and try a hard refresh again. If it persists, it may not be a cache issue at all (for example, a change that didn't actually save, or a content/plugin problem). Reach out and we'll take a look.
+
+## Related
+
+- [Optimized Webserver (OpenLiteSpeed + LSCache)](/whp/add-ons/optimized-webserver/) — what the server-level cache is and how to enable it.
+- [Switching a site's backend](/whp/how-to/switching-site-backend/)
+
+## Still stuck?
+
+<Support />
@@ -2,7 +2,7 @@
 title: Create a site
 description: Spin up a containerized site on a domain you've added to WHP.
 sidebar:
-  order: 2
+  order: 3
 ---

 import { Steps, Aside } from '@astrojs/starlight/components';
@@ -2,7 +2,7 @@
 title: Create an email account
 description: Add a mailbox on one of your domains and connect your email client.
 sidebar:
-  order: 3
+  order: 4
 ---

 import { Steps, Aside } from '@astrojs/starlight/components';
@@ -23,20 +23,52 @@ import Support from '~/content/partials/support-link.mdx';

 <Steps>

-1. In the sidebar, click **Email**.
-   ![WHP Email Management page](~/assets/screenshots/whp/whp-email.png)
+1. In the sidebar, click **Email**. The page is organized into tabs — **Email Accounts**, **Forwarders**, and **Email Domains (DNS)** — and opens on **Email Accounts**. The buttons along the top (**Webmail**, **Admin Panel**, **Setup Instructions**) open the mail server's web tools in a new tab.
+   ![The WHP Email page on the Email Accounts tab, showing the tab bar and the top access buttons](~/assets/screenshots/whp/whp-email.png)

-2. Scroll to **Email Accounts** and use the form to create a new account on one of your domains. You'll be asked for the domain, the local part, a password, and an optional mailbox size cap.
+2. On the **Email Accounts** tab, click **Create Email Account** to open the new-account form. You'll be asked for the domain, the local part, a password, and an optional mailbox size cap.

 3. Set a **strong password** — at least 12 characters with a mix of upper case, lower case, numbers, and symbols. Email accounts are common attack targets.

-4. Click **Create**. The new account appears in the **Email Accounts** list.
+4. Click **Create Account**. The new account appears in the **Email Accounts** list.

 </Steps>

+## Auto-configure your mail app
+
+Most modern mail apps — Outlook, Apple Mail, Thunderbird, and the iOS and Android mail apps — can set themselves up from your domain's DNS. You enter your **full email address** and **password**, and the app finds the right servers, ports, and security settings on its own.
+
+**If your domain uses our nameservers, this already works** — we add the necessary records automatically when you add the domain, so there's nothing for you to do.
+
+### If your DNS is hosted elsewhere
+
+If your domain's DNS lives at another provider (Cloudflare, GoDaddy, Namecheap, and so on), your mail app can't auto-configure until you add a few records there yourself. The Email page builds the exact records for you: open the **Email Domains (DNS)** tab, find **Autodiscovery Records (DNS)**, pick the domain, and copy them in.
+
+![The Autodiscovery Records (DNS) section on the Email Domains (DNS) tab, showing autodiscovery DNS records for a domain](~/assets/screenshots/whp/whp-email-autodiscovery.png)
+
+Add these records to the domain's zone at your DNS provider. The names are **relative to your domain** — most providers fill in the rest automatically, so `autoconfig` becomes `autoconfig.example.com`.
+
+| Type | Name | Priority | Weight | Port | Value |
+| --- | --- | --- | --- | --- | --- |
+| CNAME | `autoconfig` | — | — | — | your mail server |
+| SRV | `_autodiscover._tcp` | 0 | 0 | 443 | your mail server |
+| SRV | `_imaps._tcp` | 0 | 1 | 993 | your mail server |
+| SRV | `_submission._tcp` | 0 | 1 | 587 | your mail server |
+| SRV | `_pop3s._tcp` | 0 | 1 | 995 | your mail server |
+
+Use the **mail server hostname shown in the Autodiscovery Records (DNS) section** as the value — it's the same host your **MX** record points at. The `_pop3s` record is only needed if you read mail over POP3 instead of IMAP. Click **Copy records** to grab them all at once in zone-file format.
+
+<Aside type="tip">
+  If your provider has a proxy toggle (such as Cloudflare's orange cloud), keep these records **DNS only** — proxying them stops mail clients from reading them.
+</Aside>
+
+<Aside type="note">
+  These records only help apps *find* the server. You still create the mailbox in WHP first, and your domain's **MX** record must point at our mail server for mail to be delivered.
+</Aside>
+
 ## Set up your email client

-The exact IMAP, POP3, and SMTP hostnames are listed on the Email page — click **Setup Instructions → View Instructions** under **Mail Server Access** for a step-by-step that includes the right hostnames, ports, and security settings for your server.
+Most apps configure themselves from the records above once you enter your address and password. If yours doesn't support that — or you'd rather enter the settings by hand — the exact IMAP, POP3, and SMTP hostnames are listed on the Email page: click **Setup Instructions** at the top of the page for a step-by-step that includes the right hostnames, ports, and security settings for your server.

 The typical settings look like this; substitute the hostname shown in the Setup Instructions:

@@ -50,33 +82,35 @@ IMAP (incoming)

 SMTP (outgoing)
  Host:     <see Setup Instructions>
-  Port:     587
-  Security: STARTTLS
+  Port:     465
+  Security: SSL/TLS
  Username: full email address
  Password: same as IMAP
 ```

+For outgoing mail, **port 465 with SSL/TLS** is the standard. If your client prefers STARTTLS, **port 587** is the alternate submission port. (Don't use port 25 from a mail client — it's for server-to-server delivery and most networks block it.)
+
 For per-client walkthroughs (Outlook, Apple Mail, Thunderbird, etc.), see the Email clients section — coming soon.

 ## Webmail

-Click **Webmail Access → Open Webmail** on the Email page to sign in to webmail in a new tab.
+Click **Webmail** at the top of the Email page to sign in to webmail in a new tab.

 ## Verify it worked

 Send yourself a test message from another account (your personal Gmail, for example). It should arrive within a minute or two and be retrievable from both your client and webmail.

 <Aside type="caution">
-  **SPF and DKIM records matter.** Without them, your outgoing mail will get flagged or rejected by other providers. We add an SPF record automatically when you add a domain. DKIM records are listed in the **DKIM Records** section near the bottom of the Email page — make sure they're present at your registrar if the domain isn't using our nameservers.
+  **SPF and DKIM records matter.** Without them, your outgoing mail will get flagged or rejected by other providers. We add an SPF record automatically when you add a domain. DKIM records are listed in the **DKIM Management** section on the **Email Domains (DNS)** tab — make sure they're present at your registrar if the domain isn't using our nameservers.
 </Aside>

 ## Troubleshooting

-**Webmail isn't reachable.** DNS for the mail subdomain may still be propagating — wait an hour and try again.
+**Webmail isn't reachable.** Webmail is hosted at our address — the **Webmail** button on the Email page opens it directly — so it doesn't depend on your domain or its DNS. If it doesn't load, it's almost always a temporary connection issue: try again in a few minutes or from another network, and open a support ticket if it persists.

-**Outgoing mail is bouncing or going to spam.** Check the SPF and DKIM records. The DKIM Records panel on the Email page shows whether DKIM is configured for each of your domains.
+**Outgoing mail is bouncing or going to spam.** Check the SPF and DKIM records. The **DKIM Management** section on the **Email Domains (DNS)** tab shows whether DKIM is configured for each of your domains.

-**Client can connect on IMAP but not SMTP.** Some ISPs and corporate networks block outgoing port 587. Try sending from a different network to confirm; if the issue is your network, your ISP is the place to ask.
+**Client can connect on IMAP but not SMTP.** Some ISPs and corporate networks block outgoing mail ports. If sending fails on port 465, try the alternate submission port **587** (STARTTLS); if both fail, test from a different network to confirm it's your network, and if so, your ISP is the place to ask.

 ## Related

@@ -0,0 +1,119 @@
+---
+title: Manage DNS records
+description: View, add, edit, and delete DNS records for your domains using the Domains & DNS records editor in WHP.
+sidebar:
+  order: 2
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import SignIn from '~/content/partials/signing-in.mdx';
+import Support from '~/content/partials/support-link.mdx';
+
+When we host your DNS, WHP gives you a full records editor — add, edit, or remove **A**, **CNAME**, **MX**, **TXT**, and other records yourself, no support ticket needed.
+
+## Before you start
+
+- A domain already added to your account. If you haven't done that yet, [add a domain](/whp/how-to/add-a-domain/) first.
+- We must be running DNS for the domain (its nameservers point at us). If your DNS lives at another provider, make these changes there instead.
+- A couple of minutes. Record changes apply quickly on our side, but can take up to 24 hours to propagate worldwide.
+
+## Sign in to WHP
+
+<SignIn />
+
+## Open the records editor
+
+<Steps>
+
+1. In the sidebar, click **Domains & DNS**.
+   ![WHP Domains & DNS page](~/assets/screenshots/whp/whp-domains.png)
+
+2. Find your domain in the list and click **Manage DNS**.
+   ![DNS records editor for a domain](~/assets/screenshots/whp/whp-dns-records.png)
+
+</Steps>
+
+Each domain starts with a standard zone created automatically when the domain was added:
+
+| Type | What it's for |
+| --- | --- |
+| **A** | Points the apex domain at your server's IP. |
+| **CNAME** | Aliases like `www` and `autoconfig` to the right host. |
+| **MX** | Routes mail for the domain to our mail server. |
+| **TXT** | SPF and DKIM records that help your mail pass authentication. |
+| **NS** | The nameservers that are authoritative for the domain. |
+| **SRV** | Service records such as mail autodiscovery. |
+
+<Aside type="caution">
+  Editing **MX**, **NS**, or the SPF/DKIM **TXT** records can break email delivery or hand DNS control away from us. Only change these if you know exactly what you're doing.
+</Aside>
+
+## Mail autodiscovery records
+
+When we host your DNS, the records that let mail apps configure themselves — an `autoconfig` CNAME plus a set of `_autodiscover` / `_imaps` / `_submission` / `_pop3s` **SRV** records — are already in your zone. You don't need to add them.
+
+If your DNS is at another provider, add them there by hand. WHP builds the exact records for each domain on the **Email** page — see [Auto-configure your mail app](/whp/how-to/create-an-email-account/#auto-configure-your-mail-app).
+
+## Add a record
+
+<Steps>
+
+1. Click **Add Record**. A new, editable row appears at the top of the table.
+   ![Inline Add Record row](~/assets/screenshots/whp/whp-dns-add-record.png)
+
+2. Fill in the row:
+   - **Type** — choose the record type (A, AAAA, CNAME, MX, TXT, NS, PTR, SRV, CAA, SSHFP, or TLSA).
+   - **Name** — the host the record applies to. Use `@` for the domain itself, or a subdomain like `blog` for `blog.example.com`.
+   - **Content** — the value: an IP for an A record, a hostname for a CNAME, and so on.
+   - **Prio** — only used by record types that need a priority (like MX). Leave it blank otherwise.
+   - **TTL** — how long resolvers may cache the record, in seconds. The default of `300` (5 minutes) is fine for most records.
+
+3. Click **Save**. The record joins the list immediately. (Click **Cancel** to discard the row without saving.)
+
+</Steps>
+
+## Edit or delete a record
+
+In the **Actions** column on the right of each row:
+
+- The **pencil** icon opens the record for editing in place. Change any field, then save.
+- The **trash** icon deletes the record. Deletions take effect right away, so double-check before you remove anything.
+
+## Find a record quickly
+
+If a domain has a lot of records, use the **All types** dropdown above the table to filter by a single record type — for example, show only **MX** records while you sort out mail.
+
+## Work with several records at once
+
+Tick the checkboxes on the left of one or more rows to reveal the bulk-action bar:
+
+![Bulk actions on selected DNS records](~/assets/screenshots/whp/whp-dns-bulk-actions.png)
+
+- **Change TTL** — set the same TTL on every selected record.
+- **Enable/Disable** — toggle records on or off without deleting them (handy for temporarily parking a record).
+- **Delete** — remove all selected records at once.
+- **Clear** — clear your selection (this does *not* delete anything).
+
+## Verify it worked
+
+DNS changes apply on our side within moments, but resolvers elsewhere may keep serving the old answer until the record's TTL expires (up to 24 hours for unfamiliar records).
+
+- Run `dig example.com +short` (or `dig blog.example.com A +short`) from a terminal and confirm you see the value you just set.
+- Or use a web tool like [whatsmydns.net](https://www.whatsmydns.net/) to watch propagation across regions.
+
+## Troubleshooting
+
+**My change isn't showing up yet.** Resolvers cache records for the length of their TTL. Wait for the TTL to pass, then clear your local DNS cache and check again with `dig`.
+
+**There's no Manage DNS button for my domain.** We're not running DNS for it — its nameservers point somewhere else. Make the change at your current DNS provider, or [point the domain's nameservers at us](/whp/how-to/add-a-domain/#point-your-dns-at-us) first.
+
+**Email stopped working after I edited records.** Restore the original **MX** and SPF/DKIM **TXT** records. If you're not sure what they should be, open a support ticket (see below) and we'll put them back.
+
+## Related
+
+- [Add a domain](/whp/how-to/add-a-domain/)
+- [Create an email account](/whp/how-to/create-an-email-account/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,100 @@
+---
+title: Switching your site's backend
+description: Change the web engine (container type) running a site — standard PHP/FPM or the premium LiteSpeed/OpenLiteSpeed tier.
+sidebar:
+  order: 6
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import SignIn from '~/content/partials/signing-in.mdx';
+import Support from '~/content/partials/support-link.mdx';
+
+Every WHP site runs inside a container. The **container type** determines the web engine that serves your site's files and runs your PHP code. Most sites use a standard PHP or PHP-FPM container, which handles the vast majority of WordPress and PHP workloads well. If you've enabled the **Optimized Webserver** add-on, you also have access to LiteSpeed/OpenLiteSpeed (OLS) container types — a premium engine known for its built-in full-page cache (LSCache) and lower memory usage under traffic.
+
+Switching backends is a one-step change in the Sites editor, but it does briefly restart your container, so plan for a few seconds of downtime.
+
+## Before you start
+
+- You need **admin access** to your WHP account.
+- If you want to switch **onto** a LiteSpeed backend, your account must have the [Optimized Webserver add-on](/whp/add-ons/optimized-webserver/) enabled. If it isn't, those container types won't appear in the dropdown.
+- About 2 minutes, plus a brief site restart.
+
+## Sign in to WHP
+
+<SignIn />
+
+## Steps
+
+<Steps>
+
+1. In the sidebar, click **Sites**.
+
+2. Find the site you want to change and click **Edit** (the pencil icon next to it).
+
+3. In the **Edit Site** form, locate the **Container Type** (or **PHP Version / Backend**) dropdown.
+
+4. Select the backend you want:
+   - **PHP** or **PHP-FPM** options — standard shared webserver tier, suitable for most WordPress and PHP sites.
+   - **LiteSpeed PHP** options (e.g. *LiteSpeed PHP 8.x*) — premium OLS tier. These only appear if the Optimized Webserver add-on is active on your account.
+
+5. Click **Save**. WHP recreates the container with the new engine. Expect a brief moment of downtime (typically a few seconds) while the container restarts.
+
+</Steps>
+
+<Aside type="note">
+  After switching backends, any server-side page cache starts cold. For LiteSpeed sites this means LSCache has nothing cached yet — your first few page loads will be slightly slower while the cache warms up. This is normal and resolves on its own within minutes.
+</Aside>
+
+## Switching onto the premium LiteSpeed backend
+
+The LiteSpeed/OpenLiteSpeed container types are part of the **Optimized Webserver** add-on. If you open the Container Type dropdown and don't see any LiteSpeed options, the add-on isn't enabled on your account yet.
+
+To enable it:
+
+1. Visit the [Optimized Webserver add-on page](/whp/add-ons/optimized-webserver/) for details and pricing.
+2. Enable it from your [client portal](https://secure.anhonesthost.com/clientarea.php).
+3. Once active, the LiteSpeed PHP options will appear in the Container Type dropdown when editing any site.
+
+## Before cancelling the Optimized Webserver add-on
+
+<Aside type="caution">
+  You must move **all** of your sites off the LiteSpeed backend before you can cancel or disable the Optimized Webserver add-on. The system will block the cancellation and show an error listing every site that still needs to be moved.
+</Aside>
+
+To prepare for cancellation, switch each affected site back to a standard PHP or PHP-FPM container type:
+
+<Steps>
+
+1. In the sidebar, click **Sites**.
+
+2. For each site currently on a LiteSpeed container type, click **Edit**.
+
+3. Change the **Container Type** to a standard **PHP** or **PHP-FPM** option.
+
+4. Click **Save** and wait for the container to restart before moving to the next site.
+
+5. Repeat until no sites are on a LiteSpeed backend.
+
+</Steps>
+
+Once all sites are on standard backends, you can cancel or disable the add-on from your [client portal](https://secure.anhonesthost.com/clientarea.php) without errors.
+
+## Troubleshooting
+
+**LiteSpeed options don't appear in the dropdown.** The Optimized Webserver add-on is not enabled on your account. See [Optimized Webserver](/whp/add-ons/optimized-webserver/) to add it.
+
+**Site doesn't come back up after switching.** Wait 30 seconds and reload — the container may still be starting. If the site is still down after a minute, contact support.
+
+**Cancelling the add-on shows an error listing sites.** Switch each listed site to a standard PHP/PHP-FPM backend first (see the steps above), then retry the cancellation.
+
+**LiteSpeed cache not serving cached pages after the switch.** This is expected — the cache starts empty after every container recreation. It warms up automatically as visitors load pages.
+
+## Related
+
+- [Create a site](/whp/how-to/create-a-site/)
+- [Optimized Webserver add-on](/whp/add-ons/optimized-webserver/)
+- [Resource upgrades](/whp/add-ons/resource-upgrades/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,169 @@
+---
+title: Node + Nginx locally
+description: Run the cloud-node-container image on your laptop for Express, custom Node apps, and PM2-managed processes.
+sidebar:
+  order: 3
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+[`cloud-node-container`](https://repo.anhonesthost.net/cloud-hosting-platform/cloud-node-container) (image: **`cnoc`**) is the same Node + Nginx image we use for hosted Node sites. It's based on **AlmaLinux 9**, ships with **Node 18, 20, and 22** side-by-side (default 20), uses **PM2** as the process manager, and fronts your app with **Nginx (SSL + HTTP→HTTPS redirect)**.
+
+## What's included
+
+- **Multiple Node versions** — 18, 20, 22, switchable via `NODEVER` env var or the `-a` flag.
+- **PM2** for production-grade process management — automatic restart, log rotation.
+- **Nginx reverse proxy** with SSL and HTTP→HTTPS redirect.
+- **Memcached** for sessions, automatic backups, log rotation.
+- **`/ping` health endpoint** baked into the proxy config.
+
+## Image tags
+
+Pull from `repo.anhonesthost.net/cloud-hosting-platform/cnoc:<tag>`. The most useful tags:
+
+- `cnoc:latest` — the default (Node 20).
+- Version-pinned tags follow the same pattern (`cnoc:node18`, `cnoc:node20`, `cnoc:node22`).
+
+Check the repo for the current tag list.
+
+## Quick start with `local-dev.sh`
+
+The repo ships a `local-dev.sh` script that handles the Docker run, creates the bind-mount layout, generates helper scripts, and scaffolds a sample Express app if none exists.
+
+<Steps>
+
+1. Clone the repo and `cd` in:
+
+   ```bash
+   git clone https://repo.anhonesthost.net/cloud-hosting-platform/cloud-node-container.git
+   cd cloud-node-container
+   ```
+
+2. Start a local instance:
+
+   ```bash
+   ./local-dev.sh -n local-dev
+   ```
+
+3. The script will:
+   - Create user + log directories (`nginx/`, `nodejs/`).
+   - Scaffold a default Express app under `user/app/` if you haven't dropped your own in yet.
+   - Start the container with the right env vars.
+   - Generate helper scripts (`instance_start`, `instance_stop`, `instance_logs`, `instance_shell`).
+
+4. Open `http://localhost/` in a browser — the sample Express app's response page should be there. Or hit `http://localhost/ping` to confirm the health endpoint.
+
+</Steps>
+
+## Flags
+
+| Flag | Purpose | Default |
+|---|---|---|
+| `-n` | Container name (required) | — |
+| `-p` | HTTP port | `80` |
+| `-s` | HTTPS port | `443` |
+| `-r` | Root path for files | current directory |
+| `-a` | Node version (`18`, `20`, `22`) | `20` |
+| `-v` | Verbose mode | off |
+| `-h` | Show help | — |
+
+Example — run a Node 22 instance on port 3000:
+
+```bash
+./local-dev.sh -n my-node22-app -a 22 -p 3000 -s 3443
+```
+
+## Manual Docker usage
+
+```bash
+mkdir -p local-development/domain.tld
+cd local-development/domain.tld
+mkdir user
+mkdir -p user/{app,logs/{nginx,nodejs}}
+
+docker run -d \
+  -p 80:80 -p 443:443 \
+  -e NODEVER=20 -e environment=DEV \
+  --mount type=bind,source="$(pwd)"/user,target=/home/$(whoami) \
+  -e uid=$(id -u) -e user=$(whoami) -e domain=localhost \
+  --name local-dev \
+  repo.anhonesthost.net/cloud-hosting-platform/cnoc:latest
+```
+
+## Get a shell inside the container
+
+```bash
+docker exec -it local-dev /bin/bash
+```
+
+Useful for running `pm2 ls`, `pm2 logs`, or `npm` commands against your bind-mounted app folder.
+
+## Where your code goes
+
+Your Node application lives at `user/app/` on your laptop. Inside the container that's `/home/<user>/app/`. The container is configured to run your app from there via PM2.
+
+Minimum required files in `user/app/`:
+
+- **`package.json`** — describes your app and dependencies; **must define a start command** (`"start": "node server.js"` in `scripts`).
+- **A main JavaScript file** — typically `server.js` or `index.js`.
+
+After dropping files in, restart the container so PM2 picks up the new app:
+
+```bash
+docker restart local-dev
+```
+
+Your app should bind to the **port shown by the container's env var** (usually `process.env.PORT`). Nginx forwards traffic to that port internally and proxies SSL.
+
+## Logs
+
+| Where | What |
+|---|---|
+| `user/logs/nginx/` | Nginx access + error logs |
+| `user/logs/nodejs/` | PM2's stdout/stderr capture from your Node app |
+
+Tail them from your laptop:
+
+```bash
+tail -F user/logs/nodejs/*.log
+```
+
+Or via the helper script:
+
+```bash
+./instance_logs
+```
+
+## Stop / start / clean up
+
+```bash
+./instance_stop      # stop the container
+./instance_start     # start it again
+./instance_logs      # view container logs
+./instance_shell     # exec into the container
+```
+
+To wipe everything:
+
+```bash
+docker rm -f local-dev
+rm -rf local-development/
+```
+
+<Aside type="tip">
+  The `/ping` endpoint is wired by Nginx independently of your app — useful for `docker healthcheck` config when you start adapting the manual command to your own setup.
+</Aside>
+
+## Source
+
+[`cloud-node-container` on Gitea](https://repo.anhonesthost.net/cloud-hosting-platform/cloud-node-container) — Dockerfile, Nginx + PM2 configs, entrypoint, and the `local-dev.sh` script.
+
+## Related
+
+- [PHP + Apache locally](/whp/local-dev/php-apache/)
+- [Create a site](/whp/how-to/create-a-site/) — the hosted side.
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,50 @@
+---
+title: Develop locally with our containers
+description: Run the same Apache/PHP and Node containers locally that we use to host your site in production.
+sidebar:
+  order: 1
+---
+
+import { Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+The same container images we use to host your site in production are published as open-source images you can pull and run on your laptop. If you're comfortable with Docker, this gives you a development environment that matches production exactly — same OS, same Apache/Nginx config, same PHP or Node version.
+
+## Why use our containers locally
+
+- **Dev/prod parity.** Anything that runs in the container on your machine will run the same way in production. No "works on my Mac" surprises.
+- **Quick start.** Each container ships a `local-dev.sh` script that handles the Docker incantation, volume layout, and helper commands.
+- **No account required.** The images are public — pull and run.
+
+<Aside type="note">
+  This page is for customers who are comfortable with Docker. You don't need to use these images to host with us — the WHP panel handles everything for the hosted version. This is for **local development** only.
+</Aside>
+
+## Available containers
+
+| Stack | Image | Use case |
+|---|---|---|
+| **PHP + Apache** | `repo.anhonesthost.net/cloud-hosting-platform/cac` | WordPress, Laravel, traditional PHP apps |
+| **Node + Nginx** | `repo.anhonesthost.net/cloud-hosting-platform/cnoc` | Express, custom Node apps, PM2-managed processes |
+
+Both images live in our public Gitea organisation at [repo.anhonesthost.net/cloud-hosting-platform/](https://repo.anhonesthost.net/cloud-hosting-platform/) — the source Dockerfiles, build configs, and helper scripts are all there too. Issues and PRs welcome.
+
+## Prerequisites
+
+- **Docker** (or a compatible runtime like Podman / OrbStack / Rancher Desktop). Docker Desktop on Mac/Windows or `docker.io` on Linux both work.
+- A terminal where you can run `git`, `docker`, and basic shell scripts.
+- Ports `80` and `443` free on your machine (the local-dev scripts bind these by default; both can be overridden with flags).
+
+## Pick your stack
+
+- **[PHP + Apache locally](/whp/local-dev/php-apache/)** — for WordPress and any PHP application.
+- **[Node + Nginx locally](/whp/local-dev/node/)** — for Express, Next.js standalone, or any Node app.
+
+## Related
+
+- [Create a site](/whp/how-to/create-a-site/) — how the same images run as hosted sites in WHP.
+- [What is containerized hosting?](/whp/getting-started/what-is-containerized-hosting/)
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,155 @@
+---
+title: PHP + Apache locally
+description: Run the cloud-apache-container image on your laptop for WordPress and other PHP apps.
+sidebar:
+  order: 2
+---
+
+import { Steps, Aside } from '@astrojs/starlight/components';
+import Support from '~/content/partials/support-link.mdx';
+
+[`cloud-apache-container`](https://repo.anhonesthost.net/cloud-hosting-platform/cloud-apache-container) (image: **`cac`**) is the same Apache + PHP image we use for hosted PHP sites. It's based on **AlmaLinux 9**, ships with **PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4, and 8.5** side-by-side (default 8.3), and uses **Apache with mod_ssl**.
+
+## Image tags
+
+Pre-built tags are pushed on every change:
+
+- `cac:latest` — the default (PHP 8.3).
+- `cac:php74`, `cac:php80`, `cac:php81`, `cac:php82`, `cac:php83`, `cac:php84`, `cac:php85` — pin to a specific PHP version.
+
+Pull from `repo.anhonesthost.net/cloud-hosting-platform/cac:<tag>`.
+
+## Quick start with `local-dev.sh`
+
+The repo ships a `local-dev.sh` script that handles the Docker incantation, creates the volume + log directories, generates helper scripts, and installs a fresh WordPress in the web root.
+
+<Steps>
+
+1. Clone the repo and `cd` in:
+
+   ```bash
+   git clone https://repo.anhonesthost.net/cloud-hosting-platform/cloud-apache-container.git
+   cd cloud-apache-container
+   ```
+
+2. Start a local instance:
+
+   ```bash
+   ./local-dev.sh -n local-dev
+   ```
+
+3. The script will:
+   - Create a user directory and log folders (`apache/`, `system/`).
+   - Create a Docker volume for MySQL.
+   - Start the container with the right env vars.
+   - Generate helper scripts in your root path (`instance_start`, `instance_stop`, `instance_logs`, `instance_db_info`).
+   - Install WordPress in your web root.
+   - Print the MySQL credentials it generated.
+
+4. Open `http://localhost/` in a browser — WordPress's setup screen should be there.
+
+</Steps>
+
+## Flags
+
+| Flag | Purpose | Default |
+|---|---|---|
+| `-n` | Container name (required) | — |
+| `-p` | HTTP port | `80` |
+| `-s` | HTTPS port | `443` |
+| `-r` | Root path for files and DB | current directory |
+| `-a` | PHP version (`74`, `80`, `81`, `82`, `83`, `84`, `85`) | `83` |
+| `-v` | Verbose mode | off |
+| `-h` | Show help | — |
+
+Example — run a PHP 8.5 instance on port 8080:
+
+```bash
+./local-dev.sh -n my-php85-site -a 85 -p 8080 -s 8443
+```
+
+## Manual Docker usage
+
+If you'd rather skip the script and run it yourself:
+
+```bash
+mkdir -p local-development/domain.tld
+cd local-development/domain.tld
+mkdir user
+mkdir -p user/logs/{apache,system}
+
+docker run -d -it \
+  -p 80:80 -p 443:443 \
+  -e PHPVER=84 -e environment=DEV \
+  --mount type=bind,source="$(pwd)"/user,target=/home/myuser \
+  -v"$name-mysql":/var/lib/mysql \
+  -e uid=30001 -e user=myuser -e domain=localhost \
+  --name local-dev \
+  repo.anhonesthost.net/cloud-hosting-platform/cac:latest
+```
+
+## Get a shell inside the container
+
+```bash
+docker exec -it local-dev /bin/bash
+```
+
+Useful for running `wp-cli`, tailing logs from inside, or checking PHP modules.
+
+## Where things live
+
+| Inside the container | On your laptop (via bind mount) |
+|---|---|
+| `/home/myuser/public_html/` — Apache docroot | `local-development/domain.tld/user/public_html/` |
+| `/home/myuser/logs/apache/` — Apache logs | `local-development/domain.tld/user/logs/apache/` |
+| `/var/lib/mysql/` — MySQL data | Named Docker volume (`<name>-mysql`) |
+| `/home/myuser/mysql_creds` | Same path on the bind mount |
+
+## WordPress
+
+`local-dev.sh` installs WordPress automatically. If you started manually:
+
+```bash
+docker exec -it local-dev bash
+cat /home/myuser/mysql_creds  # see the credentials
+cd /home/myuser/public_html
+wp core download
+wp config create --dbname=... --dbuser=... --dbpass=... --dbhost=localhost
+wp core install --url=http://localhost --title="Local Dev" --admin_user=admin --admin_email=you@example.com
+```
+
+## Stop / start / clean up
+
+The helper scripts the local-dev script writes are the easy path:
+
+```bash
+./instance_stop      # stop the container
+./instance_start     # start it again
+./instance_logs      # tail Apache logs
+./instance_db_info   # show MySQL credentials
+```
+
+To wipe everything:
+
+```bash
+docker rm -f local-dev
+docker volume rm local-dev-mysql
+rm -rf local-development/
+```
+
+<Aside type="tip">
+  Want to test the exact PHP version of your hosted WHP site locally? Match the `-a` flag to your site's PHP version on the [Sites page](/whp/how-to/create-a-site/).
+</Aside>
+
+## Source
+
+[`cloud-apache-container` on Gitea](https://repo.anhonesthost.net/cloud-hosting-platform/cloud-apache-container) — Dockerfile, entrypoint, build configs, and the `local-dev.sh` script.
+
+## Related
+
+- [Node + Nginx locally](/whp/local-dev/node/)
+- [Create a site](/whp/how-to/create-a-site/) — the hosted side.
+
+## Still stuck?
+
+<Support />
@@ -0,0 +1,3 @@
+Super admin access is granted to the `root` user only. Sign in **directly** at `https://<your-server-hostname>:8443` with the root credentials.
+
+The WHMCS client portal route doesn't apply for super admin — it signs you in as the linked customer, not as root.
@@ -23,10 +23,25 @@ const PRODUCT_META: Record<string, { title: string; blurb: string; firstSection:
    blurb: 'Tips and tricks for getting the most out of WordPress on WHP.',
    firstSection: 'index',
  },
-  'email-clients': {
-    title: 'Email clients',
-    blurb: 'Configure Outlook, Apple Mail, Thunderbird, and mobile clients.',
-    firstSection: 'index',
+  email: {
+    title: 'Email',
+    blurb: 'Set up Outlook, Apple Mail, Thunderbird, and mobile clients — plus news about our filtering.',
+    firstSection: 'set-up-your-email-client',
+  },
+  domains: {
+    title: 'Domains',
+    blurb: 'Transfer a domain to us, point it at your hosting, and sort out DNS problems.',
+    firstSection: 'transferring-a-domain-to-us',
+  },
+  cpanel: {
+    title: 'cPanel hosting',
+    blurb: 'Nameservers, SSL certificates, permissions, and email for our cPanel shared and reseller plans.',
+    firstSection: 'nameservers',
+  },
+  support: {
+    title: 'Support',
+    blurb: 'Working with our support team, including remote-assistance sessions.',
+    firstSection: 'remote-support',
  },
 };

@@ -41,10 +41,33 @@ Outputs one PNG per entry in `shots.config.ts` to `src/assets/screenshots/whp/<i

 ## Refresh workflow

-UI changed? → `npm run screenshots` locally → review the diffs (`git diff --stat` shows changed PNGs) → eyeball them for accidental leakage → commit → push.
+UI changed? → run the capture (see below) locally → review the diffs (`git diff --stat` shows changed PNGs) → **open each changed PNG and eyeball it for accidental leakage** (server hostname, IP, account ID, customer domains/usernames) → commit → push.
+
+- **A page covered by `shots.config.ts`** (a plain navigate-and-shoot page): `npm run screenshots`.
+- **A page that needs interaction** — opening a modal, ticking checkboxes, switching tabs — lives in a **section capture script** (see below). Re-run that script instead.
+
+When a section is *reworked* (not just restyled), also: re-walk the new UI to find every state worth a screenshot, update the section script's steps, add/rename the `whp-<section>-*` ids, then refresh the `.mdx` references and run `npm run build` to confirm links and images resolve.
+
+## Section capture scripts
+
+`shots.config.ts` + `run.ts` only do navigate → redact → screenshot. Anything that needs **interaction or per-section redaction** gets its own `capture-<section>.ts`, run directly with `tsx`:
+
+```bash
+set -a; source tools/screenshots/.env; set +a
+npx tsx tools/screenshots/capture-dns.ts
+```
+
+| Script | Covers | Auth |
+| --- | --- | --- |
+| `capture-admin.ts` | Server Settings tabs, admin pages | `WHP_ADMIN_USER` |
+| `capture-site-builder.ts` | Site Builder editor states | `WHP_USER` |
+| `capture-dns.ts` | Domains & DNS list, Add Domain modal, records editor, bulk toolbar | `WHP_USER` |
+| `capture-email.ts` | Email page "Mail Client Setup" section (autodiscovery DNS records) | `WHP_USER` |
+
+Each script carries its own `redact()` (text-node + input-value swaps) so fleet hostnames, IPs, and customer data become neutral placeholders while brand/demo domains stay visible. Copy the closest existing script when adding a new section — match its viewport (1440×900), `deviceScaleFactor: 2`, and **read-only** discipline (open modals and tick boxes for the shot, but never save/delete/submit).

 ## Adding a new shot

-1. Add an entry to `shots.config.ts` with a stable `id`.
-2. `npm run screenshots`.
+1. **Static page?** Add an entry to `shots.config.ts` with a stable `id`, then `npm run screenshots`.
+2. **Interactive state?** Add the step to the relevant `capture-<section>.ts` (or copy one for a new section), then `npx tsx tools/screenshots/capture-<section>.ts`.
 3. Reference the new file in your `.mdx`: `![Alt text](~/assets/screenshots/whp/<id>.png)`.
@@ -0,0 +1,229 @@
+/**
+ * v2 admin capture — stricter redaction and deeper navigation.
+ *
+ * - Masks customer domains (anything not in the brand allowlist).
+ * - Masks customer-shaped usernames (anything not in the system allowlist).
+ * - Masks input value attributes (the v1 only walked text nodes).
+ * - Captures Settings sub-tabs (System, Services, Mail, DNS, Network & SSL,
+ *   Security) since those are where LiteLLM URL / model / key likely live.
+ *
+ * Read-only. Never clicks save/apply/restart/delete.
+ */
+import { chromium, type Page } from 'playwright';
+import { mkdir } from 'node:fs/promises';
+import { resolve, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const OUT_DIR = resolve(__dirname, '../../src/assets/screenshots/whp');
+
+function need(name: string): string {
+  const v = process.env[name];
+  if (!v) throw new Error(`missing env: ${name}`);
+  return v;
+}
+
+const BASE = need('WHP_BASE');
+const USER = need('WHP_ADMIN_USER');
+const PASS = need('WHP_ADMIN_PASS');
+
+const HIDE_CSS = `.navbar-text, .brand-full { visibility: hidden !important; }`;
+
+async function login(page: Page) {
+  await page.goto(`${BASE}/login.php`, { waitUntil: 'domcontentloaded' });
+  await page.fill('input[name="user"]', USER);
+  await page.fill('input[name="password"]', PASS);
+  await page.click('button[type="submit"]');
+  await page.waitForLoadState('networkidle');
+}
+
+async function redact(page: Page) {
+  await page.addStyleTag({ content: HIDE_CSS });
+
+  await page.evaluate(() => {
+    // ---- Mask all secret-shaped input values ----
+    const secretInputSel = [
+      'input[type="password"]',
+      'input[name*="key" i]',
+      'input[name*="token" i]',
+      'input[name*="secret" i]',
+      'input[name*="api" i]',
+    ];
+    for (const sel of secretInputSel) {
+      document.querySelectorAll<HTMLInputElement>(sel).forEach((el) => {
+        if (el.value) el.value = '████████████████';
+      });
+    }
+
+    // ---- Brand allowlist ----
+    const BRAND_SUFFIXES = [
+      'anhonesthost.com', 'anhonesthost.net', 'anhonesthost.io',
+      'anhh.co',
+      'cloud-hosting.io',
+      'example.com', 'example.org', 'example.net',
+    ];
+
+    // ---- System users to keep visible (others get masked) ----
+    const SYSTEM_USERS_ARR = ['root', 'admin', 'whp', 'haproxy', 'apache', 'nginx', 'newuser'];
+
+    // ---- Text-node swaps ----
+    const swaps: [RegExp, string][] = [
+      // Server / mail / nameserver hostnames in our infra
+      [/whp\d+(-[a-z0-9]+)?\.cloud-hosting\.io/gi, '<your-server>.cloud-hosting.io'],
+      [/mail\d+\.cloud-hosting\.io/gi, '<your-mail-server>.cloud-hosting.io'],
+      [/whp\d+(-[a-z0-9]+)?\b/gi, '<your-server>'],
+      [/WHP\d+(-[A-Z0-9]+)?\b/g, '<YOUR-SERVER>'],
+      // IPs
+      [/\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/g, '<server-IP>'],
+      // Home dirs
+      [/\/docker\/users\/[a-z0-9-]+/g, '/docker/users/<user>'],
+      // Common secret shapes
+      [/sk-[A-Za-z0-9_-]{20,}/g, '<API-KEY>'],
+      [/sk_(test|live)_[A-Za-z0-9]{20,}/g, '<API-KEY>'],
+      [/Bearer\s+[A-Za-z0-9._-]{20,}/g, 'Bearer <API-KEY>'],
+      [/eyJ[A-Za-z0-9_-]{20,}\.[A-Za-z0-9_-]{20,}\.[A-Za-z0-9_-]{20,}/g, '<JWT>'],
+      // AI provider URLs
+      [/https?:\/\/[^\s"'<>]*litellm[^\s"'<>]*/gi, '<litellm-endpoint>'],
+      [/https?:\/\/[^\s"'<>]*\.anhonesthost\.(net|com|io)[^\s"'<>]*/gi, '<internal-endpoint>'],
+      // Model family identifiers
+      [/(claude|gpt|llama|mistral|gemini)[a-z0-9._-]*-\d[a-z0-9.\-]*/gi, '<model-name>'],
+      // Bichon / Coraza / haproxy internal endpoints
+      [/https?:\/\/[^\s"'<>]*\b(bichon|coraza-spoa|haproxy-manager)[^\s"'<>]*/gi, '<internal-service>'],
+      // root → admin (we don't expose which UNIX user has super admin)
+      [/Welcome, root\b/g, 'Welcome, admin'],
+      [/(User:\s*)root\b/g, '$1admin'],
+      [/(Home Directory:\s*)\/root\b/g, '$1/<admin-home>'],
+      // Standalone 'root' (whole-word, not preceded by / or . — so paths like
+      // /root/foo and references like .root stay untouched).
+      [/(^|[^/.\w])root\b/g, '$1admin'],
+    ];
+
+    // ---- Walk text nodes ----
+    const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT);
+    const nodes: Text[] = [];
+    let n: Node | null = walker.nextNode();
+    while (n) { nodes.push(n as Text); n = walker.nextNode(); }
+    for (const node of nodes) {
+      let v = node.nodeValue ?? '';
+
+      // Mask non-brand domain names (basic pattern: word.tld)
+      v = v.replace(/\b([a-z0-9][a-z0-9-]{0,62}\.)+[a-z]{2,24}\b/gi, function (m) {
+        const h = m.toLowerCase();
+        let brand = false;
+        for (const s of BRAND_SUFFIXES) { if (h === s || h.endsWith('.' + s)) { brand = true; break; } }
+        return brand ? m : '<customer-domain>';
+      });
+
+      // Apply other swaps
+      for (const [re, replacement] of swaps) v = v.replace(re, replacement);
+
+      if (v !== node.nodeValue) node.nodeValue = v;
+    }
+
+    // ---- Mask sensitive content in input values ----
+    document.querySelectorAll<HTMLInputElement>('input[type="text"], input[type="url"], input[type="email"], input:not([type])').forEach((el) => {
+      if (!el.value) return;
+      const v = el.value;
+      let nv = v.replace(/\b([a-z0-9][a-z0-9-]{0,62}\.)+[a-z]{2,24}\b/gi, function (m) {
+        const h = m.toLowerCase();
+        let brand = false;
+        for (const s of BRAND_SUFFIXES) { if (h === s || h.endsWith('.' + s)) { brand = true; break; } }
+        return brand ? m : '<customer-domain>';
+      });
+      // Server / mail / NS hostnames
+      nv = nv.replace(/whp\d+(-[a-z0-9]+)?\.cloud-hosting\.io/gi, '<your-server>.cloud-hosting.io');
+      nv = nv.replace(/mail\d+\.cloud-hosting\.io/gi, '<your-mail-server>.cloud-hosting.io');
+      nv = nv.replace(/ns[12]\.whp\d+\.cloud-hosting\.io/gi, 'ns<n>.<your-server>.cloud-hosting.io');
+      // IPv4 — skip the well-known public resolvers / RFC1918 examples
+      nv = nv.replace(/\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/g, function (ip) {
+        const pub = new Set(['1.1.1.1', '1.0.0.1', '8.8.8.8', '8.8.4.4', '9.9.9.9', '149.112.112.112', '208.67.222.222', '208.67.220.220']);
+        if (pub.has(ip)) return ip;
+        if (/^(10\.|192\.168\.|172\.(1[6-9]|2\d|3[01])\.)/.test(ip)) return ip; // private nets, fine
+        return '<server-IP>';
+      });
+      if (nv !== v) el.value = nv;
+    });
+
+    // ---- Mask customer usernames in table cells ----
+    // Heuristic: find table cells under a header containing 'user', 'username', or 'target' (case-insensitive)
+    document.querySelectorAll('table').forEach((tbl) => {
+      const headers = Array.from(tbl.querySelectorAll('thead th, thead td')).map(th => (th.textContent || '').trim().toLowerCase());
+      const userCols: number[] = [];
+      for (let i = 0; i < headers.length; i++) {
+        if (/^(user(name)?|target|owner|account)$/.test(headers[i])) userCols.push(i);
+      }
+      if (userCols.length === 0) return;
+      const rows = tbl.querySelectorAll('tbody tr');
+      for (let r = 0; r < rows.length; r++) {
+        const cells = rows[r].querySelectorAll('td');
+        for (const idx of userCols) {
+          const cell = cells[idx];
+          if (!cell) continue;
+          const txt = (cell.textContent || '').trim();
+          if (!txt) continue;
+          let isSystem = false;
+          for (const u of SYSTEM_USERS_ARR) { if (u === txt) { isSystem = true; break; } }
+          if (!isSystem) cell.textContent = '<user>';
+        }
+      }
+    });
+  });
+}
+
+async function shot(page: Page, id: string) {
+  await page.waitForLoadState('networkidle');
+  await page.waitForTimeout(500);
+  await redact(page);
+  const path = resolve(OUT_DIR, `${id}.png`);
+  await page.screenshot({ path, fullPage: false });
+  console.log(`captured ${id}`);
+}
+
+async function main() {
+  await mkdir(OUT_DIR, { recursive: true });
+  const browser = await chromium.launch({ headless: true });
+  const ctx = await browser.newContext({ ignoreHTTPSErrors: true, viewport: { width: 1440, height: 900 }, deviceScaleFactor: 2 });
+  const page = await ctx.newPage();
+  try {
+    await login(page);
+
+    // Server Settings — click each tab
+    await page.goto(`${BASE}/index.php?page=server-settings`);
+    await page.waitForLoadState('networkidle');
+    await shot(page, 'admin-srvset-system');
+    for (const tab of ['services', 'mail', 'dns', 'network', 'security']) {
+      const trigger = page.locator(`[data-bs-target="#tab-${tab}"]`).first();
+      if (await trigger.count() === 0) { console.log('tab trigger not found:', tab); continue; }
+      await trigger.click().catch(()=>{});
+      await page.waitForTimeout(1200);
+      await shot(page, `admin-srvset-${tab}`);
+    }
+
+    // Re-shoot the previously PII-heavy pages with v2 redaction
+    const rerun = [
+      { id: 'admin-coraza',          path: '/index.php?page=coraza-rules' },
+      { id: 'admin-monitor-admin',   path: '/index.php?page=ai-monitor' },
+      { id: 'admin-ignore-rules',    path: '/index.php?page=ai-monitor-ignore-rules' },
+      { id: 'admin-user-mgmt',       path: '/index.php?page=user-management' },
+      { id: 'admin-user-resources',  path: '/index.php?page=user-resources' },
+      { id: 'admin-issues',          path: '/index.php?page=issues' },
+      { id: 'admin-suspensions',     path: '/index.php?page=account-suspensions' },
+      { id: 'admin-disk-usage',      path: '/index.php?page=disk-usage' },
+      { id: 'admin-docker',          path: '/index.php?page=docker-management' },
+      { id: 'admin-valkey',          path: '/index.php?page=valkey-admin' },
+      { id: 'admin-updates',         path: '/index.php?page=update-management' },
+      { id: 'admin-container-boot',  path: '/index.php?page=container-boot' },
+      { id: 'admin-site-audit',      path: '/index.php?page=site-audit' },
+      { id: 'admin-delegated',       path: '/index.php?page=delegated-users' },
+    ];
+    for (const r of rerun) {
+      await page.goto(`${BASE}${r.path}`);
+      await page.waitForLoadState('networkidle');
+      await shot(page, r.id);
+    }
+  } finally {
+    await browser.close();
+  }
+}
+
+main().catch(e => { console.error(e); process.exit(1); });
@@ -0,0 +1,140 @@
+/**
+ * DNS capture — the reworked "Domains & DNS" area.
+ *
+ * Captures, as the demo customer (so the demo domain's real zone shows):
+ *   - whp-domains.png          the Domains & DNS list (searchable table)
+ *   - whp-dns-add-domain.png   the Add Domain modal
+ *   - whp-dns-records.png      the per-domain DNS Records editor
+ *   - whp-dns-add-record.png   the inline "Add Record" editor row
+ *   - whp-dns-bulk-actions.png the bulk-select toolbar
+ *
+ * Viewport-only (1440x900), redacted for our multi-server fleet: server /
+ * mail / nameserver hostnames and IPs become neutral placeholders, while the
+ * brand demo domain (whp-demo.anhh.co) is kept visible on purpose.
+ *
+ * Read-only: opens modals and ticks checkboxes for the screenshot, never
+ * saves, deletes, or submits anything.
+ */
+import { chromium, type Page } from 'playwright';
+import { mkdir } from 'node:fs/promises';
+import { resolve, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const OUT_DIR = resolve(__dirname, '../../src/assets/screenshots/whp');
+
+function need(name: string): string {
+  const v = process.env[name];
+  if (!v) throw new Error(`missing env: ${name}`);
+  return v;
+}
+
+const BASE = need('WHP_BASE');
+const USER = need('WHP_USER');
+const PASS = need('WHP_PASS');
+const DOMAIN = process.env.WHP_DEMO_DOMAIN ?? 'whp-demo.anhh.co';
+
+const HIDE_CSS = `.navbar-text, .brand-full { visibility: hidden !important; }`;
+
+async function login(page: Page) {
+  await page.goto(`${BASE}/login.php`, { waitUntil: 'domcontentloaded' });
+  await page.fill('input[name="user"]', USER);
+  await page.fill('input[name="password"]', PASS);
+  await page.click('button[type="submit"]');
+  await page.waitForLoadState('networkidle');
+}
+
+/**
+ * Neutralise fleet-identifying text before the screenshot. The brand demo
+ * domain (anhh.co) is intentionally preserved; everything that names a
+ * specific server, mail host, nameserver, or IP is swapped for a placeholder.
+ */
+async function redact(page: Page) {
+  await page.addStyleTag({ content: HIDE_CSS });
+  await page.evaluate(() => {
+    const swaps: [RegExp, string][] = [
+      [/ns[12]\.whp\d+(-[a-z0-9]+)?\.cloud-hosting\.io/gi, 'ns<n>.<your-server>.cloud-hosting.io'],
+      [/whp\d+(-[a-z0-9]+)?\.cloud-hosting\.io/gi, '<your-server>.cloud-hosting.io'],
+      [/mail\d+\.cloud-hosting\.io/gi, '<mail-server>.cloud-hosting.io'],
+      [/WHP\d+(-[A-Z0-9]+)?\b/g, '<YOUR-SERVER>'],
+      [/whp\d+(-[a-z0-9]+)?\b/gi, '<your-server>'],
+      // Public IPv4 (skip RFC1918 — those read fine as generic examples)
+      [/\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/g, '<server-IP>'],
+      [/demo-user/g, 'your-username'],
+    ];
+    // Text nodes
+    const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT);
+    const nodes: Text[] = [];
+    let n: Node | null = walker.nextNode();
+    while (n) { nodes.push(n as Text); n = walker.nextNode(); }
+    for (const node of nodes) {
+      let v = node.nodeValue ?? '';
+      for (const [re, rep] of swaps) v = v.replace(re, rep);
+      if (v !== node.nodeValue) node.nodeValue = v;
+    }
+    // Input values (the inline Add Record / TTL fields)
+    document.querySelectorAll<HTMLInputElement>('input').forEach((el) => {
+      if (el.type === 'password' || !el.value) return;
+      let v = el.value;
+      for (const [re, rep] of swaps) v = v.replace(re, rep);
+      if (v !== el.value) el.value = v;
+    });
+  });
+}
+
+async function shot(page: Page, id: string) {
+  await page.waitForTimeout(400);
+  await redact(page);
+  const path = resolve(OUT_DIR, `${id}.png`);
+  await page.screenshot({ path, fullPage: false });
+  console.log(`captured ${id} -> ${path}`);
+}
+
+async function main() {
+  await mkdir(OUT_DIR, { recursive: true });
+  const browser = await chromium.launch({ headless: true });
+  const ctx = await browser.newContext({
+    ignoreHTTPSErrors: true,
+    viewport: { width: 1440, height: 900 },
+    deviceScaleFactor: 2,
+  });
+  const page = await ctx.newPage();
+  try {
+    await login(page);
+
+    // 1. Domains & DNS list
+    await page.goto(`${BASE}/index.php?page=domains`, { waitUntil: 'networkidle' });
+    await shot(page, 'whp-domains');
+
+    // 2. Add Domain modal
+    await page.locator('button:has-text("Add Domain"), a:has-text("Add Domain")').first().click();
+    await page.waitForTimeout(600);
+    await shot(page, 'whp-dns-add-domain');
+    await page.keyboard.press('Escape').catch(() => {});
+    await page.waitForTimeout(300);
+
+    // 3. DNS Records editor for the demo domain
+    await page.goto(`${BASE}/index.php?page=domains&domain=${DOMAIN}`, { waitUntil: 'networkidle' });
+    await shot(page, 'whp-dns-records');
+
+    // 4. Inline Add Record row
+    await page.locator('button:has-text("Add Record"), a:has-text("Add Record")').first().click();
+    await page.waitForTimeout(500);
+    await shot(page, 'whp-dns-add-record');
+    // Cancel the inline add row so the next shot is clean
+    await page.locator('button:has-text("Cancel")').first().click().catch(() => {});
+    await page.waitForTimeout(400);
+
+    // 5. Bulk-select toolbar (tick two record rows)
+    const rowChecks = page.locator('table tbody input[type=checkbox]');
+    const n = await rowChecks.count();
+    if (n >= 2) { await rowChecks.nth(0).check(); await rowChecks.nth(1).check(); }
+    else if (n === 1) { await rowChecks.nth(0).check(); }
+    await page.waitForTimeout(500);
+    await shot(page, 'whp-dns-bulk-actions');
+  } finally {
+    await browser.close();
+  }
+}
+
+main().catch((err) => { console.error(err); process.exit(1); });
@@ -0,0 +1,123 @@
+/**
+ * Email capture — the tabbed Email Management page, as the demo customer.
+ *
+ * Captures:
+ *   - whp-email.png                 the Email page on its default "Email Accounts"
+ *                                   tab: the top button strip (Webmail / Admin
+ *                                   Panel / Setup Instructions) + the tab bar
+ *                                   (Email Accounts · Forwarders · Email Domains
+ *                                   (DNS)) + the Email Accounts card.
+ *   - whp-email-autodiscovery.png   the "Autodiscovery Records (DNS)" card on the
+ *                                   "Email Domains (DNS)" tab: the per-domain
+ *                                   autodiscovery DNS records table + copyable zone.
+ *
+ * Viewport-only (1440x900, deviceScaleFactor 2), redacted for our multi-server
+ * fleet: server/mail hostnames + IPs become placeholders, while the brand demo
+ * domain (whp-demo.anhh.co) is kept visible on purpose.
+ *
+ * Read-only: switches tabs / selects a domain for the shot, never saves.
+ */
+import { chromium, type Page } from 'playwright';
+import { mkdir } from 'node:fs/promises';
+import { resolve, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const OUT_DIR = resolve(__dirname, '../../src/assets/screenshots/whp');
+
+function need(name: string): string {
+  const v = process.env[name];
+  if (!v) throw new Error(`missing env: ${name}`);
+  return v;
+}
+
+const BASE = need('WHP_BASE');
+const USER = need('WHP_USER');
+const PASS = need('WHP_PASS');
+
+const HIDE_CSS = `.navbar-text, .brand-full { visibility: hidden !important; }`;
+
+async function login(page: Page) {
+  await page.goto(`${BASE}/login.php`, { waitUntil: 'domcontentloaded' });
+  await page.fill('input[name="user"]', USER);
+  await page.fill('input[name="password"]', PASS);
+  await page.click('button[type="submit"]');
+  await page.waitForLoadState('networkidle');
+}
+
+/**
+ * Neutralise fleet-identifying text before the screenshot. The brand demo
+ * domain (anhh.co) is intentionally preserved; mail/server hosts and IPs are
+ * swapped for placeholders. Inline only — no named helpers inside evaluate
+ * (esbuild's __name instrumentation isn't defined in the browser context).
+ */
+async function redact(page: Page) {
+  await page.addStyleTag({ content: HIDE_CSS });
+  await page.evaluate(() => {
+    const swaps: [RegExp, string][] = [
+      [/mail\d+\.cloud-hosting\.io/gi, '<mail-server>.cloud-hosting.io'],
+      [/whp\d+(-[a-z0-9]+)?\.cloud-hosting\.io/gi, '<your-server>.cloud-hosting.io'],
+      [/WHP\d+(-[A-Z0-9]+)?\b/g, '<YOUR-SERVER>'],
+      [/whp\d+(-[a-z0-9]+)?\b/gi, '<your-server>'],
+      [/\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/g, '<server-IP>'],
+    ];
+    const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT);
+    const nodes: Text[] = [];
+    let n: Node | null = walker.nextNode();
+    while (n) { nodes.push(n as Text); n = walker.nextNode(); }
+    for (const node of nodes) {
+      let v = node.nodeValue ?? '';
+      for (const [re, rep] of swaps) v = v.replace(re, rep);
+      if (v !== node.nodeValue) node.nodeValue = v;
+    }
+  });
+}
+
+async function main() {
+  await mkdir(OUT_DIR, { recursive: true });
+  const browser = await chromium.launch({ headless: true });
+  const ctx = await browser.newContext({
+    ignoreHTTPSErrors: true,
+    viewport: { width: 1440, height: 900 },
+    deviceScaleFactor: 2,
+  });
+  const page = await ctx.newPage();
+  try {
+    await login(page);
+    await page.goto(`${BASE}/index.php?page=email-management`, { waitUntil: 'networkidle' });
+    await page.waitForSelector('#email-mgmt-nav', { state: 'visible' });
+
+    // --- Shot 1: the default Email Accounts tab (orientation) ---
+    await page.waitForTimeout(300);
+    await redact(page);
+    await page.evaluate(() => window.scrollTo(0, 0));
+    const mainPath = resolve(OUT_DIR, 'whp-email.png');
+    await page.screenshot({ path: mainPath }); // viewport-only, no chrome
+    console.log(`captured whp-email -> ${mainPath}`);
+
+    // --- Shot 2: the Autodiscovery Records (DNS) card on the DNS tab ---
+    await page.locator('#email-mgmt-nav button[data-bs-target="#email-mgmt-dns"]').click();
+    await page.waitForSelector('#custMailDnsDomain', { state: 'visible' });
+    // Ensure a domain is selected, then (re)render the zone block.
+    await page.evaluate(() => {
+      const sel = document.getElementById('custMailDnsDomain') as HTMLSelectElement | null;
+      if (sel && sel.selectedIndex < 0 && sel.options.length) sel.selectedIndex = 0;
+      const fn = (window as unknown as { renderCustMailDns?: () => void }).renderCustMailDns;
+      if (typeof fn === 'function') fn();
+    });
+    await page.waitForTimeout(500);
+    await redact(page); // re-run: tab content rendered after the first pass
+
+    // The autodiscovery section is the .card wrapping the domain <select>.
+    const card = page.locator('#custMailDnsDomain').locator('xpath=ancestor::div[contains(@class,"card")][1]');
+    await card.scrollIntoViewIfNeeded();
+    await page.waitForTimeout(300);
+    const autoPath = resolve(OUT_DIR, 'whp-email-autodiscovery.png');
+    await card.screenshot({ path: autoPath });
+    console.log(`captured whp-email-autodiscovery -> ${autoPath}`);
+  } finally {
+    await browser.close();
+  }
+}
+
+main().catch((err) => { console.error(err); process.exit(1); });
@@ -0,0 +1,116 @@
+/**
+ * Traffic analytics capture — for the June 2026 platform-updates blog post.
+ *
+ * Captures, as the demo customer:
+ *   - traffic-analytics-overview.png   View Traffic landing: Yesterday's Snapshot,
+ *                                      Top URLs / Bandwidth Consumers, Daily Totals
+ *   - traffic-analytics-day-detail.png the per-day drill-down: hourly request graph,
+ *                                      top pages by views, top pages by bandwidth
+ *
+ * Viewport 1440x900, deviceScaleFactor 2, fullPage:false. Redacts the fleet
+ * server strip ("WHP-01" / "Welcome, ...") and the version-number footer; keeps
+ * the brand demo domain (whp-demo.anhh.co) visible on purpose. Read-only.
+ *
+ * Output goes to /workspace/blog-assets (this is a blog image, not a KB page).
+ */
+import { chromium, type Page } from 'playwright';
+import { mkdir } from 'node:fs/promises';
+import { resolve } from 'node:path';
+
+const OUT_DIR = '/workspace/blog-assets';
+
+function need(name: string): string {
+  const v = process.env[name];
+  if (!v) throw new Error(`missing env: ${name}`);
+  return v;
+}
+
+const BASE = need('WHP_BASE');
+const USER = need('WHP_USER');
+const PASS = need('WHP_PASS');
+
+// Hide the server-identifying navbar strip and the version footer.
+const HIDE_CSS = `.navbar-text, .brand-full, .navbar-brand { visibility: hidden !important; }`;
+
+async function login(page: Page) {
+  await page.goto(`${BASE}/login.php`, { waitUntil: 'domcontentloaded' });
+  await page.fill('input[name="user"]', USER);
+  await page.fill('input[name="password"]', PASS);
+  await page.click('button[type="submit"]');
+  await page.waitForLoadState('networkidle');
+}
+
+async function redact(page: Page) {
+  await page.addStyleTag({ content: HIDE_CSS });
+  await page.evaluate(() => {
+    const swaps: [RegExp, string][] = [
+      [/whp\d+(-[a-z0-9]+)?\.cloud-hosting\.io/gi, '<your-server>.cloud-hosting.io'],
+      [/WHP\d+(-[A-Z0-9]+)?\b/g, '<YOUR-SERVER>'],
+      [/whp\d+(-[a-z0-9]+)?\b/gi, '<your-server>'],
+      [/\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/g, '<server-IP>'],
+      [/demo-user/g, 'your-username'],
+      // Strip the release/version identifier from the footer.
+      [/Web Hosting Panel\s*-\s*\d{4}\.\d{2}\.\d+/gi, 'Web Hosting Panel'],
+      [/\b\d{4}\.\d{2}\.\d+\b/g, ''],
+    ];
+    const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT);
+    const nodes: Text[] = [];
+    let n: Node | null = walker.nextNode();
+    while (n) { nodes.push(n as Text); n = walker.nextNode(); }
+    for (const node of nodes) {
+      let v = node.nodeValue ?? '';
+      for (const [re, rep] of swaps) v = v.replace(re, rep);
+      if (v !== node.nodeValue) node.nodeValue = v;
+    }
+  });
+}
+
+async function main() {
+  await mkdir(OUT_DIR, { recursive: true });
+  const browser = await chromium.launch({ headless: true });
+  const ctx = await browser.newContext({
+    ignoreHTTPSErrors: true,
+    viewport: { width: 1440, height: 900 },
+    deviceScaleFactor: 2,
+  });
+  const page = await ctx.newPage();
+  try {
+    await login(page);
+
+    // Resolve the demo site's traffic view via the "View Traffic" button.
+    await page.goto(`${BASE}/index.php?page=site-traffic`, { waitUntil: 'networkidle' });
+    await page.locator('a:has-text("View Traffic"), button:has-text("View Traffic")').first().click();
+    await page.waitForLoadState('networkidle');
+    await page.waitForTimeout(1000);
+    const trafficUrl = page.url();
+
+    // 1. Overview — clip to the main content card so the snapshot + daily totals
+    //    frame nicely without the empty side gutters.
+    await redact(page);
+    await page.evaluate(() => window.scrollTo(0, 0));
+    await page.waitForTimeout(300);
+    await page.screenshot({ path: resolve(OUT_DIR, 'traffic-analytics-overview.png'), fullPage: false });
+    console.log('captured traffic-analytics-overview');
+
+    // 2. Day drill-down — click the 23rd (richest demo data), then clip to the
+    //    "Breakdown for ..." card (hourly graph + top pages + bandwidth).
+    await page.locator('a:has-text("2026-06-23")').first().click();
+    await page.waitForLoadState('networkidle');
+    await page.waitForTimeout(1500);
+    await redact(page);
+    const card = page.locator('#day-detail, .card:has-text("Breakdown for")').first();
+    await card.scrollIntoViewIfNeeded().catch(() => {});
+    await page.waitForTimeout(400);
+    if (await card.count()) {
+      await card.screenshot({ path: resolve(OUT_DIR, 'traffic-analytics-day-detail.png') });
+    } else {
+      await page.screenshot({ path: resolve(OUT_DIR, 'traffic-analytics-day-detail.png'), fullPage: false });
+    }
+    console.log('captured traffic-analytics-day-detail');
+    console.log('traffic url was', trafficUrl);
+  } finally {
+    await browser.close();
+  }
+}
+
+main().catch((err) => { console.error(err); process.exit(1); });
Author	SHA1	Message	Date
AnHonestHost DevandClaude Opus 5	b00a5fd8cf	docs: add Email section — client setup + Baruwa retirement notice Replaces the three Outlook 2016 articles (WHMCS 2, 3, 9 — ~62k views) with one client-agnostic setup guide. Outlook 2016 went end of life in October 2025, and the two archiving articles documented a feature the current Outlook doesn't have. Server settings are taken from the live autoconfig endpoint rather than the old articles: IMAP 993/SSL, POP3 995/SSL, SMTP 587/STARTTLS, username is the full address. cPanel settings verified against cpanel01. Adds a Baruwa retirement notice covering the move to Proxmox Mail Gateway in November 2026. Deliberately frames this as a platform change rather than describing our current outbound filtering posture — see the PR discussion. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 14:51:09 -07:00
AnHonestHost DevandClaude Opus 5	425f364f48	docs: add cPanel section; drop the outbound-filtering page Adds a cPanel hosting section so cPanel customers have a correct destination — previously this KB was WHP-only, so cPanel-specific articles had nowhere to redirect to: - cpanel/nameservers (WHMCS 5, 24k views) - cpanel/free-ssl-certificate (WHMCS 8, 18k views) - cpanel/fix-a-403-error (WHMCS 6, 20k views) - cpanel/wordpress-email-from-your-domain (WHMCS 7, 25k views) Rewritten rather than copied where the originals were wrong or thin: - WordPress SMTP told customers to use port 25 unencrypted; now 587/TLS with 465 as the implicit-TLS alternative. - The 403 article now says explicitly that loosening permissions to 777 makes suEXEC refuse harder, since that's the instinctive wrong fix. - AutoSSL gained the actual failure modes (CAA records, .htaccess redirects intercepting validation, domain not added to the account). Also removes email/outbound-spam-filtering, added in the previous commit. Outbound filtering via Baruwa has been disabled and Baruwa is being retired, so the page describes a feature we no longer offer. It needs rewriting around the Proxmox migration before it can ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 14:47:44 -07:00
AnHonestHost DevandClaude Opus 5	ee6b6af107	docs: port still-relevant WHMCS KB articles to the dedicated KB First step of retiring the WHMCS knowledgebase in favour of kb.anhonesthost.com. Ports the four articles that are still accurate and product-agnostic, into three new top-level sections: - domains/ — transferring a domain, flushing a local DNS cache - email/ — why we filter outbound mail - support/ — remote support via RustDesk Content was refreshed rather than copied verbatim: - RustDesk download links were pinned to 1.3.8; now point at /releases/latest (current is 1.4.9). API server switched to https, which the relay serves. - macOS DNS flush gained the killall mDNSResponder step, without which the documented command usually appears to do nothing. - The nameserver list was deliberately not ported — this KB points customers at Dashboard → Server Information instead of hardcoding per-server values. - Added an anti-social-engineering warning to the remote-support page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 14:36:30 -07:00
jknapp	f0ec3395ab	Merge pull request 'docs: link Bichon to its open-source project' (#8 ) from docs/bichon-opensource-link into main Build and deploy / deploy (push) Successful in 24s Details Reviewed-on: #8	2026-06-29 01:31:02 +00:00
jknapp	8c515a8074	Merge branch 'main' into docs/bichon-opensource-link	2026-06-29 01:30:55 +00:00
shadowdaoandClaude Opus 4.8	5fdf55de7f	docs: link Bichon to its open-source project The archival-email page linked to https://anhonesthost.com/bichon/, which does not exist. Point readers at the upstream open-source project instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 18:29:33 -07:00
jknapp	f7d739fe2d	Merge pull request 'docs(how-to): add 'Clear your site's cache' guide' (#7 ) from docs/clear-your-cache into main Build and deploy / deploy (push) Successful in 25s Details Reviewed-on: #7	2026-06-27 04:04:58 +00:00
shadowdaoandClaude Opus 4.8	858d505e7e	docs(how-to): add 'Clear your site's cache' guide Customer-facing troubleshooting for stale content: hard refresh (browser cache) first, then purge LiteSpeed Cache via the WP plugin Toolbox for Optimized Webserver sites, with a note that logged-in views are never cached. Cross-linked from the Optimized Webserver add-on page. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 21:02:17 -07:00
jknapp	240b6d392b	Merge pull request 'docs(email): fix webmail-reachability note and SMTP port guidance' (#5 ) from docs/email-port-webmail-fixes into main Build and deploy / deploy (push) Successful in 22s Details Reviewed-on: #5	2026-06-23 22:15:01 +00:00
jknapp	9762822e97	Merge branch 'main' into docs/email-port-webmail-fixes	2026-06-23 22:14:52 +00:00
jknapp	54bee2cf55	Merge pull request 'docs(archival): retention is for the life of the account, not 14 days' (#6 ) from docs/archival-retention into main Build and deploy / deploy (push) Successful in 24s Details Reviewed-on: #6	2026-06-23 22:14:46 +00:00
shadowdaoandClaude Opus 4.8	ef4a4605b2	docs(archival): correct retention — kept for the life of the account The add-on does not impose a 14-day window or offer "configurable retention." Archived mail is retained for as long as the customer has an active account with us. Replaced the inaccurate "14-day quick-restore window" and "Configurable longer retention" highlights, and softened the compliance use-case wording away from "fixed window." Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 15:13:55 -07:00
shadowdaoandClaude Opus 4.8	3b31acbbac	docs(email): fix webmail-reachability note and outgoing SMTP port guidance - Webmail is hosted at our address (the Webmail button opens it directly), so it does not depend on the customer's domain/DNS. Replaced the incorrect "DNS still propagating" troubleshooting note. - Outgoing SMTP: lead with port 465 (SSL/TLS) as the standard and present 587 (STARTTLS) as the alternate submission port; note that port 25 is for server-to-server and shouldn't be used from a mail client. Updated the IMAP-but-not-SMTP troubleshooting entry to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 15:09:09 -07:00
jknapp	3a526783cb	Merge pull request 'docs(email): update Create an email account for the tabbed layout' (#4 ) from docs/email-tabs into main Build and deploy / deploy (push) Successful in 25s Details Reviewed-on: #4	2026-06-23 21:56:46 +00:00
shadowdaoandClaude Opus 4.8	1769d5dc0b	docs(email): show the create-account form in the Email Accounts screenshot Bumped the demo account's email-account allowance so the page renders the "Create Email Account" button + usage bar instead of the limit-reached state. Updated steps to match the button → modal flow (Create Email Account opens the form; the modal's submit button is "Create Account"). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 14:54:29 -07:00
shadowdaoandClaude Opus 4.8	f1159867df	docs(email): update Create an email account for the new tabbed layout The Email page is now organized into tabs (Email Accounts / Forwarders / Email Domains (DNS)) with a top button strip (Webmail / Admin Panel / Setup Instructions). Reworked the how-to to match: - orient readers to the tabs + top buttons; create on the Email Accounts tab - autodiscovery records now live in Email Domains (DNS) → Autodiscovery Records (DNS) (was "Mail Client Setup") - DKIM is in the DKIM Management section on the Email Domains (DNS) tab - Webmail / Setup Instructions are the top-strip buttons Recaptured whp-email.png (Email Accounts tab) and whp-email-autodiscovery.png (DNS tab) via the rewritten capture-email.ts (clicks the DNS tab; fleet hostnames/IPs redacted, brand demo domain kept). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 14:49:33 -07:00
jknapp	a6269d18fd	Merge pull request 'docs(screenshots): document section capture scripts' (#3 ) from docs/dns-page-rework into main Build and deploy / deploy (push) Successful in 22s Details Reviewed-on: #3	2026-06-22 15:43:02 +00:00
shadowdaoandClaude Opus 4.8	8f42adc799	docs(screenshots): list capture-email.ts in the section-scripts table Completes the section-capture docs after merging main — capture-email.ts (Email page "Mail Client Setup") now appears alongside the other scripts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 08:41:06 -07:00
shadowdao	7f63f064c9	Merge branch 'main' into docs/dns-page-rework	2026-06-22 08:40:31 -07:00
jknapp	c9a08313ca	Merge pull request 'docs(email): mail-client autodiscovery + external-DNS records' (#2 ) from docs/mail-autodiscovery into main Build and deploy / deploy (push) Successful in 29s Details Reviewed-on: #2	2026-06-22 15:36:31 +00:00
shadowdaoandClaude Opus 4.8	0b53569821	docs(email): document mail-client autodiscovery + external-DNS records Reflects the new customer "Mail Client Setup" section on the Email page. - create-an-email-account.mdx: new "Auto-configure your mail app" section — explains clients self-configure from DNS, that domains on our nameservers are already set, and the records to add when DNS is hosted elsewhere (Cloudflare/GoDaddy/etc.) with the full RFC 6186 record table + screenshot. Reframe "Set up your email client" as the manual fallback. - manage-dns-records.mdx: cross-link "Mail autodiscovery records" subsection. - New capture-email.ts + whp-email-autodiscovery.png (fleet-redacted: mail host shown as <mail-server>.cloud-hosting.io; demo domain kept visible). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 08:11:44 -07:00
shadowdaoandClaude Opus 4.8	23cc5a887b	docs(screenshots): document section capture scripts + refresh workflow The README only covered the shots.config.ts/run.ts path. Add a Section capture scripts table (capture-admin/site-builder/dns) and a refresh note distinguishing static pages (npm run screenshots) from interactive states (npx tsx capture-<section>.ts), since reworked sections need the latter. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 15:00:14 -07:00
jknapp	03aa273100	Merge pull request 'docs(whp): rework DNS page for new Domains & DNS UI' (#1 ) from docs/dns-page-rework into main Build and deploy / deploy (push) Successful in 23s Details Reviewed-on: #1	2026-06-11 21:52:34 +00:00
shadowdaoandClaude Opus 4.8	da24dc8c67	docs(whp): rework DNS page for new Domains & DNS UI The WHP DNS area was reworked from the old Domains page (left-side add form + right-side DNS Management dropdown) into a searchable Domains & DNS list plus a dedicated per-domain DNS records editor. - Recapture whp-domains.png against the new list layout - Add screenshots for the Add Domain modal, records editor, inline Add Record row, and bulk-action toolbar - Add capture-dns.ts (fleet-redacted, viewport-only) following the existing capture-admin.ts pattern - Rewrite add-a-domain.mdx Add Domain steps for the modal flow and point at the new records editor - Add manage-dns-records.mdx how-to (add/edit/delete, type filter, bulk actions, verification, troubleshooting); renumber sidebar order Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 14:50:21 -07:00
shadowdaoandClaude Opus 4.8	08adca6955	docs(whp): add backend-switching how-to + Optimized Webserver (OLS) add-on page Build and deploy / deploy (push) Successful in 25s Details - how-to/switching-site-backend: change a site's container type between standard PHP/FPM and the premium LiteSpeed/OLS backend; required steps to move off premium before cancelling the add-on (panel blocks the disable otherwise). - add-ons/optimized-webserver: what the OLS/LSCache add-on is, advantages, when NOT to use it, how to enable/use, and cancellation requirements. - add-ons/overview: list the new add-on. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 06:52:11 -07:00
shadowdaoandClaude Opus 4.7	6ee2cf13b0	kb(whp/admin): document panel HSTS + VM-rebuild lockout recovery Build and deploy / deploy (push) Successful in 23s Details The WHP panel sends Strict-Transport-Security max-age=31536000 includeSubDomains on every response (correct for prod). When a server is rebuilt, the regenerated self-signed cert no longer matches what the admin's browser cached as HSTS-valid, and there is no clickable 'proceed unsafely' escape — the admin is locked out of their own panel by hostname. Add a Caution Aside under Network & SSL describing the symptom, the two-browser HSTS confirmation pattern, and the three recovery paths (IP-direct + LE issuance, browser HSTS clear, real cert preserved across rebuilds). Frames LE issuance as a first-day operation, not an incident response. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-29 09:21:08 -07:00
shadowdao	33d1da92ca	docs(admin): add Data-drive encryption (LUKS) article Build and deploy / deploy (push) Successful in 25s Details Covers the opt-in LUKS2 encryption of /docker available on new server installs. Reboot UX (web unlock at :8444, SSH fallback), threat model in plain English, what LUKS does and doesn't protect against, header backup handling, passphrase rotation outline, and the "do not enable this if you need unattended reboots" caveat. Sidebar order 7 (after Backups in the admin section). Linked from the admin overview "What's in this section" list and from the VDS comparison section of "What is containerized hosting?". No cost / pricing language by design — operational positioning is still being decided.	2026-05-23 08:59:16 -07:00
shadowdao	69439afe4a	docs(local-dev): add 'Local development' section + PHP 8.5 support Build and deploy / deploy (push) Successful in 23s Details Adds /whp/local-dev/ with three articles documenting the public cloud container images on repo.anhonesthost.net/cloud-hosting-platform/: - overview: dev/prod parity pitch, prerequisites, table of images, link to the Gitea org, and a note that this is for customers comfortable with Docker (the hosted side needs none of this). - php-apache: cloud-apache-container (cac). PHP 7.4 through 8.5 side by side, default 8.3, AlmaLinux 9 + Apache mod_ssl. Documents image tags, local-dev.sh flags, manual docker command, bind-mount layout, WordPress install, helper scripts (instance_start / instance_stop / instance_logs / instance_db_info), and cleanup. - node: cloud-node-container (cnoc). Node 18/20/22, default 20, AlmaLinux 9 + Nginx (SSL + HTTP→HTTPS redirect) + PM2 + Memcached. Same shape: tags, flags, manual docker, where code goes (user/app/), logs layout, helpers, cleanup. Sidebar gains a 'Local development' group between Site Builder and Reference. Section redirect /whp/local-dev/ -> overview added to the section-landing redirect set.	2026-05-18 12:01:49 -07:00
shadowdao	aeb033bae5	feat(routing): redirect section landings + harden 404 / no directory listings Build and deploy / deploy (push) Successful in 23s Details - astro.config.mjs: section-only URLs now redirect to the first article in that section. /whp/admin/ used to render Apache's directory listing because no index.html existed; now it serves a meta-refresh to /whp/admin/overview/. Same for /whp/, /whp/getting-started/, /whp/how-to/, /whp/site-builder/, /whp/reference/, /whp/add-ons/. - public/.htaccess: ships in dist, disables Options Indexes + MultiViews (defense in depth so any future section without a redirect doesn't leak a listing), and routes 404/403 to /404.html. - src/content/docs/404.md: replaces the bare 'check the URL' tagline with two explicit actions — 'Go to the knowledge base home' and 'WHP getting started'.	2026-05-18 11:18:35 -07:00
shadowdao	119d376029	docs(admin): rewrite + extend WHP super-admin section from real UI Build and deploy / deploy (push) Successful in 24s Details Verified every page against the live admin panel on whp01 (read-only). Five existing articles rewritten; one new article added; customer-facing backups article updated to match server reality. Article changes - overview: super admin = the root user only (no UI to add another); WHMCS portal route doesn't apply for admin; accurate sidebar map of every admin-only section; customer backups don't cover server config (multiple locations, not just /etc — full-server backup is the right safety net). - server-settings: walked all six tabs (System / Services / Mail / DNS / Network & SSL / Security); clarified that host Apache + PHP-FPM serve the WHP control panel, not customer sites; that MySQL runs as a container so host MySQL config is client-facing; that custom container needs are met by publishing a custom Docker image (linked to repo.anhonesthost.net/cloud-hosting-platform/ for examples). - coraza-waf: real Firing rules / CRS catalog / Activity tabs; global WAF mode pill (off/detect/enforce); per-rule + per-host overrides; Ask AI link; security.db source-of-truth + SIGHUP reload note. - site-monitoring: split into the three actual admin pages — AI Monitor dashboard, Issues, Ignore Rules — with stat tiles + health-check timeline + ignore-rule AND-semantics. - user-management: account types corrected to full / domain_dns / mail_dns (verified in web-files/pages/user-management.php:26); system users are protected against deletion (verified is_protected_user in web-files/libs/usermgmt.php:697); delegated users are admin-editable (not read-only); suspension page is served by haproxy's 503 errorfile (verified in haproxy-manager-base/haproxy_tarpit_config.txt:31) so troubleshooting points at haproxy reload / container logs. - new admin/backups: customer-data backups vs full-server backups; auto-backups only run with a default target; how to add global vs per-customer targets; how to fire on-demand backups for any user; troubleshooting around missing targets / failed test / disk pressure. - how-to/backups (customer): aside about default-target requirement; new section explaining what full-server backups cover vs customer backups (managed plans + VDS covered by AnHonestHost; elsewhere is the server operator's responsibility). New components / tooling - admin-signin partial: 'sign in directly at :8443 as root'. - Head.astro override + medium-zoom: click-to-zoom lightbox on every article image; auto-reattaches after Starlight client navigation. - capture-admin.ts: read-only Playwright capture for admin docs with multi-pass redaction (server hostnames, mail server, customer domains, customer usernames in table cells, IPs except RFC1918 and public resolvers, password/key/token/secret/api input values, plus LiteLLM URLs, model names, JWT/sk-prefix API keys, root → admin).	2026-05-18 10:49:43 -07:00