reduce usage of newt

manage/resources/private/ai-gateway.mdx

@@ -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
 

manage/resources/understanding-resources.mdx

@@ -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">

manage/sites/credentials.mdx

@@ -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
 

manage/sites/site-provisioning.mdx

@@ -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
 

manage/sites/understanding-sites.mdx

@@ -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.