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

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

@@ -7,6 +7,20 @@ An AI Gateway public resource is a protocol-aware reverse proxy on a fully quali
 
 This page covers how the **resource** works: reachability, authentication, and what you attach. Providers, keys, model routing, the catalog, and client setup live in [AI Gateway](/manage/ai/overview).
 
+## Benefits
+
+- Coding agents work from anywhere, with no Pangolin client on the device.
+- Provider API keys stay in Pangolin. Users get virtual API keys that you can revoke without rotating the provider key.
+- Identity keys follow user and role grants, so removing someone's access disables their key.
+- One URL can front several providers, with model routing, budgets, and usage analytics in one place.
+
+## Use Cases
+
+- Give a team Claude Code, Codex, or Gemini CLI on company provider accounts.
+- Issue manual keys to CI pipelines, scripts, or internal services that call a model API.
+- Track AI usage per user and key, and cap spend by role, key, or model with [budgets](/manage/ai/budgets).
+- Limit which models each team can use with [model routing](/manage/ai/providers/model-routing).
+
 ## How It Works
 
 1. You assign a FQDN on a domain managed in Pangolin and set the resource type to **AI Gateway**.

content/docs/manage/resources/public/healthchecks-failover.mdx

@@ -5,6 +5,19 @@ description: "Monitor public resource targets and automatically remove unhealthy
 
 Health checks for public resources monitor each target and keep bad targets out of traffic automatically. When a target fails its check, Pangolin marks it unhealthy and removes it from load balancing. When it recovers and passes again, Pangolin adds it back.
 
+## Benefits
+
+- Traffic is only sent to targets that are responding, so users don't hit a broken backend.
+- Failover and recovery are automatic, with no manual changes to the resource.
+- Thresholds keep a brief blip from pulling a target out of rotation.
+- Health status feeds [alert rules](/manage/alerting/alert-rules) and the [maintenance page](/manage/resources/public/maintenance), so you can notify admins and users when something fails.
+
+## Use cases
+
+- Keep a web app online when one of several servers goes down or restarts.
+- Fail over between sites in different locations for disaster recovery.
+- Roll out an update one target at a time while the others keep serving traffic.
+
 ## How it works
 
 For every target on a public resource, Pangolin runs checks at your configured intervals and evaluates the result against your health criteria.

content/docs/manage/resources/public/http-https.mdx

@@ -7,6 +7,23 @@ HTTP and HTTPS public resources are the most common public resource type. They e
 
 Users open the resource URL in any web browser. No Pangolin client is required.
 
+## Benefits
+
+- Publish apps from behind NAT or a firewall without opening inbound ports or needing a public IP on the backend.
+- Every resource gets a valid TLS certificate that Pangolin issues and renews.
+- Unauthenticated visitors are stopped at Pangolin before any traffic reaches your app.
+- SSO, identity providers, and context rules like geo-blocking protect apps that have no login of their own.
+- Multiple targets across sites give load balancing, health checks, and automatic failover.
+- Users only need a browser, so contractors, customers, and personal devices can get access without installing anything.
+
+## Use Cases
+
+- Put self-hosted apps such as Grafana, Home Assistant, or an internal wiki behind SSO.
+- Publish a public website or API running on a home server or private network.
+- Share a staging site with a client using a PIN, passcode, or expiring link.
+- Restrict an admin panel to certain countries, IP ranges, or URL paths with access rules.
+- Load balance a web app across servers in different locations.
+
 ## How It Works
 
 1. You assign a FQDN on a domain managed in Pangolin.

content/docs/manage/resources/public/maintenance.mdx

@@ -12,6 +12,18 @@ Pangolin can display a customizable maintenance page to users when a resource is
     <img src="/images/maintenance_page.png" alt="Maintenance Page Preview"/>
 </Frame>
 
+## Benefits
+
+- Users see a clear message you write instead of a gateway error when a resource is down.
+- An estimated completion time sets expectations and cuts down on support requests.
+- Automatic mode covers unplanned outages without anyone having to switch it on.
+
+## Use Cases
+
+- Announce a planned maintenance window for an app or API.
+- Tell users a service is temporarily unavailable when every target fails its health check.
+- Hold a page in place while you migrate a resource to new servers.
+
 ## Configuration
 
 Title: The main title text displayed on the maintenance page.

content/docs/manage/resources/public/raw-resources.mdx

@@ -9,6 +9,28 @@ Because TCP and UDP resources are not protocol-aware, they do **not** enforce Pa
 
 For workloads that do not need a public proxy, prefer a [private host or CIDR resource](/manage/resources/understanding-resources#private-resource-types) so traffic stays on the zero-trust tunnel with full access control.
 
+## Benefits
+
+- Expose any TCP or UDP service, whatever the protocol, without opening ports on the backend network.
+- The backend stays behind NAT or a firewall. Only the Pangolin server needs a public port.
+- Players or users connect with their normal client software, with no Pangolin client to install.
+- Multiple targets across sites give round-robin routing and failover.
+- Proxy Protocol can pass the original client IP through to backends that support it.
+
+## Use Cases
+
+- Host a game server, such as Minecraft, from a home network.
+- Publish a VoIP, MQTT, or other non-HTTP service that clients reach by host and port.
+- Give public access to a service that has its own authentication and needs no extra layer from Pangolin.
+
+## How TCP and UDP Resources Work
+
+1. You map a port on the Pangolin server to the resource.
+2. A client connects to `<pangolin-server>:<port>`.
+3. Pangolin forwards the traffic as-is through the tunnel to a site, which delivers it to the target.
+
+Pangolin does not inspect or authenticate the traffic, so any security has to come from the service itself.
+
 ## Target Configuration
 
 TCP and UDP resources use **[targets](/manage/resources/public/targets)** like HTTP/HTTPS resources:

content/docs/manage/resources/public/rdp.mdx

@@ -9,6 +9,20 @@ RDP public resources render a full Remote Desktop Protocol client in the browser
   <img src="/images/rdp-public.gif" alt="Remote desktop session rendered in the Pangolin web dashboard" />
 </Frame>
 
+## Benefits
+
+- Users get a Windows desktop from any browser, with no remote desktop software or Pangolin client to install.
+- Port 3389 is never exposed to the internet, which removes a common target for brute-force attacks.
+- SSO, identity providers, and access rules sit in front of Windows authentication.
+- File transfer and clipboard copy and paste work in the browser session.
+
+## Use Cases
+
+- Let staff reach their office workstation from home or a personal device.
+- Give vendors or support staff time-limited access to a Windows server.
+- Reach Windows machines on a factory floor, lab, or branch office behind NAT.
+- Use Windows-only line-of-business apps from Mac, Linux, or Chromebook devices.
+
 ## Video Walkthrough
 
 <iframe

content/docs/manage/resources/public/resource-policies.mdx

@@ -13,6 +13,23 @@ Resource policies let you define authentication and access rule settings once an
 Resource policies currently apply to **public resources** only. Support for private resources is coming soon.
 </Note>
 
+## Benefits
+
+- Define authentication and access rules once instead of repeating them on every resource.
+- A change to a policy applies to every linked resource at once, so resources don't drift apart.
+- Resources can still add their own users, roles, and rules on top of the shared baseline.
+- A consistent baseline makes it easier to see and review how your public resources are protected.
+
+## Use Cases
+
+- Require SSO and block the same set of countries on every app a team publishes.
+- Apply one IP allow list to all internal tools, then grant individual apps to extra roles.
+- Keep the same PIN or email OTP settings across a group of resources shared with a client.
+
+## How Resource Policies Work
+
+A public resource either has its own inline policy or links to a shared policy. When it links to one, it inherits every setting in that policy, and those settings show as read-only on the resource. Users, roles, and access rules you add on the resource combine with the shared policy rather than replacing it. See [Additive Policies](#additive-policies).
+
 ## What a Resource Policy Contains
 
 A resource policy holds the same settings you configure on a public resource's authentication and access tabs:

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

@@ -9,6 +9,20 @@ SSH public resources render a full interactive terminal in the browser. Users vi
   <img src="/images/ssh-public.gif" alt="Interactive SSH terminal rendered in the Pangolin web dashboard" />
 </Frame>
 
+## Benefits
+
+- Users get a terminal from any browser, with no SSH client, keys, or Pangolin client on their device.
+- The host's SSH port is never exposed to the internet. Pangolin authentication happens before a session can start.
+- SSO, identity providers, and access rules like geo-blocking apply to shell access.
+- With automated provisioning, users are created on the host from their Pangolin identity, so there are no shared accounts or keys to manage.
+
+## Use Cases
+
+- Get emergency access to a server from a borrowed or locked-down computer.
+- Give contractors shell access to a single server without setting up a VPN or SSH keys for them.
+- Manage home lab or edge devices from a phone or tablet.
+- Let support staff reach customer appliances behind NAT through a site.
+
 ## Video Walkthrough
 
 <iframe

content/docs/manage/resources/public/vnc.mdx

@@ -5,6 +5,19 @@ description: "View and control a remote display through a VNC client rendered in
 
 VNC public resources render a full VNC client in the browser. Users visit a FQDN, complete Pangolin authentication, and get an interactive remote display session without installing a VNC viewer.
 
+## Benefits
+
+- Users get a remote display from any browser, with no VNC viewer or Pangolin client to install.
+- The VNC server is never exposed to the internet. Pangolin authentication happens before a session can start.
+- SSO, identity providers, and access rules protect VNC servers that often have weak or no passwords of their own.
+- Works with Linux desktops, macOS screen sharing, and embedded devices that expose a VNC server.
+
+## Use Cases
+
+- Remotely support a Linux or macOS desktop.
+- Reach the display of a kiosk, digital sign, or industrial HMI panel behind NAT.
+- Get console access to a virtual machine whose hypervisor exposes VNC.
+
 ## How It Works
 
 1. You assign a FQDN on a domain managed in Pangolin.

content/docs/manage/resources/public/wildcard-resources.mdx

@@ -11,6 +11,26 @@ With a wildcard public resource, one resource owns an entire subdomain level: ev
 
 Access rules and authentication you set on that resource apply to all hostnames matched by the wildcard. If you enable a PIN code, every hostname under the wildcard requires that PIN. You can also attach a [resource policy](/manage/resources/public/resource-policies) so the same shared settings apply to the wildcard and any other linked public resources.
 
+## Benefits
+
+- New hostnames work as soon as your downstream proxy serves them, with no new resource in Pangolin.
+- One set of authentication and access rules protects every hostname at that level.
+- Downstream routing keeps working, since the original `Host` header is passed through.
+- A single wildcard certificate covers every hostname, so there is no certificate to issue per app.
+
+## Use Cases
+
+- Put a Kubernetes ingress controller or an existing reverse proxy such as Traefik, Caddy, or nginx behind Pangolin.
+- Give each pull request or branch its own preview URL, such as `pr-123.preview.example.com`.
+- Host per-customer or per-tenant subdomains for a multi-tenant app.
+
+## How Wildcard Resources Work
+
+1. You set the resource's subdomain to `*`, optionally under a parent such as `*.apps`.
+2. DNS sends every hostname at that level to Pangolin, which serves a wildcard certificate for it.
+3. Pangolin applies the resource's authentication and access rules to the request.
+4. The request goes through the tunnel to the target with its original `Host` header, and your downstream proxy routes it to the right app.
+
 ## Creating a Wildcard Resource
 
 In the resource’s domain settings, set the subdomain field to `*` to match any label at that level. You can combine this with a parent subdomain, such as `*.apps`, so only hostnames under `apps` are covered, as long as TLS and DNS cover that same scope.