diff --git a/astro.config.mjs b/astro.config.mjs
index da2605f..c71c95b 100644
--- a/astro.config.mjs
+++ b/astro.config.mjs
@@ -19,6 +19,10 @@ export default defineConfig({
'/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: {
@@ -85,6 +89,22 @@ export default defineConfig({
},
],
},
+ {
+ 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,
diff --git a/src/content/docs/cpanel/fix-a-403-error.mdx b/src/content/docs/cpanel/fix-a-403-error.mdx
new file mode 100644
index 0000000..c57d413
--- /dev/null
+++ b/src/content/docs/cpanel/fix-a-403-error.mdx
@@ -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:
+
+
+
+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.
+
+
+
+## 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.
+
+
+
+## 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?
+
+
diff --git a/src/content/docs/cpanel/free-ssl-certificate.mdx b/src/content/docs/cpanel/free-ssl-certificate.mdx
new file mode 100644
index 0000000..ab8f175
--- /dev/null
+++ b/src/content/docs/cpanel/free-ssl-certificate.mdx
@@ -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:
+
+
+
+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.
+
+
+
+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.
+
+
+
+## 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?
+
+
diff --git a/src/content/docs/cpanel/nameservers.mdx b/src/content/docs/cpanel/nameservers.mdx
new file mode 100644
index 0000000..e9af8b8
--- /dev/null
+++ b/src/content/docs/cpanel/nameservers.mdx
@@ -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.
+
+
+
+## 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.
+
+
+
+## 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?
+
+
diff --git a/src/content/docs/cpanel/wordpress-email-from-your-domain.mdx b/src/content/docs/cpanel/wordpress-email-from-your-domain.mdx
new file mode 100644
index 0000000..f4b0951
--- /dev/null
+++ b/src/content/docs/cpanel/wordpress-email-from-your-domain.mdx
@@ -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.
+
+
+
+## Step 1 — Create a mailbox to send from
+
+
+
+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.
+
+
+
+## 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 |
+
+
+
+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?
+
+
diff --git a/src/content/docs/domains/flush-your-dns-cache.mdx b/src/content/docs/domains/flush-your-dns-cache.mdx
new file mode 100644
index 0000000..a21483f
--- /dev/null
+++ b/src/content/docs/domains/flush-your-dns-cache.mdx
@@ -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.
+
+
+
+## Windows
+
+
+
+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."*
+
+
+
+## macOS
+
+
+
+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.
+
+
+
+
+
+## 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?
+
+
diff --git a/src/content/docs/domains/transferring-a-domain-to-us.mdx b/src/content/docs/domains/transferring-a-domain-to-us.mdx
new file mode 100644
index 0000000..a4a06b8
--- /dev/null
+++ b/src/content/docs/domains/transferring-a-domain-to-us.mdx
@@ -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.
+
+
+
+## Confirming the transfer
+
+
+
+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.
+
+
+
+## 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.
+
+
+
+## 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?
+
+
diff --git a/src/content/docs/email/set-up-your-email-client.mdx b/src/content/docs/email/set-up-your-email-client.mdx
new file mode 100644
index 0000000..520c8e0
--- /dev/null
+++ b/src/content/docs/email/set-up-your-email-client.mdx
@@ -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.
+
+
+
+## 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.
+
+
+
+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.
+
+
+
+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 |
+
+
+
+### 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.
+
+
+
+## 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?
+
+
diff --git a/src/content/docs/email/spam-filtering-changes.mdx b/src/content/docs/email/spam-filtering-changes.mdx
new file mode 100644
index 0000000..2ca9728
--- /dev/null
+++ b/src/content/docs/email/spam-filtering-changes.mdx
@@ -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.
+
+
+
+## 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?
+
+
diff --git a/src/content/docs/support/remote-support.mdx b/src/content/docs/support/remote-support.mdx
new file mode 100644
index 0000000..722c079
--- /dev/null
+++ b/src/content/docs/support/remote-support.mdx
@@ -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.
+
+
+
+## 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.
+
+
+
+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.
+
+
+
+## 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.
+
+
+
+## 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?
+
+
diff --git a/src/pages/index.astro b/src/pages/index.astro
index 57bfaa4..60db0b6 100644
--- a/src/pages/index.astro
+++ b/src/pages/index.astro
@@ -23,10 +23,25 @@ const PRODUCT_META: Record