pangolin_mirror/docs-v2
1
0
Fork 0
mirror of https://github.com/fosrl/docs-v2.git synced 2026-07-17 03:19:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

enhance(newt): reduce fluff

Browse Source
This commit is contained in:
Laurence
2026-04-27 16:00:15 +01:00
parent 06738bc224
commit 4ea48b2d43
2 changed files with 3 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -46,13 +46,13 @@ 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. This flag is not written into the config file. If you want the key to exist only in the config file and then be removed by Newt after provisioning, use `provisioningKey` in the config file instead. 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>
<ResponseField name="config-file" type="string">
Path to a JSON file where Newt reads and persists settings (`endpoint`, `id`, `secret`, optional `provisioningKey`, and other options). When you use [site provisioning](/manage/sites/site-provisioning), Newt writes `id` and `secret` into this file after a successful exchange. If the file contained `provisioningKey`, Newt removes that field when it updates the file.
Path to a JSON file where Newt reads and persists settings (`endpoint`, `id`, `secret`, optional `provisioningKey`, and other options). When you use [site provisioning](/manage/sites/site-provisioning), Newt writes `id` and `secret` into this file after a successful exchange.
**Example**: `/var/newt.json`
</ResponseField>

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

@@ -47,23 +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.
<Note>
You do not need to edit the config file by hand after successful provisioning.
- `provisioningKey` in the config file: Newt removes it after provisioning.
- `--provisioning-key`: Newt does not store it in the config file, but your bootstrap method may still leave it elsewhere on the machine.
- If you want Newt to remove the key from the config file after provisioning, put `provisioningKey` in the config file before first run.
</Note>
### Do I need to remove the provisioning key manually?
Usually, no.
- In the Newt config file itself, the answer is no: Newt either removes `provisioningKey` or ignores the one-time key once `id` and `secret` are present.
- If you passed the key on the command line, there is no Newt config entry to clean up afterward.
- If you put the key in a startup script, cloud-init file, image, or other bootstrap artifact, remove it there if you do not want it reused.
**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.