Add use benefits, use cases, and how to on each section

content/docs/manage/resources/private/ai-gateway.mdx

@@ -7,6 +7,21 @@ A private AI Gateway resource exposes an AI API only to devices connected with t
 
 This page covers how the **resource** works: reachability, access, and what you attach. Providers, model routing, the catalog, and client setup live in [AI Gateway](/manage/ai/overview).
 
+## Benefits
+
+- The gateway is never reachable from the public internet, only from connected clients with access.
+- There are no API keys to issue or leak. The client connection identifies the caller.
+- Provider API keys stay in Pangolin and never reach users' machines.
+- Calls are attributed to the connected user, so [usage analytics](/manage/ai/usage-analytics) and [session logs](/manage/ai/session-logs) show who made each one.
+- Self-hosted model servers on a site network can sit behind the same gateway as cloud providers.
+
+## Use Cases
+
+- Give employees Claude Code, Codex, or other coding agents through company provider accounts without handing out provider keys.
+- Keep AI access limited to managed devices that run the Pangolin client.
+- Serve a self-hosted model, such as one running on Ollama or vLLM, to your team without exposing it to the internet.
+- Give machine clients, such as CI jobs or internal agents, model access tied to their own identity.
+
 ## How It Works
 
 1. You create a private resource with type **AI Gateway** on a Pangolin Site and attach one or more org-level [providers](/manage/ai/providers/overview).

content/docs/manage/resources/private/cidr.mdx

@@ -7,6 +7,28 @@ A CIDR private resource exposes an entire IP range on your remote network to con
 
 CIDR resources are the usual choice for whole subnets or network segments instead of creating a separate host resource for every machine.
 
+## Benefits
+
+- One resource covers a whole subnet, so you don't have to create a resource for every machine.
+- Hosts added to the range later are reachable right away, with no change in Pangolin.
+- Access is still granted per user, role, or machine client, and port restrictions apply to the whole range.
+- Attaching several sites that reach the same range gives redundant paths with automatic failover.
+- CIDR resources are the building block for [subnet routers](/manage/clients/subnet-router), which give devices that can't run the client access to Pangolin resources.
+
+## Use Cases
+
+- Give IT or operations staff access to a full office or data center LAN.
+- Reach a cloud VPC, such as an AWS VPC or Azure VNet, through a site running inside it.
+- Manage a range of network equipment, IP cameras, or industrial devices on a dedicated subnet.
+- Let a team reach a lab or staging network where machines change often.
+- Restrict a range to a single protocol, such as HTTPS on port `443`, across every host in it.
+
+## How CIDR Resources Work
+
+When a user with access connects, the Pangolin client installs a route for the whole prefix. Any traffic to an address in that range goes over the encrypted tunnel to a site attached to the resource, and the site forwards it to the matching host on its network.
+
+The client only routes the prefixes a user has access to, so traffic to other addresses, including the public internet, stays on the device's normal network path. When a host resource and a CIDR resource overlap, the client prefers the more specific route.
+
 ## Destination
 
 A CIDR resource destination is an IP range in CIDR notation—for example `10.1.0.0/16`. Any address inside the range is covered for users who have been granted access.

content/docs/manage/resources/private/host.mdx

@@ -7,6 +7,28 @@ A host private resource exposes a single machine on your remote network to conne
 
 Host resources are the most common private resource type. They do not render in a browser—you use native applications (a database client, `curl`, an RDP client, etc.) against the destination address while the Pangolin client is connected.
 
+## Benefits
+
+- Nothing is exposed to the public internet. The host is only reachable by clients that are connected and granted access.
+- Access is scoped to a single machine, not the whole network behind the site, so users only reach what they need.
+- Any TCP or UDP protocol works, and you can narrow it to specific ports with port restrictions.
+- An alias gives users a stable, memorable name for the host without any external DNS records.
+- Attaching several sites gives the host redundant paths with automatic failover.
+
+## Use Cases
+
+- Connect to a database such as PostgreSQL or MySQL with your usual client, without opening its port to the internet.
+- Reach an internal API, admin panel, or dashboard from a laptop on any network.
+- Use a native RDP, SSH, or VNC client against a single server.
+- Reach a service that only listens on the site host's loopback interface, through an alias.
+- Give a machine client, such as a CI runner, access to one build server or artifact store.
+
+## How Host Resources Work
+
+When a user with access connects, the Pangolin client starts routing traffic for the host over the encrypted tunnel. That covers the destination address and, if the resource has one, its alias, which the client resolves through Pangolin. A site attached to the resource receives the traffic and sends it to the destination on its local network. Responses come back the same way.
+
+The site resolves the destination, so an FQDN only needs to resolve from the site's network, not from the user's device. Traffic to any other address stays on the user's normal network path, since the client only routes resources the user has access to.
+
 ## Destination
 
 Every host resource has a [destination](/manage/resources/private/destinations): a single IP address or fully qualified domain name (FQDN).

content/docs/manage/resources/private/multi-site-routing.mdx

@@ -4,6 +4,19 @@ description: "Use multiple sites on a private resource for resilient routing and
 ---
 When you configure a private resource, you can attach more than one site. Pangolin then chooses how to reach the resource’s destination through those sites, similar in spirit to running multiple connectors into the same network: traffic is steered toward whichever path is most suitable at the time.
 
+### Benefits
+
+- A single site or connector host going down doesn't cut users off from the resource.
+- Clients route through the best online site, weighing factors such as latency, so users never choose a site by hand.
+- Failover is automatic. You don't need to edit the resource or reconnect clients.
+- You can attach as many sites as you need to one resource.
+
+### Use Cases
+
+- Run two connectors into the same office LAN so access survives a server reboot or hardware failure.
+- Reach a cloud VPC through connectors in different availability zones.
+- Do maintenance or upgrades on one connector while users keep working through another.
+
 ### How Routing Works
 
 Pangolin evaluates the sites you selected and routes client traffic through the site that is most ideal from the client’s perspective. That decision weighs factors such as latency and whether the site is reachable. If a site becomes unavailable, clients begin using the next best online site without you having to reconfigure the resource.

content/docs/manage/resources/private/private-http.mdx

@@ -7,6 +7,28 @@ Private HTTP/HTTPS resources expose web applications over the Pangolin tunnel wi
 
 Once connected, users open the resource in a normal web browser at a URL like `https://my-app.internal.example.com`. The Pangolin client resolves the hostname privately, traffic travels over the peer-to-peer tunnel, and the site connector terminates TLS and runs a reverse proxy to the backend.
 
+## Benefits
+
+- Web apps get a real hostname on your domain and a valid TLS certificate, so browsers show no certificate warnings.
+- Users browse on the default port with a clean URL, with no port numbers or IP addresses to remember.
+- Nothing is reachable from the public internet. The hostname only resolves for connected clients with access.
+- Identity comes from the client connection, so users don't see an extra login page in front of the app.
+- Traffic travels peer-to-peer from the client to the site, and TLS terminates at the site, close to the app.
+
+## Use Cases
+
+- Publish internal tools such as wikis, Grafana, or admin panels only to employees on the Pangolin client.
+- Serve a self-hosted app over HTTPS when it only speaks plain HTTP on the local network.
+- Replace a public resource for sensitive apps that should never have a public login page.
+- Give contractors browser access to a staging site without exposing it to the internet.
+
+## How Private HTTP Resources Work
+
+1. You assign a hostname on a domain configured in Pangolin and set the destination host, port, and scheme.
+2. The Pangolin control plane provisions routing and pushes a certificate for that hostname to the site.
+3. A connected user with access opens the URL. The Pangolin client resolves the hostname privately and sends the request over the tunnel to the site.
+4. A reverse proxy on the site terminates TLS and proxies the request to the destination.
+
 For a deep dive into how private HTTPS reverse proxying works—including DNS hijacking, overlay addressing, certificate push, and the embedded edge proxy—see [Building a Peer-to-Peer Alternative to Cloudflare Tunnels](https://pangolin.net/news/building-a-peer-to-edge-peer-reverse-proxy).
 
 ## Hostname, DNS, and TLS

content/docs/manage/resources/private/ssh.mdx

@@ -5,6 +5,21 @@ description: "Connect to remote hosts over the Pangolin tunnel using the Pangoli
 
 Private SSH resources let users connect to remote hosts from their terminal over the Pangolin tunnel. Unlike [public SSH resources](/manage/resources/public/ssh), private SSH is **not** browser-rendered.
 
+## Benefits
+
+- SSH servers are never exposed to the public internet. Only connected clients with access can reach them.
+- With automated provisioning, users sign in with their Pangolin identity and get short-lived certificates, so there are no long-lived keys to distribute or rotate.
+- Accounts are created on the host just in time, with sudo and group permissions set by role.
+- Users keep a native terminal workflow, including their own shell, tools, and SSH options.
+- Removing a user's access in Pangolin cuts off their path to the host, whatever credentials they still hold.
+
+## Use Cases
+
+- Give engineers SSH access to production or staging servers based on their role.
+- Reach many servers behind one bastion, with an auth daemon provisioning users on each host.
+- Replace a shared jump host and hand-managed `authorized_keys` files.
+- Let on-call staff get into servers from anywhere without a separate VPN.
+
 ## How It Works
 
 1. The user connects with the Pangolin client (GUI or CLI).