reduce usage of newt

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.