pangolin_mirror/docs-v2
1
0
Fork 0
mirror of https://github.com/fosrl/docs-v2.git synced 2026-08-31 19:21:31 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #107 from LaurenceJJones/docs/clarify-newt-provisioning-key-lifecycle

Browse Source 
enhance(newt): Information about removing key
This commit is contained in:
Owen Schwartz
2026-04-27 09:48:08 -07:00
committed by GitHub
parent e1587bff94 4ea48b2d43
commit e1c0d24e6d
2 changed files with 2 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
manage/sites/configure-site.mdx
View File

@@ -46,7 +46,7 @@ import PangolinCloudTocCta from "/snippets/pangolin-cloud-toc-cta.mdx";
</ResponseField>
<ResponseField name="provisioning-key" type="string">
Provisioning key from Pangolin (alternative to a `provisioningKey` field inside the config file). Newt exchanges it once for site credentials, then persists `id` and `secret` to the config file and ignores the key on later runs. See [Site provisioning keys](/manage/sites/site-provisioning).
Provisioning key from Pangolin (alternative to a `provisioningKey` field inside the config file). Newt exchanges it once for site credentials, then persists `id` and `secret` to the config file and ignores the key on later runs. This flag is not written into the config file. See [Site provisioning keys](/manage/sites/site-provisioning).
**Example**: `spk_...`
</ResponseField>

3
manage/sites/site-provisioning.mdx
View File

@@ -47,7 +47,7 @@ Pass the key with **`--provisioning-key`** instead of storing it in the file. Yo
newt --config-file /var/newt.json --endpoint https://app.pangolin.net --provisioning-key 'spk_...'
```
**After the site is provisioned**, Newt writes the new `id` and `secret` into that config file. On later runs, Newt uses those credentials and ignores the provisioning key (CLI flag or file field), because valid ID and secret are already present. If you used `provisioningKey` in JSON, that entry is removed when the file is updated, so the long-lived token is not left on disk.
**After the site is provisioned**, Newt writes the new `id` and `secret` into that config file. On later runs, Newt uses those credentials and ignores the provisioning key (CLI flag or file field), because valid ID and secret are already present. If you used `provisioningKey` in JSON, that entry is removed when the file is updated, so the long-lived token is not left on disk. If you pass `--provisioning-key` instead, Newt does not write that key into the config file, but anything that launched Newt with the flag may still contain it.
From there Newt authenticates over the websocket, optionally applies a blueprint if you passed one, then brings the tunnel online. The high-level sequence is summarized below.
@@ -144,4 +144,3 @@ Optionally, sites provisioned with a key can be placed into a pending state. The
<Frame>
<img src="/images/pending-sites.png" alt="Pending sites listed for admin review" centered />
</Frame>