Merge branch 'dev' of github.com:fosrl/docs-v2 into dev

2026-09-17 03:19:08 +02:00 · 2026-09-10 17:04:10 -04:00
parent 44f840f179 e90acc688c
commit aaab1bcaa1
31 changed files with 504 additions and 146 deletions
@@ -1,35 +1,38 @@
 ---
 title: "How Pangolin Works"
-description: "Learn about the fundamentals of Pangolin and how they work together to provide simple and secure remote access."
+description: "Learn about the fundamentals of Pangolin and how they work together."
 ---
+
+This page explains Pangolin's concepts: the server, sites, resources, users, and clients. Read it first. For a more technical picture of the software components and how they interact, see [System Architecture](/development/system-architecture) after this page.
+
 ## Basic Steps

 <Steps>
-<Step title="Link remote networks with sites">
-  Join remote networks together using site connectors. Pangolin's lightweight connectors use intelligent routing and NAT traversal to make any network anywhere available.
+<Step title="Make remote networks available with sites">
+  Access remote networks using site connectors. Pangolin's lightweight connectors use intelligent routing and NAT traversal to make any network anywhere available. Once a site is created, you can access resources on that network from anywhere.
 </Step>

 <Step title="Define resources">
-  Create resources that represent services or entire network ranges available for remote access. Resources can be public or fully private.
+  Create resources for the things users should reach on the network of your site. Each resource follows a protocol: HTTPS in the browser, an IP or network range over the client, SSH, remote desktop, LLM access, and more. Resources can be public or fully private.
 </Step>

 <Step title="Users access resources">
-  Authenticated users access resources through a web browser (public resources) or when connected with a Pangolin client (private resources). The same users, roles, and policies apply across both—users never pick a site; Pangolin routes to the right connector automatically.
+  Authenticated users access resources via the protocol of the resource. Commonly, public resources are accessed through a web browser, while private resources are accessed through a Pangolin client. The same users, roles, and policies apply across both. Users don't think about connecting to a site, they just access resources and Pangolin routes to the right connector automatically.
 </Step>
 </Steps>

 ## Key Concepts

-Pangolin relies on several components that work together to provide secure remote access. Each component has a specific role in ensuring that only authenticated users can access the resources they are authorized to use.
+Pangolin relies on several components that work together to provide secure networking. Each component has a specific role in ensuring that only authenticated users can access the resources they are authorized to use.

 ### Pangolin Server

-The Pangolin server is the central coordination component for your network. It stores configuration changes, manages access policies, and coordinates connections between clients and sites. The server handles user authentication and generates access control lists that determine what resources each user can reach.
+The Pangolin server is the central coordination component for your network. It stores configuration changes, manages access policies, and coordinates connections between clients and sites. The server handles user authentication, generates access control lists that determine what resources each user can reach, hosts the UI and API, and more. It is the brains of your Pangolin network.

-You can use [Pangolin Cloud](https://app.pangolin.net/auth/signup), which is fully managed, or you can self-host your own Pangolin server for complete control over your infrastructure and data.
+You can use [Pangolin Cloud](https://app.pangolin.net/auth/signup), which is fully managed, or you can self-host your own Pangolin server for complete control over your infrastructure and data. See [Pangolin Cloud vs. Self-Hosted](/about/pangolin-cloud-vs-self-hosted).

 <Card title="Try free on Pangolin Cloud" icon="cloud" href="https://app.pangolin.net/auth/signup" arrow="true" cta="Sign up free">
-  Fastest way to get started with the fully managed control plane. No credit card required.
+  Fastest way to get started with the fully managed control plane.
 </Card>

 <Card title="Read about how to self-host Pangolin" icon="server" href="/self-host/quick-install">
@@ -38,11 +41,23 @@ You can use [Pangolin Cloud](https://app.pangolin.net/auth/signup), which is ful

 ### Sites

-Sites connect remote networks to your Pangolin server. They use Newt connectors to create secure tunnels from remote networks back to Pangolin. Sites let you expose resources on those networks to authorized users.
+Sites connect remote networks to your Pangolin server. They use Pangolin Site connectors (sometimes referred by their engineering name, "Newt") to create secure tunnels from remote networks back to Pangolin. Sites let you expose [resources](/manage/resources/understanding-resources) on those networks to authorized users.

-Sites run behind firewalls on remote networks. They maintain outbound connections to the Pangolin server. By default, sites block all traffic until you define resources and grant access. This ensures that just deploying a site does not expose any network resources.
+Sites are an expected to entirely be managed by administrators and are typically set-and-forget. Users don't need to know about sites, they just access resources that are available on the site.

-The Newt connector handles tunnel creation, NAT traversal, and routing. It makes remote networks available without requiring complex firewall rules or public IP addresses. Newt sites also unlock browser-based SSH, RDP, and VNC resources, private HTTP with edge TLS termination, and intelligent multi-site routing when the same resource is reachable from more than one location.
+<Frame caption="Manage Sites in the Pangolin dashboard, with status, uptime, and resource counts per site.">
+  <img src="/images/sites.png" alt="Manage Sites page in the Pangolin dashboard"/>
+</Frame>
+
+Sites run behind firewalls on remote networks. They maintain outbound connections to the Pangolin server. By default, sites block all traffic until you define resources and grant access. This ensures that just [deploying a site](/manage/sites/install-site) does not expose any network resources.
+
+<Frame caption="Creating a site: pick a platform, copy the install command, and run the connector on the remote network.">
+  <img src="/images/create-site.png" alt="Create Site page in the Pangolin dashboard"/>
+</Frame>
+
+When [private resources](/manage/resources/understanding-resources#private-resource-types) (VPN-like access) are used, [clients](/manage/clients/understanding-clients) connect directly to the site connector using peer-to-peer (P2P) [NAT traversal](/manage/clients/nat-traversal). If the client is on the same network as the site connector, it will use the [local network address](/manage/clients/nat-traversal#same-network-detection).
+
+The site connector is very intelligent and handles tunnel creation, NAT traversal, and routing. It makes remote networks available without requiring complex firewall rules or public IP addresses. They also unlock browser-based [SSH](/manage/resources/public/ssh), [RDP](/manage/resources/public/rdp), and [VNC](/manage/resources/public/vnc) resources, [private HTTP](/manage/resources/private/private-http) with edge TLS termination, intelligent [multi-site routing](/manage/resources/private/multi-site-routing) when the same resource is reachable from more than one location, and much more.

 <Card title="Read more about sites" icon="plug" href="/manage/sites/understanding-sites">
  Learn about sites, how they work, and how to install and configure them.
@@ -50,35 +65,115 @@ The Newt connector handles tunnel creation, NAT traversal, and routing. It makes

 ### Resources

-Resources are the applications, hosts, or network ranges you make available to users. They exist on sites and represent what users can access. Users connect to resources, not to sites directly.
+Pangolin is resource-based. A resource is the unit of access: you define it, grant users and roles, and Pangolin routes only authorized traffic. Users connect to resources, not to sites.

-There are two types of resources. [Public resources](/manage/resources/understanding-resources#public-resource-types) work through web browsers and act as reverse proxies—or protocol-specific proxies—for backend services. [Private resources](/manage/resources/understanding-resources#private-resource-types) require a client connection and function like a zero-trust VPN.
+Resources follow different protocols depending on what you are exposing (for example, but not limited to):

-What sets Pangolin apart is the breadth of resource types on one platform:
+- An HTTPS app, available in the browser
+- An IP address, reached through the Pangolin client
+- A network range, reachable through the Pangolin client
+- An [AI Gateway](/manage/ai/overview) resource for LLM access
+- Remote desktop
+- SSH

- **Public HTTP/HTTPS** — authenticated reverse proxies with SSO, access rules, and automatic TLS. No client required.
- **Public SSH, RDP, and VNC** — full terminal, desktop, or display sessions rendered in the browser. No SSH client or remote desktop software needed.
- **Public TCP/UDP** — raw port proxies for protocols that do not need a domain name or authentication layer.
- **Private host and CIDR** — route traffic to specific machines or entire subnets over the tunnel, with per-resource port restrictions.
- **Private HTTP/HTTPS** — reverse proxy with TLS terminated at your network edge over the tunnel. The app is never exposed on the public internet; only connected clients can reach it.
- **Private SSH** — traditional terminal access via `pangolin ssh`, with optional automatic user provisioning from Pangolin identity.
+The access model stays the same while the protocol changes.
+
+[Public resources](/manage/resources/understanding-resources#public-resource-types) are publically available proxies to your Pangolin server. Often, these are exposed as a public FQDN, like a website available in the web-browser or an API.
+
+<Frame caption="Public resources in the dashboard: HTTPS, SSH, RDP, and VNC with health, uptime, and access URLs.">
+  <img src="/images/public-resources.png" alt="Manage Public Resources page in the Pangolin dashboard"/>
+</Frame>
+
+[Private resources](/manage/resources/understanding-resources#private-resource-types) require a [Pangolin client](/manage/clients/install-client) connection and stay off the public internet. They are for VPN-like, fully private access to resources on your remote network.
+
+<Frame caption="Private resources in the dashboard: hosts, HTTP, SSH, and CIDR ranges with destinations and aliases.">
+  <img src="/images/private-resources.png" alt="Manage Private Resources page in the Pangolin dashboard"/>
+</Frame>

 You must define resources and assign access before users can reach them. By default, no resources are available on sites. This ensures that only explicitly defined resources can be accessed.

+#### Resource Launcher
+
+The Resource Launcher is the dashboard your users (non-admins) see. It lists every resource they are allowed to access in one place, grouped by site or label, with search and filters. Users open a web app, copy a hostname, or launch a private resource from that hub.
+
+<Frame caption="The Resource Launcher, grouped by site, showing the resources a user can open.">
+  <img src="/images/resource-launcher.png" alt="Resource Launcher in the Pangolin dashboard"/>
+</Frame>
+
+Selecting a resource always expands a panel with the details that matter for that type: URL or alias, how to connect, and any extra setup. The screenshot below is an [AI Gateway](/manage/ai/overview) example. The same panel is used for every resource.
+
+<Frame caption="Resource Launcher detail panel. This example is a private AI Gateway, with models and coding agent setup.">
+  <img src="/images/resource-launcher-expanded.png" alt="Resource Launcher detail panel showing a private AI Gateway as an example"/>
+</Frame>
+
+<Card title="Resource Launcher" icon="grid-2" href="/manage/resource-launcher">
+  Find, launch, and save views of the resources you can access.
+</Card>
+
 <Card title="Read more about resources" icon="link" href="/manage/resources/understanding-resources">
  Learn about public and private resources and how to create them.
 </Card>

+### Users and Roles
+
+Identity lives in the same control plane as sites and resources. You manage your team in one place: Pangolin users, [identity providers](/manage/identity-providers/add-an-idp), and the [roles](/manage/access-control/create-user#roles) that grant access.
+
+Use Pangolin's built-in users, or bring Google Workspace, Microsoft Entra ID, Okta, or any OIDC provider. Users authenticate once. That identity applies to the dashboard, browser resources, the Pangolin client, the AI Gateway, and everything else.
+
+Roles group people for RBAC. You assign roles on each resource, so access follows the team rather than a separate list per protocol. A user's effective access is the union of what their roles can reach. The same users and roles apply to public resources, private resources, and AI Gateway resources.
+
+<Frame caption="Users in the dashboard, with identity providers and roles managed together.">
+  <img src="/images/users.png" alt="Manage Users page in the Pangolin dashboard"/>
+</Frame>
+
+<Card title="Users and Roles" icon="users" href="/manage/access-control/create-user">
+  Add internal or external users and assign roles for resource access.
+</Card>
+
+<Card title="Add an Identity Provider" icon="key" href="/manage/identity-providers/add-an-idp">
+  Let users sign in with Google, Microsoft Entra ID, Okta, or any OIDC provider.
+</Card>
+
 ### Clients

-Clients are software components installed on user devices or machines. They let users and automated systems connect to your Pangolin network and access private resources through a secure tunnel.
+Clients are software components installed on user devices or machines. They let users and automated systems connect directly to sites to access [private resources](/manage/resources/understanding-resources#private-resource-types) through a secure tunnel. Clients also enforce access control and security at the edge.

-Users authenticate through the client using their accounts. Machines connect with credentials. Once connected, users can reach all resources their account has access to. The client handles routing decisions and establishes encrypted tunnels to the appropriate sites.
+Users authenticate through the client using their [accounts](/manage/access-control/create-user). [Machines](/manage/clients/credentials) connect with credentials. Once connected, users can reach all resources their account has access to. The client handles [routing](/manage/clients/nat-traversal) decisions and establishes encrypted tunnels to the appropriate [sites](/manage/sites/understanding-sites).

-Clients are available for Mac, Windows, and Linux. They work transparently with applications, so no application configuration is required.
+<Frame caption="User devices in the dashboard, with identity provider, connection status, and client version.">
+  <img src="/images/user-devices.png" alt="User Devices page in the Pangolin dashboard"/>
+</Frame>
+
+Clients are available on [all major platforms](/manage/clients/install-client). They work transparently with applications, so no application configuration is required.
+
+<Card title="Download Pangolin clients" icon="download" href="https://pangolin.net/downloads" arrow="true">
+  Get the client for Mac, Windows, Linux, iOS, and Android.
+</Card>

 <Card title="Read more about clients" icon="desktop" href="/manage/clients/understanding-clients">
-  Learn about clients and where to download them for Mac, Windows, and Linux.
+  Learn how user and machine clients connect to private resources.
+</Card>
+
+### AI Gateway
+
+An [AI Gateway](/manage/ai/overview) is a special resource type for LLM access. It is protocol-aware, in the same way an HTTPS resource understands HTTP.
+
+<Frame caption="Creating a public resource with type set to AI Gateway.">
+  <img src="/images/ai/create-ai-gateway-resource.png" alt="Create Public Resource form with Type set to AI Gateway"/>
+</Frame>
+
+Pangolin already inspects HTTPS traffic to apply identity, access rules, [request logs](/manage/analytics/request), and analytics. An AI Gateway resource does the equivalent for model APIs. Because the gateway understands the LLM protocol, it can attribute each call to a user, record [cost and token usage](/manage/ai/usage-analytics), keep [chat session history](/manage/ai/session-logs), and enforce who can use which [models](/manage/ai/providers/model-routing) and [budgets](/manage/ai/budgets).
+
+Access is identity-based. You grant users and roles on the resource the same way you do for HTTPS or SSH. Pangolin then decides which models that identity may call and whether a budget still allows the request.
+
+<Frame caption="AI Gateway session logs, showing provider, model, resource, and the user who made the call.">
+  <img src="/images/ai/expanded-session-logs.png" alt="AI Gateway session logs in the Pangolin dashboard"/>
+</Frame>
+
+A [private AI Gateway](/manage/resources/private/ai-gateway) uses the [Pangolin client](/manage/clients/install-client) the same way every other private resource does. The client running on the end user's device already authenticated that user. Coding agents on that device call the resource over the tunnel, and Pangolin attributes the request to the connected identity. That eliminates provider API keys on the laptop: the upstream key stays on the [provider](/manage/ai/providers/overview).
+
+<Card title="Read more about AI Gateway" icon="sparkles" href="/manage/ai/overview">
+  Set up providers, resources, and identity-based access for coding agents and AI clients.
 </Card>

 ### Remote Nodes
@@ -90,3 +185,7 @@ You can deploy multiple remote nodes for high availability and automatic failove
 <Card title="Read more about remote nodes" icon="circle-nodes" href="/manage/remote-node/understanding-nodes">
  Learn about remote nodes and how they provide high availability and simplified operations.
 </Card>
+
+## System Architecture
+
+For a more technical picture of the software components and how they interact, see [System Architecture](/development/system-architecture).
@@ -0,0 +1,60 @@
+---
+title: "Cloud vs. Self-Hosted"
+description: "Choose managed Pangolin Cloud or run the same software on your own infrastructure"
+---
+
+You can run Pangolin as [Pangolin Cloud](https://app.pangolin.net/auth/signup) or [self-host](/self-host/quick-install) the same open-source software. Sites, resources, and clients work the same way in both. The difference is who operates the server: the control plane, DNS, certificates, and the nodes that terminate tunnels.
+
+## Pangolin Cloud
+
+Cloud is the managed control plane. You create an account, install [sites](/manage/sites/install-site) and [clients](/manage/clients/install-client), and define resources. Pangolin runs the dashboard, database, certificates, and globally distributed nodes.
+
+Use Cloud when you want high availability, automatic updates, and less operational work. You can still keep traffic on infrastructure you control with [remote nodes](/manage/remote-node/understanding-nodes).
+
+## Self-Hosted
+
+Self-hosted Pangolin runs on a server you operate. You supply a public IP, a domain, and the listener ports. See [Quick Install](/self-host/quick-install) and [DNS and Networking](/self-host/dns-and-networking). You are responsible for updates, backups, certificates, and uptime.
+
+Two editions:
+
+- **Community Edition** is the core platform.
+- **[Enterprise Edition](/self-host/enterprise-edition)** uses the `ee` image and a license key. It unlocks extra identity, logging, and management features. Compare tiers on the [Self-Hosted pricing page](https://pangolin.net/pricing#Self-Hosted-identity-and-access-management).
+
+<Check>
+Enterprise Edition is **free** for personal use and organizations with less than $100,000 USD gross annual revenue. You still need a license key. Larger organizations need a paid license.
+</Check>
+
+## Remote Nodes (Hybrid)
+
+[Remote nodes](/manage/remote-node/understanding-nodes) are a middle path but are part of Pangolin Cloud. You run the node (tunnels, TLS, relay) on your server and bandwidth. Cloud still handles the dashboard, DNS, certificates, and failover. If your node goes down, traffic can fail over to other nodes or cloud points of presence.
+
+Public TCP/UDP listeners that bind a port on the Pangolin host are a self-hosted-server feature. On Cloud, deploy a remote node for that. See [TCP / UDP](/manage/resources/public/raw-resources).
+
+## Quick Comparison
+
+| | Pangolin Cloud | Self-hosted |
+|---|---|---|
+| **Control plane** | Managed | You run Pangolin, Traefik, and Gerbil |
+| **Traffic path** | Cloud nodes, or your [remote nodes](/manage/remote-node/understanding-nodes) | Your server |
+| **DNS and certificates** | Managed | You configure DNS and Let's Encrypt |
+| **Updates and backups** | Included | You operate them |
+| **High availability** | Included | You design it ([clustering](/self-host/advanced/clustering) on Enterprise) |
+| **Identity and logs** | Cloud plans | Community core; extra IdPs, streaming, and AI session logs on [Enterprise Edition](/self-host/enterprise-edition) |
+| **Data residency** | Cloud regions, or traffic on your remote nodes | Entirely on your infrastructure |
+| **Best for** | Fast start and less ops | Air-gapped networks, full control, compliance that requires self-hosting |
+
+Cloud and self-hosted plans are listed separately on [pricing](https://pangolin.net/pricing). Click "Self-Hosted" at the top to toggle between deployment options.
+
+## When to Use Each
+
+Use **Pangolin Cloud** if you want to start quickly, get HA and certificate management included, and optionally attach remote nodes so tunnel traffic stays on your network.
+
+Use **self-hosted** if the control plane and data must stay on infrastructure you operate, you need an air-gapped or fully isolated deployment, or you already run Pangolin as Community or Enterprise Edition.
+
+<Card title="Start on Pangolin Cloud" icon="cloud" href="https://app.pangolin.net/auth/signup" arrow="true" cta="Sign up">
+  Managed control plane. Install sites and clients, then define resources.
+</Card>
+
+<Card title="Self-host Pangolin" icon="server" href="/self-host/quick-install">
+  Install Community Edition or Enterprise Edition with the quick installer.
+</Card>
@@ -0,0 +1,76 @@
+---
+title: "Pangolin vs. Bifrost vs. LiteLLM"
+description: "What are the similarities and differences between Pangolin's AI Gateway and traditional LLM gateways like Bifrost and LiteLLM?"
+---
+
+Pangolin's [AI Gateway](/manage/ai/overview) does the work you would expect from a traditional LLM gateway: one URL in front of many providers, model routing, usage tracking, and access control. The difference is how it is built. It is a protocol-aware Pangolin resource, so identity, tunnels, and governance are the same system you already use for HTTPS and SSH.
+
+## Why Use a Gateway
+
+Coding agents and AI clients want a provider URL and a key. If every laptop holds the org's OpenAI, Anthropic, or Gemini key, you cannot tell who spent what, you cannot limit which models a contractor may call, and rotating a leaked key means touching every machine.
+
+An AI gateway sits in front of those upstream APIs. Clients call the gateway. The gateway authenticates the caller, picks a provider and model, records usage, and forwards the request with the org's real key. LiteLLM and Bifrost are dedicated products for that job. Pangolin does it as an identity-aware resource on the same platform as the rest of your application and infrastructure access.
+
+## A Protocol-Aware Resource
+
+An [AI Gateway resource](/manage/ai/overview) is not a separate stack. It is a Pangolin resource type, the same way HTTP/HTTPS is a type for web apps and SSH is a type for terminals.
+
+Pangolin already inspects HTTPS to apply identity, access rules, [request logs](/manage/analytics/request), and analytics. An AI Gateway resource does the equivalent for model APIs. Because it understands the LLM protocol, it can attribute each call to a user, record [cost and token usage](/manage/ai/usage-analytics), keep [chat session history](/manage/ai/session-logs), and enforce who can use which [models](/manage/ai/providers/model-routing) and [budgets](/manage/ai/budgets).
+
+That is the justification in Pangolin terms: an identity-aware gateway, not only a model router.
+
+## What Each Solution Provides
+
+**[LiteLLM](https://docs.litellm.ai)** is a dedicated LLM proxy. It presents a unified API in front of many model providers, with virtual keys, spend tracking, fallbacks, and load balancing. Teams often run it as a self-hosted proxy or use its SDK inside applications.
+
+**[Bifrost](https://www.getmaxim.ai/bifrost)** is a dedicated LLM gateway focused on complex routing rules, failover, and performance. For example, you can use it to route requests to different models based on the user's location or the request's content. You can also run it downstream of Pangolin as a [Custom provider](/manage/ai/providers/custom/bifrost) when Pangolin should authenticate callers and Bifrost should pick models.
+
+**Pangolin** provides the same gateway job as a [protocol-aware resource](/about/how-pangolin-works#ai-gateway). Providers, model lists, [virtual API keys](/manage/ai/virtual-api-keys) on public resources, budgets, and session logs are all there. Identity comes from Pangolin users, roles, and (for private AI gateway resources) the [desktop client](/manage/clients/install-client). Site and client tunnels are how you reach self-hosted models and how you keep provider keys off laptops.
+
+## Identity-Aware Gateway
+
+Access follows the resource. You grant [users and roles](/manage/access-control/create-user) the same way you do for other Pangolin resources. Pangolin then decides which models that identity may call and whether a [budget](/manage/ai/budgets) still allows the request.
+
+On a [public AI Gateway](/manage/resources/public/ai-gateway), coding agents send a [virtual API key](/manage/ai/virtual-api-keys). Pangolin identity keys identify the user; you grant the user or role, not the key.
+
+On a [private AI Gateway](/manage/resources/private/ai-gateway), the [Pangolin client](/manage/clients/install-client) running on the end user's device already authenticated that user. Coding agents on that device call over the tunnel fully privately. Pangolin attributes the request to the connected identity. That eliminates provider API keys on the laptop: the upstream key never leaves the provider.
+
+## Virtual API Keys
+
+On other gateways you mint a key for each person, then keep track of who holds which key and which models that key may call. Pangolin [virtual API keys](/manage/ai/virtual-api-keys) work the other way around.
+
+Every user already has an **identity key**. You do not grant the key access to the gateway. You grant the [user or role](/manage/access-control/create-user) access to the AI Gateway resource and its models. The key only identifies the caller as that user. When you change who is on the resource, the key follows. You do not manage a key inventory as the source of access.
+
+Users retrieve their own key:
+
+- Log in at the public gateway URL in a browser, using Pangolin or their [identity provider](/manage/identity-providers/add-an-idp). After login, Pangolin presents the key.
+- Open the Resource Launcher, pick the resource, and copy the key. The launcher also shows which models they can use and how to configure a coding agent to use the key.
+- Admins can [email keys](/manage/ai/virtual-api-keys#email-keys-to-users) to users.
+
+You can still mint **manual keys**, the same way other gateways issue arbitrary virtual keys. Use those for services, machines, CI, or a person if you want a key that is not tied to resource grants. Creating the key grants access to the public gateways you scope it to. See [Identity Keys vs Manual Keys](/manage/ai/virtual-api-keys#identity-keys-vs-manual-keys).
+
+## Tunneling
+
+Tunneling is a Pangolin strength, on both sides of the network.
+
+### Sites: Self-Hosted Models on Remote Networks
+
+A [site connector](/manage/sites/understanding-sites) sits on the network where [Ollama](/manage/ai/providers/custom/ollama), [vLLM](/manage/ai/providers/custom/vllm), or another model server already runs. [Custom providers](/manage/ai/providers/custom) use **Site Targets** so the gateway reaches that API over the tunnel. The model host does not need a public IP or an inbound port. Pangolin can also call cloud providers from the node, so one resource can mix hosted APIs and self-hosted models.
+
+You can put LiteLLM or Bifrost on that same site network and attach them as a Custom provider. Pangolin authenticates; the downstream gateway routes.
+
+### Clients: Remote Access Without Provider Keys
+
+Users connect with the Pangolin client, then reach a private AI Gateway the same way they reach a private host or SSH resource. That is how someone on a laptop uses a self-hosted model on a remote network, or a cloud provider, without holding the upstream key. The client connection is the credential so you don't need to distribute virtual API keys to users.
+
+## When to Use Each Solution
+
+Use **LiteLLM** if you want a dedicated Python proxy or SDK in front of many providers, and you already have a network path and your own identity layer.
+
+Use **Bifrost** if you want a dedicated high-performance LLM gateway for routing and failover. You can run it on its own, or behind Pangolin as a [Custom provider](/manage/ai/providers/custom/bifrost).
+
+Use **Pangolin** if you want LLM access as an identity-aware resource: the same users and roles as the rest of Pangolin, site tunnels to self-hosted models, and client tunnels that authenticate and govern usage at the edge so provider keys stay off devices.
+
+<Card title="AI Gateway Overview" icon="sparkles" href="/manage/ai/overview">
+  Set up providers, resources, and identity-based access for coding agents and AI clients.
+</Card>
@@ -9,17 +9,18 @@ Pangolin combines the capabilities of both a reverse proxy and a VPN into a sing

 ## What Each Solution Provides

-**Reverse Proxies** expose web applications to the internet. They handle SSL termination, load balancing, and basic authentication. Users access applications through web browsers using domain names.
+**Reverse Proxies** expose web applications to the internet. They handle SSL termination, load balancing, and basic authentication. Users access applications through web browsers using domain names. They are usually protocol-aware of HTTPS only.

-**VPNs** create encrypted tunnels that give users access to entire private networks. Users install client software and connect to a VPN server. Once connected, they can access any resource on the network they have network-level access to.
+**VPNs** create encrypted tunnels that give users access to entire private networks as if they were on the local network. Users install client software and connect to a VPN server. Once connected, they can access any resource on the network they have network-level access to.

-**Pangolin** provides both capabilities—and several things neither traditional tool does on its own. Public resources work like a reverse proxy, allowing browser-based access to specific applications. Private resources work like a zero-trust VPN, giving users access to specific hosts or network ranges when connected with a client.
+**Pangolin** provides both capabilities, and several things neither traditional tool does on its own. [Public resources](/manage/resources/understanding-resources#public-resource-types) are publicly served proxies. That is often a website in a browser, but it can also be an API or an [AI Gateway](/manage/ai/overview). [Private resources](/manage/resources/understanding-resources#private-resource-types) work like a zero-trust VPN, giving users access to specific hosts or network ranges when connected with a client.

 ## What Pangolin Does Differently

 | Capability | Traditional reverse proxy | Traditional VPN | Pangolin |
 |------------|--------------------------|-----------------|----------|
-| Browser access to web apps | Yes | No | Yes — public HTTP/HTTPS |
+| Publicly served proxies | Web apps | No | Yes: HTTP/HTTPS, APIs, [AI Gateway](/manage/ai/overview) |
+| Protocol-aware proxies | HTTPS | No | Yes: HTTPS, SSH, RDP, VNC, AI providers, and more |
 | Browser SSH, RDP, VNC | No | No | Yes — public SSH, RDP, VNC |
 | Client-only private access | No | Yes | Yes — host, CIDR, SSH, private HTTP |
 | Per-resource access control | Limited | Network-wide | Yes — users and roles per resource |
@@ -29,9 +30,11 @@ Pangolin combines the capabilities of both a reverse proxy and a VPN into a sing

 ## Reverse Proxy Capabilities

-Pangolin's public resources function as reverse proxies—and go further than HTTP alone.
+Pangolin's public resources function as reverse proxies. They are publicly served, not limited to web browsers. A traditional reverse proxy is usually protocol-aware of HTTPS only. Pangolin understands many protocols, including HTTPS, SSH, RDP, VNC, and AI provider APIs, so identity, access rules, and logging apply to each the same way.

-**HTTP/HTTPS** resources expose web applications through domain names with automatic SSL certificates. Users access them in a browser with no client installed. Identity-aware access control supports SSO, MFA, and rules based on user identity, roles, geographic location, IP addresses, and URL paths.
+**HTTP/HTTPS** resources expose web applications and APIs through domain names with automatic SSL certificates. A browser is the common client; any HTTP client can call the same FQDN. Identity-aware access control supports SSO, MFA, and rules based on user identity, roles, geographic location, IP addresses, and URL paths.
+
+**AI Gateway** resources are public proxies for LLM APIs. Coding agents call the FQDN instead of the upstream provider. Pangolin authenticates the caller and applies identity, model access, and budgets. See [AI Gateway](/manage/ai/overview).

 **SSH, RDP, and VNC** resources render full sessions in the browser. Users get a terminal, Windows desktop, or VNC display without installing SSH clients or remote desktop software—while still passing through Pangolin authentication first.

@@ -47,7 +50,7 @@ Pangolin's private resources function like a zero-trust VPN—but with tighter s

 **Private HTTP/HTTPS** resources behave like a reverse proxy that only exists on the tunnel. TLS terminates at your [site edge over peer-to-peer transport](/manage/resources/private/private-http)—the application is never reachable from the public internet, only from connected clients with valid access.

-**Private SSH** resources provide terminal access via `pangolin ssh`, with optional automatic user provisioning from Pangolin identity—no manual key distribution required.
+**[Private SSH](/manage/resources/private/ssh)** resources provide terminal access via `pangolin ssh`, with optional automatic user provisioning from Pangolin identity—no manual key distribution required.

 Clients work transparently with applications. No application configuration is required. Users connect once and can access all their authorized resources. The client handles routing and establishes encrypted tunnels automatically.

@@ -55,7 +58,7 @@ Clients work transparently with applications. No application configuration is re

 Many organizations need both reverse proxy and VPN capabilities. You might want to expose a customer portal through a browser while also giving developers SSH access to internal servers and a private HTTPS dashboard that never touches the public internet.

-With Pangolin, you use one platform for all of these. Public resources handle browser-based access—including SSH, RDP, and VNC when you want sessions without a client. Private resources handle tunnel-only access to hosts, subnets, internal HTTPS apps, and CLI SSH. Both use the same authentication system, access control policies, and infrastructure.
+With Pangolin, you use one platform for all of these. Public resources handle publicly served access: websites in a browser, APIs, [AI Gateway](/manage/ai/overview) resources, and SSH, RDP, and VNC sessions. Private resources handle tunnel-only access to hosts, subnets, internal HTTPS apps, and CLI SSH. Both use the same authentication system, access control policies, and infrastructure.

 This unified approach simplifies management. You configure users, roles, and access policies once. Those policies apply to both public and private resources. You do not need to maintain separate systems for reverse proxy and VPN access.

@@ -73,4 +76,4 @@ Use a traditional reverse proxy if you only need to expose web applications over

 Use a traditional VPN if you need broad network access, you can accept the security risks of flat network visibility, and you do not need application-specific access control.

-Use Pangolin if you need both reverse proxy and VPN capabilities, browser-based SSH/RDP/VNC, private HTTPS with edge TLS termination, granular per-resource access control, multi-site routing, high availability, or outbound-only connectivity without open ports on your networks.
+Use Pangolin if you need both reverse proxy and VPN capabilities, publicly served APIs and AI gateways, browser SSH/RDP/VNC, private HTTPS with edge TLS termination, granular per-resource access control, multi-site routing, high availability, or outbound-only connectivity without open ports on your networks.
@@ -3,15 +3,13 @@ title: "System Architecture"
 description: "A technical overview of how Pangolin's control plane, nodes, connectors, and clients fit together"
 ---

-
-
 ## Open Source

 Every layer of Pangolin is open source, from the control plane server through site connectors and end-user clients. Each component has its own repository under [fosrl on GitHub](https://github.com/fosrl); the [component reference](#component-reference) at the bottom of this page lists them.

-The software that powers [Pangolin Cloud](https://app.pangolin.net) is open source as well. The SaaS control plane runs the same codebase as self-hosted Pangolin, and that code lives in the main [fosrl/pangolin](https://github.com/fosrl/pangolin) repository. Nothing described here is proprietary or hidden behind the managed service.
+The software that powers [Pangolin Cloud](https://app.pangolin.net) is open source as well. The SaaS control plane runs the same codebase as self-hosted Pangolin, and that code lives in the main [fosrl/pangolin](https://github.com/fosrl/pangolin) repository.

-Pangolin is split into a **control plane** (configuration, identity, and orchestration) and a **data plane** (encrypted tunnels, ingress, and relay). Sites and clients both initiate **outbound** connections to a Pangolin node, which keeps remote networks behind firewalls reachable without opening inbound ports on those networks.
+Pangolin is split into a **control plane** (configuration, identity, and orchestration) and a **data plane** (encrypted tunnels, ingress, and relay). For [public resources](/manage/resources/understanding-resources#public-resource-types), site connectors initiate **outbound** connections to a Pangolin node so the node can reverse-proxy traffic into the remote network without opening inbound ports there. For [private resources](/manage/resources/understanding-resources#private-resource-types), [clients](/manage/clients/understanding-clients) connect **peer-to-peer** to the site; the node is only in the data path as a relay when a direct path cannot be established. See [Peer-to-Peer and Relay Paths](#peer-to-peer-and-relay-paths).

 For a product-level walkthrough of sites, resources, and clients, see [How Pangolin Works](/about/how-pangolin-works). This page focuses on how those pieces are implemented and how traffic moves through the system.

@@ -64,16 +62,16 @@ The control plane writes certificates, Traefik router definitions, and WireGuard

 ## Site Connectors

-A **site connector** runs on a remote network (server, VM, container, or appliance) and maintains persistent **outbound** connections to a Pangolin node. It is the bridge between your private LAN and the platform.
+A **site connector** runs on a remote network (server, VM, container, or appliance) and is the bridge between your private LAN and the platform. For public resources it maintains persistent **outbound** connections to a Pangolin node so ingress can reverse-proxy into the LAN. For private resources, clients form a **peer-to-peer** path to the connector; the node is only in that data path as a relay when hole punching fails.

-The primary connector implementation is **Newt** (codename). Newt opens:
+The primary connector is a **Pangolin Site**. In engineering contexts it is referred to as Newt. The site opens:

 1. A **WebSocket** to the control plane for configuration, health, and coordination
 2. A **WireGuard** tunnel to the node's tunnel manager (Gerbil) for encrypted data traffic

 Site connectors are deny-by-default proxies. Deploying one does not expose hosts on the network; traffic is forwarded only for [resources](/manage/resources/understanding-resources) you define and grant access to. The connector resolves backend targets on the remote network and delivers packets there.

-Newt sites support the full feature set: public and private resources, protocol-aware proxies, multi-site routing, health checks, and edge TLS for private HTTP. Other connector types ([local](/manage/sites/understanding-sites#local-site) and [basic WireGuard](/manage/sites/understanding-sites#basic-wireguard-site)) exist for specialized self-hosted cases.
+Pangolin Sites support the full feature set: public and private resources, protocol-aware proxies, multi-site routing, health checks, and edge TLS for private HTTP. Other connector types ([local](/manage/sites/understanding-sites#local-site) and [basic WireGuard](/manage/sites/understanding-sites#basic-wireguard-site)) exist for specialized self-hosted cases.

 <Card title="Understanding sites" icon="plug" href="/manage/sites/understanding-sites">
  Site types, deployment models, and connector capabilities.
@@ -28,7 +28,9 @@
                        "group": "About",
                        "pages": [
                            "about/how-pangolin-works",
-                            "about/pangolin-vs-reverse-proxy-vs-vpn"
+                            "about/pangolin-vs-reverse-proxy-vs-vpn",
+                            "about/pangolin-vs-bifrost-vs-litellm",
+                            "about/pangolin-cloud-vs-self-hosted"
                        ]
                    },
                    {
@@ -61,6 +63,7 @@
                                "icon": "link",
                                "pages": [
                                    "manage/resources/understanding-resources",
+                                    "manage/resource-launcher",
                                    {
                                        "group": "Public Resources",
                                        "pages": [
@@ -368,15 +371,15 @@
        ],
        "global": {
            "anchors": [
-                {
-                    "anchor": "Slack",
-                    "href": "https://pangolin.net/slack",
-                    "icon": "slack"
-                },
                {
                    "anchor": "Discord",
                    "href": "https://pangolin.net/discord",
                    "icon": "discord"
+                },
+                {
+                    "anchor": "Slack",
+                    "href": "https://pangolin.net/slack",
+                    "icon": "slack"
                }
            ]
        }
@@ -471,14 +474,6 @@
                        "label": "Terms of Service",
                        "href": "https://pangolin.net/tos"
                    },
-                    {
-                        "label": "Data Processing Addendum",
-                        "href": "https://pangolin.net/dpa"
-                    },
-                    {
-                        "label": "Service Level Agreement",
-                        "href": "https://pangolin.net/sla"
-                    },
                    {
                        "label": "Commercial License",
                        "href": "https://pangolin.net/fcl"
@@ -1,43 +1,82 @@
 ---
 title: "Introduction to Pangolin"
+description: "Connect and protect your users with an open-source networking and security platform"
 ---
-Pangolin is an open-source, identity-based remote access platform built on WireGuard that enables secure, seamless connectivity to private and public resources.
+
+Pangolin is an open-source SASE platform with one mission: connect and protect your users, wherever they are.
+
+It treats networking and security as a single system. Identity, sites, access control, privileged access, and an identity-aware AI gateway share one policy model. The idea is the same as platforms like Cloudflare One, Zscaler, and Prisma Access, but Pangolin is open, self-hostable, and built to stay light enough that administrators actually enjoy running it.

 <Frame caption="Screenshot of resources page from the Pangolin Dashboard.">
  <img src="/images/hero.png" alt="Pangolin Dashboard"/>
 </Frame>

-Pangolin combines reverse proxy and VPN capabilities into one platform. It provides browser-based access to web applications and client-based access to private resources like databases and SSH servers, all with zero-trust security and granular access control.
+## Why Pangolin Exists

-Pangolin connects remote networks using lightweight software connectors called sites. Sites create secure tunnels without requiring public IP addresses or open ports. Admins define specific resources that users can access, not entire networks. This gives users only the access they need while keeping everything else secure.
+Legacy SASE platforms got the idea right: connectivity and security belong together. They delivered it as a heavyweight, closed, cloud-locked stack. Pangolin does that unification in the open, on infrastructure you control, and simple enough to deploy yourself.

-Users access public resources through any web browser with authentication. Users access private resources by connecting with a Pangolin client on their device. Both methods use the same identity-based access control, so you manage users and permissions in one place.
+- **Open source and auditable.** You can see how traffic is handled and how access decisions get made.
+- **Networking and security as one platform.** Connecting users and protecting them happen together, with one identity and policy model.
+- **Lightweight by design.** The control plane runs on a modest server. A user-space connector sits in your private networks.
+- **Zero trust from day one.** Access is granted per resource, with identity providers, roles, and audit logs.
+- **Run it your way.** Self-host or use [Pangolin Cloud](https://app.pangolin.net/auth/signup).

-<Frame caption="Screenshot of sites page from Pangolin Dashboard">
-  <img src="/images/sites.png" alt="Pangolin Dashboard"/>
-</Frame>
+## Core Concepts

-<Frame caption="Screenshot of private network resources page from Pangolin Dashboard">
-  <img src="/images/private-resources.png" alt="Pangolin Dashboard"/>
-</Frame>
+Pangolin is organized around a few pieces you will use everywhere:
+
+1. A **server** is the control plane. It holds identity, policy, and coordination. You can use [Pangolin Cloud](/about/pangolin-cloud-vs-self-hosted) or [self-host](/self-host/quick-install) the same software.
+2. **[Sites](/manage/sites/understanding-sites)** connect the networks where your applications and infrastructure live.
+3. **[Resources](/manage/resources/understanding-resources)** are the specific things users are allowed to reach: web apps, SSH, desktops, private hosts, and AI providers.
+4. **[Clients](/manage/clients/understanding-clients)** give devices a private path to those resources.
+
+<Card title="How Pangolin Works" icon="brain" href="/about/how-pangolin-works">
+  Learn the fundamentals: server, sites, resources, clients, and how they fit together.
+</Card>
+
+## Explore the Platform
+
+<CardGroup cols={2}>
+  <Card title="Sites" icon="plug" href="/manage/sites/understanding-sites">
+    Connect private networks with lightweight connectors so authorized users can reach what lives there.
+  </Card>
+  <Card title="Resources" icon="link" href="/manage/resources/understanding-resources">
+    Define the apps, hosts, SSH sessions, desktops, and AI endpoints users can access.
+  </Card>
+  <Card title="Identity and Access" icon="users" href="/manage/access-control/create-user">
+    Use built-in users or your identity provider. Grant roles per resource and keep an audit trail.
+  </Card>
+  <Card title="AI Gateway" icon="sparkles" href="/manage/ai/overview">
+    Put identity, budgets, and session history in front of cloud and self-hosted model APIs.
+  </Card>
+</CardGroup>

 ## Keep Reading

-<Card title="How Pangolin Works" icon="brain" href="/about/how-pangolin-works">
-  Learn about the fundamentals of Pangolin and how they work together to provide simple and secure remote access.
-</Card>
-
-<Card title="Pangolin vs. Reverse Proxy vs. VPN" icon="book" href="/about/pangolin-vs-reverse-proxy-vs-vpn">
-  What are the similarities and differences between Pangolin and traditional reverse proxies and VPNs?
-</Card>
+<CardGroup cols={2}>
+  <Card title="Cloud vs. Self-Hosted" icon="server" href="/about/pangolin-cloud-vs-self-hosted">
+    Choose a managed control plane or run the same software on your own infrastructure.
+  </Card>
+  <Card title="Pangolin vs. Proxy vs. VPN" icon="book" href="/about/pangolin-vs-reverse-proxy-vs-vpn">
+    How Pangolin relates to traditional reverse proxies and VPNs, and what it does beyond either.
+  </Card>
+  <Card title="Pangolin vs. Bifrost vs. LiteLLM" icon="sparkles" href="/about/pangolin-vs-bifrost-vs-litellm">
+    How Pangolin's identity-aware AI Gateway compares to dedicated LLM gateways.
+  </Card>
+  <Card title="System Architecture" icon="diagram-project" href="/development/system-architecture">
+    A technical picture of the control plane, nodes, connectors, and how traffic moves.
+  </Card>
+</CardGroup>

 ## Deployment Options

+See [Cloud vs. Self-Hosted](/about/pangolin-cloud-vs-self-hosted) for the differences, including [remote nodes](/manage/remote-node/understanding-nodes) as a hybrid.
+
 <Columns cols={2}>
  <Card title="Pangolin Cloud" icon="cloud" href="https://app.pangolin.net/auth/signup">
-    Use Cloud for low-maintenance, highly available remote access. Optionally self-host a node to keep your traffic private.
+    A managed control plane. Install sites and clients, then define resources. Optionally self-host a node to keep traffic on your network.
  </Card>
-  <Card title="Self-host Pangolin" icon="server" href="self-host/quick-install">
-    Self-host a fully isolated Pangolin server. Install the Community Edition or Enterprise Edition easily using the quick installer.
+  <Card title="Self-host Pangolin" icon="server" href="/self-host/quick-install">
+    Run a fully isolated Pangolin server. Install Community Edition or Enterprise Edition with the quick installer.
  </Card>
 </Columns>
@@ -3,7 +3,7 @@ title: "AI Gateway Overview"
 description: "Route coding agents and AI clients through Pangolin with centralized providers and access control"
 ---

-An AI Gateway resource is a normal Pangolin resource that proxies requests to one or more upstream AI providers (OpenAI, Anthropic, Google Gemini, Bedrock, Vertex AI, or a custom endpoint). Point a client at the resource's URL instead of the provider's, and Pangolin handles auth, access control, and logging in front of it.
+An AI Gateway resource is a normal Pangolin resource that proxies requests to one or more upstream AI providers (OpenAI, Anthropic, Google Gemini, Bedrock, Vertex AI, or a custom endpoint). Point a client at the resource's URL instead of the provider's, and Pangolin handles auth, access control, and logging in front of it. See [Pangolin vs. Bifrost vs. LiteLLM](/about/pangolin-vs-bifrost-vs-litellm) if you are comparing Pangolin to a traditional LLM gateway.

 ## How It Fits Together

@@ -77,3 +77,7 @@ Each type has its own configuration guide. Capabilities (which API formats a pro
 | Custom | Whatever you select | [Configure](/manage/ai/providers/custom) |

 Use [Custom](/manage/ai/providers/custom) for any upstream that isn't in the typed list. Assign whichever capabilities it speaks - OpenAI, Anthropic, Gemini, Vertex, Bedrock, or a mix. A Moonshot AI (Kimi) endpoint is one example: select Anthropic Messages and point at its Anthropic-compatible URL.
+
+<Card title="Pangolin vs. Bifrost vs. LiteLLM" icon="book" href="/about/pangolin-vs-bifrost-vs-litellm">
+  How Pangolin's identity-aware AI Gateway compares to traditional LLM gateways.
+</Card>
@@ -21,7 +21,7 @@ See [AI Providers](/manage/ai/providers/overview) if you haven't created a provi

 ## Reach a Self-Hosted API

-Site Targets send the request over a Pangolin tunnel to a host Newt can reach. [Install a site](/manage/sites/install-site) on the same network as the model server so the gateway can route to that API over the tunnel. See [Understanding Sites](/manage/sites/understanding-sites).
+Site Targets send the request over a Pangolin tunnel to a host the site can reach. [Install a site](/manage/sites/install-site) on the same network as the model server so the gateway can route to that API over the tunnel. See [Understanding Sites](/manage/sites/understanding-sites).

 After the site is connected, add the process as a target on the provider's **Network** tab (host, port, HTTP or HTTPS). Worked examples: [Ollama](/manage/ai/providers/custom/ollama), [vLLM](/manage/ai/providers/custom/vllm), and [Bifrost](/manage/ai/providers/custom/bifrost).

@@ -3,7 +3,7 @@ title: "Cloud APIs Through a Site"
 description: "Send OpenAI or Anthropic traffic out through a Pangolin site so the vendor sees a fixed egress IP"
 ---

-Typed [OpenAI](/manage/ai/providers/openai) and [Anthropic](/manage/ai/providers/anthropic) providers send requests from the Pangolin node's own egress. A [Custom](/manage/ai/providers/custom) provider with **Site Targets** sends the same APIs out through a chosen site (Newt), so OpenAI or Anthropic see that site's public IP.
+Typed [OpenAI](/manage/ai/providers/openai) and [Anthropic](/manage/ai/providers/anthropic) providers send requests from the Pangolin node's own egress. A [Custom](/manage/ai/providers/custom) provider with **Site Targets** sends the same APIs out through a chosen site, so OpenAI or Anthropic see that site's public IP.

 Use this when the vendor allowlists IPs, or all inference must leave from one network. The site is only the egress path. Auth still lives on the provider: paste the real vendor key.

@@ -54,7 +54,7 @@ Pangolin supports two blueprint formats:

 ### YAML

-Use YAML when you want a readable file that can be committed to git, applied through Newt, pasted into the UI, or sent through the API.
+Use YAML when you want a readable file that can be committed to git, applied through a site, pasted into the UI, or sent through the API.

 ### Container Labels

@@ -70,8 +70,8 @@ Use container labels when the resource definition should live inside your Compos
  </Frame>
 </Card>

-<Card title="Newt">
-  Run Newt with `--blueprint-file` to keep the file declarative and continuously applied:
+<Card title="Site">
+  Run a site with `--blueprint-file` to keep the file declarative and continuously applied:

  ```bash
  newt --blueprint-file /path/to/blueprint.yaml <other-args>
@@ -140,7 +140,7 @@ Use container labels when the resource definition should live inside your Compos
 </Card>

 <Note>
-`--blueprint-file` in Newt and container labels behave as an ongoing source of truth. Dashboard edits can be overwritten the next time the blueprint is applied. UI, API, and CLI applies are typically one-off operations.
+`--blueprint-file` on a site and container labels behave as an ongoing source of truth. Dashboard edits can be overwritten the next time the blueprint is applied. UI, API, and CLI applies are typically one-off operations.
 </Note>

 ## Quick Start YAML Example
@@ -229,7 +229,7 @@ public-resources:
 ```

 <Note>
-When applying a blueprint via Newt (using `--blueprint-file` or container labels), `site` on each target is optional. If omitted, the target is assigned to the site of the Newt that applied the blueprint.
+When applying a blueprint from a site (using `--blueprint-file` or container labels), `site` on each target is optional. If omitted, the target is assigned to the site that applied the blueprint.
 </Note>

 ### Raw TCP Or UDP Example
@@ -364,7 +364,7 @@ Private resources define what Pangolin clients can reach after they connect to y
 - Use **`mode: inference`** for a private [AI Gateway](/manage/ai/overview) resource reachable only by Pangolin clients, not the public internet

 <Note>
-When applying a blueprint via Newt (using `--blueprint-file` or container labels), `sites` is optional. If omitted, the resource is assigned to the site of the Newt that applied the blueprint.
+When applying a blueprint from a site (using `--blueprint-file` or container labels), `sites` is optional. If omitted, the resource is assigned to the site that applied the blueprint.
 </Note>

 ```yaml
@@ -457,7 +457,7 @@ Container labels are continuously applied. Treat the Compose file as the source

 ### Enable Container Label Discovery

-To use container labels, Newt must be able to read the Docker socket:
+To use container labels, the site must be able to read the Docker socket:

 ```bash
 newt --docker-socket /var/run/docker.sock <other-args>
@@ -524,7 +524,7 @@ This creates a single Pangolin resource with multiple targets:
 </Card>

 <Card title="Site Assignment">
-  If no `site` is specified on a target (public resource) or on a private resource, it is assigned to the site of the Newt that applied the blueprint — whether through container labels or `--blueprint-file`.
+  If no `site` is specified on a target (public resource) or on a private resource, it is assigned to the site that applied the blueprint, whether through container labels or `--blueprint-file`.
 </Card>

 <Card title="Merged Configuration">
@@ -1146,7 +1146,7 @@ public-resources:

        <Expandable title="Target object">
          <ResponseField name="site" type="string">
-            Site that hosts the target. Optional when deploying from a Newt — if omitted, the target is assigned to the site of the Newt that applied the blueprint.
+            Site that hosts the target. Optional when deploying from a site. If omitted, the target is assigned to the site that applied the blueprint.

            YAML: `site: my-site`  
            Container label: `pangolin.public-resources.web-app.targets[0].site=my-site`
@@ -1380,7 +1380,7 @@ private-resources:
      </ResponseField>

      <ResponseField name="sites" type="array of strings">
-        Sites that host the resource. Optional when deploying from a Newt — if omitted, the resource is assigned to the site of the Newt that applied the blueprint.
+        Sites that host the resource. Optional when deploying from a site. If omitted, the resource is assigned to the site that applied the blueprint.

        Container labels for arrays must include an index (`[0]`, `[1]`, ...).

@@ -10,7 +10,7 @@ When a client and site share the same local network, they detect this and connec

 Same-network connections typically offer the lowest latency because traffic never leaves the LAN.

-Newt collects IP addresses from the host's network interfaces and uses them to send UDP test packets to the client. If Newt runs inside a Docker container, it only sees the container's internal network, so run it on the host itself to ensure it can detect the host's real IP addresses. This detection also works across VLANs—if a client and site are on different VLANs but routing between them is configured correctly, the connection should still succeed.
+The site collects IP addresses from the host's network interfaces and uses them to send UDP test packets to the client. If the site runs inside a Docker container, it only sees the container's internal network, so run it on the host itself to ensure it can detect the host's real IP addresses. This detection also works across VLANs. If a client and site are on different VLANs but routing between them is configured correctly, the connection should still succeed.

 ## NAT Hole Punching

@@ -27,7 +27,7 @@ Direct connections typically offer:

 If the site and client are unable to hole punch, they fall back to relaying through your Pangolin server.

-Clients can relay traffic through a Pangolin server—through Gerbil specifically. Gerbil listens on UDP port 21820 for new WireGuard connections and forwards the packets down the Newt site tunnels to the right peers. This means your connections back to your site do not require firewall config and uses the existing NAT hole punching capabilities of Newt.
+Clients can relay traffic through a Pangolin server, through the Gerbil service specifically. Gerbil listens on UDP port 21820 for new WireGuard connections and forwards the packets down the site tunnels to the right peers. This means your connections back to your site do not require firewall config and uses the existing NAT hole punching capabilities of the site.

 Relaying is reliable when direct paths are blocked by NAT or firewall rules, but traffic passes through your Pangolin node instead of traveling directly between the client and site.

@@ -99,7 +99,7 @@ Use either view when troubleshooting hole punching or verifying that configurati

 ## Improve Hole Punching Reliability

-Newt supports NAT traversal to allow clients to connect directly to Newt sites without relaying through the Pangolin server, improving performance and reducing latency.
+Pangolin Sites support NAT traversal so clients can connect directly without relaying through the Pangolin server, improving performance and reducing latency.

 In some environments, depending on the NAT type and firewall, you may need to tweak settings to get optimal connectivity in the firewall itself. See [Firewall Integrations](/manage/clients/firewalls) for Pangolin-specific guidance for common platforms.

@@ -121,7 +121,7 @@ Returns values you pass into the create-site endpoint.

 ## Create public HTTP resource

-You need a **domain ID** before creating a resource. List your org's domains, then create the resource with the chosen domain. For all Resource endpoints, see [Resource API (Swagger)](https://api.pangolin.net/v1/docs/#/Resource).
+You need a **domain ID** before creating a resource. List your org's domains, then create the resource with the chosen domain. For all public resource endpoints, see [Public Resource API (Swagger)](https://api.pangolin.net/v1/docs/#/Public%20Resource).

 <Steps>
 <Step title="List domains">
@@ -183,7 +183,7 @@ Returns all domains for the organization. Use `domainId` from a domain when crea

 ### Create public HTTP resource

-**PUT** `/org/{orgId}/resource`
+**PUT** `/org/{orgId}/public-resource`

 **Path**
 - `orgId` (string) — organization ID
@@ -242,9 +242,9 @@ The `subdomain` value is combined with the base domain from `domainId` to form t

 ### Add targets to the resource

-**PUT** `/resource/{resourceId}/target`
+**PUT** `/public-resource/{resourceId}/target`

-Add a target (backend) to a resource. Use the numeric `resourceId` from the create-resource response. The target is the site and address (ip + port) that will receive traffic for the resource. For all Target endpoints, see [Target API (Swagger)](https://api.pangolin.net/v1/docs/#/Target).
+Add a target (backend) to a resource. Use the numeric `resourceId` from the create-resource response. The target is the site and address (ip + port) that will receive traffic for the resource. For all target endpoints, see [Resource Target API (Swagger)](https://api.pangolin.net/v1/docs/#/Resource%20Target).

 **Path**
 - `resourceId` (number) — From create-resource response (e.g. `9943`)
@@ -287,11 +287,11 @@ Add a target (backend) to a resource. Use the numeric `resourceId` from the crea

 ## Create private resource

-In the API Private Resources are called **site resources**. You need an existing site. For more endpoints, see [API docs (Swagger)](https://api.pangolin.net/v1/docs/#/Resource).
+You need an existing site. For more endpoints, see [Private Resource API (Swagger)](https://api.pangolin.net/v1/docs/#/Private%20Resource).

-### Create site resource
+### Create private resource

-**PUT** `/org/{orgId}/site-resource`
+**PUT** `/org/{orgId}/private-resource`

 **Path**
 - `orgId` (string) — organization ID
@@ -364,7 +364,7 @@ If you omit `roleIds`/`userIds`, the org admin role is granted access by default

 ## Assign users and roles to a resource (public or private)

-You can grant access to a **public resource** or a **private (site) resource** by adding roles or users. First list roles and users in the org to get IDs, then call the add endpoints. The Admin role cannot be assigned via these endpoints.
+You can grant access to a **public resource** or a **private resource** by adding roles or users. First list roles and users in the org to get IDs, then call the add endpoints. The Admin role cannot be assigned via these endpoints.

 ### Get role and user IDs

@@ -372,18 +372,18 @@ You can grant access to a **public resource** or a **private (site) resource** b

 **GET** `/org/{orgId}/users` — Returns users in the org. Use `id` (string) as `userId` when adding a user to a resource. Query: `limit`, `offset` (optional).

-### Public resource (HTTP/resources)
+### Public resource

-**POST** `/resource/{resourceId}/roles/add` — **Path:** `resourceId` (number, from create-resource). **Body:** `{ "roleId": number }`. Admin role not allowed.
+**POST** `/public-resource/{resourceId}/roles/add` — **Path:** `resourceId` (number, from create public-resource). **Body:** `{ "roleId": number }`. Admin role not allowed.

-**POST** `/resource/{resourceId}/users/add` — **Path:** `resourceId` (number). **Body:** `{ "userId": string }`.
+**POST** `/public-resource/{resourceId}/users/add` — **Path:** `resourceId` (number). **Body:** `{ "userId": string }`.

 Both return `{ "data": {}, "success": true, "error": false, "message": "...", "status": 201 }`.

-### Private resource (site resource)
+### Private resource

-**POST** `/site-resource/{siteResourceId}/roles/add` — **Path:** `siteResourceId` (number, from create site-resource). **Body:** `{ "roleId": number }`. Admin role not allowed.
+**POST** `/private-resource/{siteResourceId}/roles/add` — **Path:** `siteResourceId` (number, from create private-resource). **Body:** `{ "roleId": number }`. Admin role not allowed.

-**POST** `/site-resource/{siteResourceId}/users/add` — **Path:** `siteResourceId` (number). **Body:** `{ "userId": string }`.
+**POST** `/private-resource/{siteResourceId}/users/add` — **Path:** `siteResourceId` (number). **Body:** `{ "userId": string }`.

-Same response shape as above. Role must belong to the same org as the site resource. For more endpoints (list/remove), see [Resource API](https://api.pangolin.net/v1/docs/#/Resource).
+Same response shape as above. Role must belong to the same org as the private resource. For more endpoints (list/remove), see [Public Resource API](https://api.pangolin.net/v1/docs/#/Public%20Resource) and [Private Resource API](https://api.pangolin.net/v1/docs/#/Private%20Resource).
@@ -6,10 +6,16 @@ description: "Turn a remote node into a network concentrator that routes traffic
 	Site to cloud is an advanced [remote node](/manage/remote-node/understanding-nodes) configuration available in [Pangolin Cloud](https://app.pangolin.net/auth/signup).
 </Note>

-A standard remote node terminates WireGuard tunnels and proxies HTTP(S) traffic to your resources. A **backhaul** node goes a step further: it acts as an IP router between an entire network, such as a cloud VPC, and your Pangolin sites. Instead of just forwarding individual resource connections, the node forwards whole subnets, letting hosts on either side reach each other without installing Newt on every machine.
+A standard remote node terminates WireGuard tunnels and proxies HTTP(S) traffic to your resources. A **backhaul** node goes a step further: it acts as an IP router between an entire network, such as a cloud VPC, and your Pangolin sites. Instead of just forwarding individual resource connections, the node forwards whole subnets, letting hosts on either side reach each other without needing to install site and client on every machine.

 This is useful when you want to bridge a cloud network (for example, an AWS VPC) with your on-prem or office network through Pangolin, using a node running in that VPC as the concentrator.

+Another common use case is connecting edge devices to a cloud network. Edge devices can send traffic to a service in the cloud, and the cloud can send traffic down to a specific edge device. In both cases, the persistent backhaul tunnel carries the traffic.
+
+<Frame>
+	<img src="/images/basic-backhaul-diagram.png" alt="Diagram of a backhaul remote node in a cloud network with bidirectional tunnels to sites on remote private networks" />
+</Frame>
+
 <Tip>
 	Site to cloud builds on top of a normal remote node install. Read [Remote Nodes](/manage/remote-node/understanding-nodes) and [Quick Install Guide](/manage/remote-node/quick-install-remote) first if you haven't deployed a node yet.
 </Tip>
@@ -19,7 +25,7 @@ This is useful when you want to bridge a cloud network (for example, an AWS VPC)
 - **The node routes, it doesn't just proxy.** Gerbil creates the WireGuard interface directly on the host and Docker forwards packets between it and the host's network, rather than isolating traffic inside a container network namespace.
 - **The cloud network learns to route to the node.** You add a route in your VPC (or other network) so that traffic destined for the Pangolin overlay is sent to the node.
 - **The node learns to route to the cloud network.** You register the VPC's CIDR on the node so it's pushed down to your sites as a route.
- **Sites route natively.** Sites connect with Newt's native routing mode so the tunnel subnet is a real route on the site's host, not just an application-layer proxy.
+- **Sites route natively.** Sites connect with native routing mode so the tunnel subnet is a real route on the site's host, not just an application-layer proxy.

 ## Prerequisites

@@ -54,7 +60,7 @@ The standard node install runs Gerbil and Traefik on a bridge network, with Trae
 name: pangolin
 services:
  pangolin:
-    image: docker.io/fosrl/pangolin-node:latest
+    image: docker.io/fosrl/pangolin-node:latest # We recommend locking to a specific version for stability.
    container_name: pangolin
    restart: unless-stopped
    network_mode: host
@@ -124,8 +130,8 @@ server:
    internal_port: 3001
    internal_hostname: localhost
 managed:
-    id: "he4g78wevj25msf"
-    secret: "n7sd18twfko0q0vrb7wyclqzbvvnx1fqt7ezv8xewhdb9s7d"
+    id: "he4g78wevj25msf" # REPLACE WITH YOUR NODE'S ID
+    secret: "n7sd18twfko0q0vrb7wyclqzbvvnx1fqt7ezv8xewhdb9s7d" # REPLACE WITH YOUR NODE'S SECRET
 ```

 See the [configuration file reference](/manage/remote-node/config-file) for every available option.
@@ -148,7 +154,7 @@ experimental:
  plugins:
    badger:
      moduleName: "github.com/fosrl/badger"
-      version: "v1.3.1"
+      version: "v1.7.0" # Check GitHub Releases for latest version tag

 log:
  level: "INFO"
@@ -255,13 +261,7 @@ If you are using Newt on Windows `wintun.dll` is required to run in native mode.

 ## Resolving a Site's Address Directly

-If something outside of Pangolin's normal resource routing needs to reach a site directly, for example a static route configured elsewhere in your network, you can resolve `<newtId>.site.pangolin.net` to get the site's current routable address.
-
-This is useful with backhaul because a site's traffic can move between exit nodes if one becomes unavailable. The DNS record always follows the site to whichever node it's currently connected through.
-
-<Note>
-	Expect a short gap in resolution when a site moves between nodes while the DNS record updates.
-</Note>
+If something outside of Pangolin's normal resource routing needs to reach a site directly, for example a static route configured elsewhere in your network or a cloud service sending traffic to a specific edge device, you can resolve `<siteId>.site.pangolin.net` (the site ID is the one used in the `--id` argument when running the site) to get the site's current routable address.

 ## High Availability

@@ -0,0 +1,55 @@
+---
+title: "Resource Launcher"
+description: "Find and open the resources you can access from one organization home page"
+---
+
+The Resource Launcher is the organization home page. It lists every [public](/manage/resources/understanding-resources#public-resource-types) and [private](/manage/resources/understanding-resources#private-resource-types) resource the signed-in user can access through an explicit grant on their user or [role](/manage/access-control/create-user#roles). Non-administrators land here when they sign in. Administrators can use it the same way, then jump into settings when they need to change a resource.
+
+<Frame caption="The Resource Launcher, grouped by site, showing the resources a user can open.">
+  <img src="/images/resource-launcher.png" alt="Resource Launcher in the Pangolin dashboard"/>
+</Frame>
+
+## Find Resources
+
+Switch between **Grid** and **List** layouts. Search updates as you type across names, domains, sites, labels, destinations, aliases, and related fields. Filter by one or more [sites](/manage/sites/understanding-sites) and [labels](/manage/labels). Sort by name, and group by **Site**, **Label**, or **None** for a flat list.
+
+Site groups show an online or offline indicator. You can expand or collapse groups. The launcher remembers that state for the current organization and view.
+
+In very large organizations, the launcher may ask you to search or filter before browsing, and it may simplify grouping until the list is smaller.
+
+## Open a Resource
+
+Selecting a resource always expands a details panel. The panel shows what matters for that type: access URL or alias, health and auth for public resources, destination and certificate status for private resources, and port restrictions when they apply.
+
+<Frame caption="Resource Launcher detail panel. This example is a private AI Gateway, with models and coding agent setup.">
+  <img src="/images/resource-launcher-expanded.png" alt="Resource Launcher detail panel showing a private AI Gateway as an example"/>
+</Frame>
+
+From a card, list row, or the panel you can open HTTP-style resources in a new tab (HTTP/HTTPS, SSH, RDP, VNC, AI Gateway) or copy the access string. Private resources remind you to connect with a [Pangolin client](/manage/clients/install-client).
+
+For [AI Gateway](/manage/ai/overview) resources, the panel also lists available models, [virtual API keys](/manage/ai/virtual-api-keys), and copy-paste setup for coding agents. Public gateways use your API key. Private gateways use the connected client as the credential.
+
+The launcher URL stores the current search, filters, grouping, layout, and sort, so you can bookmark or share a view. Opening a resource from admin settings can deep-link into the launcher with that resource's panel already open.
+
+## Saved Views
+
+A saved view captures search, filters, grouping, layout, and sort. Start from **Default**, then save the current setup as a personal view. Switch views with the tabs at the top. The last view you used in that organization is restored when you come back.
+
+- **Save for Me** stores your personal default. It overrides any organization-wide default for you only.
+- **Save as New View** creates a named personal view.
+- **Save to Current View** updates a personal view you own.
+- **Reset View** discards unsaved changes.
+
+Organization-wide views are read-only unless you are an administrator.
+
+## For Administrators
+
+Use **View as Admin** in the header to open organization settings, or from a resource panel to open that resource's settings. From a resource settings page you can jump back to the launcher with that resource already open.
+
+Administrators can share views with the organization:
+
+- **Save for Everyone** on the default view sets the organization-wide default for members who have not saved a personal default.
+- **Save for Everyone** on a named view shares it with every member.
+- **Make Personal** turns an organization-wide view back into a personal view.
+
+Set a useful organization-wide default (for example grouped by site, list layout) so people do not have to configure the launcher themselves. Users only see resources granted to their user or a role they belong to. Refresh reloads the latest resources so recent access or config changes show up.
@@ -9,7 +9,7 @@ This page covers how the **resource** works: reachability, access, and what you

 ## How It Works

-1. You create a private resource with type **AI Gateway** on a Newt site and attach one or more org-level [providers](/manage/ai/providers/overview).
+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).
 2. You grant [users, roles, or machines](/manage/resources/private/authentication) access, the same as any other private resource.
 3. The user connects with the Pangolin client. The machine running the AI client must be on that tunnel.
 4. The agent calls the resource URL. Pangolin attributes the call to the connected user and proxies to the selected provider.
@@ -20,7 +20,7 @@ Clients still need a value in the API key field. Use the literal string `none`.

 Private AI Gateway resources attach providers on the resource's **AI Gateway** tab. They do not use a host or CIDR [destination](/manage/resources/private/destinations) as the model backend. Cloud APIs are called from Pangolin. [Custom](/manage/ai/providers/custom) providers can use **Site Targets** when the model server is on a site network.

-Private resources, including this type, can only be created on [Newt sites](/manage/sites/understanding-sites#newt-site-recommended).
+Private resources, including this type, can only be created on [Pangolin Sites](/manage/sites/understanding-sites#pangolin-site-recommended).

 ## Authentication and Access Rules

@@ -24,7 +24,7 @@ TCP and UDP resources use **[targets](/manage/resources/public/targets)** like H
 This feature is only available in self-hosted Pangolin instances. If you're using Pangolin Cloud, you will need to deploy a remote node.
 </Note>

-Pangolin supports raw TCP and UDP traffic because Newt can pass anything through the tunnel.
+Pangolin supports raw TCP and UDP traffic because a site can pass anything through the tunnel.

 In Community Edition or Enterprise Edition, ensure you have the flag enabled in the config file:

@@ -12,7 +12,7 @@ Targets function as destination endpoints for your resources:

 1. **Resource Creation**: When you create a resource, you configure one or more targets
 2. **Traffic Routing**: Incoming traffic is routed to the appropriate target based on your configuration
-3. **Network Access**: Newt proxy routes traffic to the local network through the tunnel
+3. **Network Access**: The site routes traffic to the local network through the tunnel
 4. **Direct Connection**: No additional routing is necessary on the remote network

 ## Additional Proxy Settings
@@ -5,7 +5,7 @@ description: "Resources are any network address you want to make available to us



-Resources represent the applications, hosts, or ranges you make available for remote access to users. Resources exist on the remote networks of your sites. Users only ever think about connecting to resources and not specific sites.
+Resources represent the applications, hosts, or ranges you make available for remote access to users. Resources exist on the remote networks of your sites. Users only ever think about connecting to resources and not specific sites. They find and open what they can access from the [Resource Launcher](/manage/resource-launcher).

 By default, no resources are made available on sites. Admins must define resources with backend targets, and assign specific access policies before any users can gain access.

@@ -35,7 +35,7 @@ HTTP/HTTPS, SSH, RDP, and VNC are all **browser-based**. You assign a fully qual

 [AI Gateway](/manage/resources/public/ai-gateway) also gets a public FQDN, but coding agents call it as an API. Visiting the URL in a browser is how users retrieve a virtual API key, not how they run the workload.

-SSH, RDP, and VNC require a **Newt site**. HTTP/HTTPS, AI Gateway, and TCP/UDP resources can also run on local and basic WireGuard sites.
+SSH, RDP, and VNC require a **Pangolin Site**. HTTP/HTTPS, AI Gateway, and TCP/UDP resources can also run on local and basic WireGuard sites.

 TCP and UDP are the exception. They do not receive a FQDN. Instead, they bind to a port on the Pangolin server host and act as simple protocol-agnostic pipes to the downstream resource. Because they are not protocol-aware, they do not enforce Pangolin authentication or access rules.

@@ -72,7 +72,7 @@ TCP and UDP are the exception. They do not receive a FQDN. Instead, they bind to
 #### Site Compatibility

 <CardGroup cols={3}>
-<Card title="Newt Site" icon="plug" href="/manage/sites/understanding-sites#newt-site-recommended">
+<Card title="Pangolin Site" icon="plug" href="/manage/sites/understanding-sites#pangolin-site-recommended">
  All public resource types supported.

  Required for SSH, RDP, and VNC.
@@ -117,7 +117,7 @@ Private resources require users to connect with the Pangolin client before any t
 </Card>
 </CardGroup>

-Private resources can only be created on Newt sites.
+Private resources can only be created on Pangolin Sites.

 **Private resources function like a zero-trust virtual private network (VPN).** Explicit access to resources must be granted for users and roles to be able to access them. For raw TCP/UDP traffic that does not need a public proxy, prefer a private host or CIDR resource over public TCP/UDP resources.

@@ -126,10 +126,10 @@ Private resources support [aliases](/manage/resources/private/alias) for human-r
 #### Site Compatibility

 <CardGroup cols={3}>
-<Card title="Newt Site" icon="plug" href="/manage/sites/understanding-sites#newt-site-recommended">
+<Card title="Pangolin Site" icon="plug" href="/manage/sites/understanding-sites#pangolin-site-recommended">
  Supported.

-  Private resources require a Newt site.
+  Private resources require a Pangolin Site.
 </Card>

 <Card title="Local Site" icon="server" href="/manage/sites/understanding-sites#local-site">
@@ -10,7 +10,7 @@ Every site is provisioned with a unique identifier (ID), secret, and endpoint. T

 Example: `ln8yqs6w85la5zg`

-The ID represents the site connection type in the system. Every Newt site has an ID. 
+The ID represents the site connection type in the system. Every Pangolin Site has an ID. 

 This value is not a secret and it is okay if made publically available.

@@ -34,7 +34,7 @@ The endpoint is how the site knows which server to connect to. This is the fully

 ## Provisioning keys at scale

-If you deploy many sites (for example IoT devices, golden images, or scripted installs), managing a unique ID and secret per host before first boot can be awkward. **[Site provisioning keys](/manage/sites/site-provisioning)** let each Newt instance exchange a single long-lived token for its own ID and secret on first connect, so you do not have to pre-create and distribute credentials for every machine individually.
+If you deploy many sites (for example IoT devices, golden images, or scripted installs), managing a unique ID and secret per host before first boot can be awkward. **[Site provisioning keys](/manage/sites/site-provisioning)** let each site exchange a single long-lived token for its own ID and secret on first connect, so you do not have to pre-create and distribute credentials for every machine individually.

 ## Rotating and Regenerating Credentials

@@ -13,12 +13,12 @@ As described in [Site credentials](/manage/sites/credentials), each Pangolin sit

 The same friction shows up in other scenarios:

- **Golden images and OS images**: You want one trusted image (or cloud-init payload) shared across a class of machines, not a unique secret baked into every build artifact. A single provisioning key in the image, or injected at first boot, lets each instance obtain its own credentials the first time Newt starts.
+- **Golden images and OS images**: You want one trusted image (or cloud-init payload) shared across a class of machines, not a unique secret baked into every build artifact. A single provisioning key in the image, or injected at first boot, lets each instance obtain its own credentials the first time the site starts.
 - **Scripted and CI-driven installs**: Ansible, Terraform, cloud-init, or installer scripts can drop the same provisioning key everywhere (or fetch it from a vault once) instead of coordinating “create site N, copy credentials to host N” for every node.
 - **Developer and lab environments**: Spin up VMs or containers repeatedly without clicking through the dashboard for each site; tear them down and provision again with bounded keys (usage limits and expiry; see below).
 - **MSP and multi-customer rollouts**: Standardize your onboarding bundle (endpoint + provisioning key + blueprint) while still giving each customer site isolated credentials after exchange.

-With provisioning keys, you create one long-lived token in Pangolin, embed it in your image or distribute it with a single script, and each Newt instance exchanges that token for its own [site ID and secret](/manage/sites/credentials) on first connect.
+With provisioning keys, you create one long-lived token in Pangolin, embed it in your image or distribute it with a single script, and each site exchanges that token for its own [site ID and secret](/manage/sites/credentials) on first connect.

 ## How provisioning works

@@ -2,7 +2,9 @@
 title: "Understanding Sites"
 description: "Create a site to connect to a remote network and expose resources"
 ---
-A site is a connection to a network where your resources live. Pangolin uses sites to make public and private resources available to users. Every resource belongs to one or more sites. Newt is Pangolin's connector that establishes this connection and routes traffic to targets on remote networks.
+A site is a connection to a network where your resources live. Pangolin uses sites to make public and private resources available to users. Every resource belongs to one or more sites.
+
+A Pangolin Site is the software connector that establishes this connection and routes traffic to targets on remote networks. In engineering contexts, and in some install commands, it is sometimes referred to as Newt.

 ## The Basics

@@ -17,11 +19,11 @@ Pangolin supports three different types of sites, each designed for different us

 ### Newt Site (Recommended)

-This site type exposes resources on a remote network through a managed tunnel and websocket connection. It requires the Newt connector on the remote network. This is the easiest setup and does not require NAT configuration.
+This site type exposes resources on a remote network through a managed tunnel and websocket connection. It requires the Pangolin Site connector on the remote network. This is the easiest setup and does not require NAT configuration.

-Use Newt sites in most deployments. Newt is the primary connector type and supports the broadest feature set.
+Use Pangolin Sites in most deployments. This is the primary site type and supports the broadest feature set.

-Newt sites support:
+Pangolin Sites support:
 - Public proxied resources
 - Protocol awareness (HTTP/HTTPS, SSH, RDP, VNC)
 - Private resources (ZTNA)
@@ -44,7 +46,7 @@ Local sites do not support:

 ### Basic WireGuard Site

-This option is self-hosted only. It uses a raw WireGuard connection without Newt, so there is no websocket control channel and setup is more manual. NAT is required to reach targets on other hosts in the remote network. Without NAT, you can expose only resources on the WireGuard peer host itself.
+This option is self-hosted only. It uses a raw WireGuard connection without a Pangolin Site connector, so there is no websocket control channel and setup is more manual. NAT is required to reach targets on other hosts in the remote network. Without NAT, you can expose only resources on the WireGuard peer host itself.

 In general, use Basic WireGuard sites only for specific advanced use cases.

@@ -1,9 +1,36 @@
 ---
 title: "How to Update"
-description: "Keep your Pangolin deployment up to date with the latest features and security patches"
+description: "Keep your self-hosted Pangolin server up to date with the latest features and security patches"
 ---

-Updating Pangolin is straightforward since it's a collection of Docker images. Simply pull the latest images and restart the stack. Migration scripts run automatically to update your database and configuration files when needed.
+Updating Pangolin is straightforward since it's a collection of Docker images. Simply pull the latest images and restart the stack.
+
+This page covers updating your self-hosted Pangolin server. To update sites and clients, see the respective guides:
+
+<CardGroup cols={2}>
+<Card title="Update Sites" icon="plug" href="/manage/sites/update-site">
+  Update sites to the latest version.
+</Card>
+<Card title="Update Clients" icon="desktop" href="/manage/clients/update-client">
+  Update your installed client to the latest version.
+</Card>
+</CardGroup>
+
+## Migration Scripts
+
+When Pangolin starts and detects a version update, it runs migration scripts automatically to update your database and configuration files. Pangolin stores the last successfully run version in the database, so it knows which scripts still need to run. Scripts run in order, starting from the oldest unrun script through the latest.
+
+These are commonly SQL schema updates, and sometimes data migrations.
+
+If a release includes a Badger update, Pangolin also tries to update the Traefik config when it still matches the default Pangolin installer Traefik config. If Pangolin cannot apply that change, it fails silently so you can update Badger yourself.
+
+A failed database migration blocks startup and prevents the server from running.
+
+If you are using SQLite, Pangolin automatically creates a copy of the database file before a migration runs so you can roll back if needed. You can disable this by setting the `DISABLE_BACKUP_ON_MIGRATION` environment variable to `true`.
+
+<Warning>
+Because migrations can change the database schema, downgrading is sometimes impossible and is not recommended. The database may become incompatible with older versions. Always back up your database before updating.
+</Warning>

 ## Before You Update

@@ -31,7 +58,7 @@ sudo docker compose down
  
  - **Pangolin**: [GitHub Releases](https://github.com/fosrl/pangolin/releases)
  - **Gerbil**: [GitHub Releases](https://github.com/fosrl/gerbil/releases)
-  - **Traefik**: [Docker Hub](https://hub.docker.com/_/traefik)
+  - **Traefik**: [Docker Hub](https://github.com/traefik/traefik/releases)
  - **Badger**: [GitHub Releases](https://github.com/fosrl/badger/releases)
  
  <Info>
@@ -45,15 +72,15 @@ sudo docker compose down
 ```yaml title="docker-compose.yml"
 services:
  pangolin:
-      image: fosrl/pangolin:1.16.0  # Update to latest version
+      image: fosrl/pangolin:1.22.0 # Check GitHub Releases for latest version tag
      # ... rest of config

  gerbil:
-      image: fosrl/gerbil:1.5.0   # Update to latest version
+      image: fosrl/gerbil:1.5.1 # Check GitHub Releases for latest version tag
      # ... rest of config
  
    traefik:
-      image: traefik:v3.7         # Update if needed
+      image: traefik:v3.7.12 # Check GitHub Releases for latest version tag
      # ... rest of config
  ```

@@ -64,7 +91,7 @@ services:
    plugins:
      badger:
        moduleName: github.com/fosrl/badger
-        version: v1.4.1 # Update to latest version
+        version: v1.7.0 # Check GitHub Releases for latest version tag
  ```
  
  <Warning>
@@ -88,7 +88,7 @@ Once installation completes successfully, you'll see:
 Installation complete!

 To complete the initial setup, please visit:
-https://pangolin.example.com/auth/initial-setup
+https://<your-dashboard-domain>/auth/initial-setup
 ```

 <Steps>