Bulk onboarding

Adding devices one at a time is fine for a handful. For a rack or a site, the bulk onboarding wizard takes a pool of addresses that share one connection profile and creates a source and tracked config for each — with a probe pass in the middle so a wrong credential is caught before anything is created.

Open it from Configuration Tracker → Configs → Onboard (bulk). Onboarding is a composition of three ordinary create paths, so the wizard is only offered to an operator holding all three create rights — sources, tracked configs and collection jobs. Without them the page shows an “insufficient permissions” note instead of the wizard.

Every address in one onboarding run shares a single header:

• Transport — any of the six (ssh, telnet, scp, sftp, http, https). The wizard sends no transport settings, so every source it creates gets the transport’s defaults — for the SSH family that means trust_on_first_use host-key pinning, no paging command and no device-type override. If a device needs one of those, edit its source afterwards under Configuration Tracker → Settings → Sources.
• Credential — one vault entry for the whole batch, required for ssh/telnet/scp/sftp and optional for HTTP(S).
• Recipe — required. There is no default recipe to fall back on, and its kind must match the transport: a file recipe belongs to an scp/sftp source and nowhere else, and an scp/sftp source is rejected with anything but a file recipe. The recipe also decides masking for every config the run creates — a recipe with no scrub set stays fully masked, and one whose set has automatic masking switched off carries that choice to the whole batch.
• Port — optional; blank uses the transport default (22 for the SSH family, 23 for telnet, 80/443 for HTTP(S)).
• Collector — defaults to the embedded one; the picker only appears once you have more than one collector.

Only the address varies per device. If a subset of devices needs a different profile, run the wizard once per profile.

Choose the shared profile above and paste the address pool — one IP or FQDN per line, or comma/space separated, up to 25 addresses per run. A counter under the box tracks how many it parsed against that cap. Duplicates collapse, and an entry that is neither a valid IP literal nor a well-formed hostname is reported per-address later, not accepted: there is no subnet or range syntax here, so 10.0.0.0/24 is rejected — expand it into addresses. There is no file upload; the pool is typed or pasted.

A stop-on-first-error toggle lets you abort the batch on the first failure instead of continuing. Continue won’t leave this step until a transport, a recipe, a credential (where the transport needs one) and at least one address are set.

Before creating anything, Probe sample connects to the addresses with the shared credential and recipe and persists nothing — no source, no config, no snapshot. This catches a bad shared credential or wrong transport before you spray it across the pool. It walks the whole pool, one address per request, with a progress bar filling the results table as it goes. Each probed address comes back as:

Result	Meaning
Reachable	Reached and authenticated.
Auth failed	Reached, but the credential was rejected.
Unreachable	Couldn’t connect (or, with a just-in-time credential, its account was busy).
Error	Bad address, an FQDN that doesn’t resolve, or another error.

A Device column shows the name of the network device whose host address matches — that name becomes the tracked config’s name at import, instead of the bare address.

If the sample looks wrong, go Back, fix the profile, and probe again — nothing has been created yet. Editing any setup field discards the probe result, since the header it was taken under no longer applies.

Probing is optional — you can continue straight to Import — but if you did probe, the import only attempts the addresses that came back Reachable, and tells you how many it excluded. A device that happened to be down during the sample is therefore not onboarded; run the wizard again for it.

The import creates objects for the addresses that make sense to onboard. For each address, in isolation, it finds or creates a network object for the target (a host object for an IP, an fqdn object for a name), creates a source named onboard-<address>-<transport><port> — plus a short recipe discriminator, so the same device collected two ways doesn’t collide — then a tracked config, and probes the device once. Each address ends as:

Status	Meaning
Created	Network object, source and tracked config created; the probe succeeded.
Skipped	An identical config already exists (same target + transport + effective port + recipe, whichever collector fetches it) — nothing duplicated.
Unreachable	Couldn’t connect; nothing left half-created.
Auth failed	Credential rejected; nothing left half-created.
Error	Another failure; nothing left half-created.

Each address is created inside its own transaction savepoint, so a failure on one rolls that address back cleanly — you never end up with an orphaned source and no config. The wizard also sends one address per request, so every result is committed as it lands: a closed tab or a dropped connection keeps what has already been created. With stop-on-first-error off, one bad address never aborts the rest of the batch. The whole import (including the per-address probe spray and every address’s outcome) is audited; the sample run is audited too, as a summary.

The probe only proves the device answers — it stores no snapshot. So when you press Done and land back on the Configs list, the new tracked configs read Never collected until the next scheduled sweep collects them, or you collect one now and pin a baseline.

A rack of identical switches. One SSH credential, the matching vendor recipe, paste the 25 management IPs, probe the pool, import. Twenty-five tracked configs, each with its own history.

A remote site. Select the site’s standalone collector in the profile so every onboarded source is bound to it, then paste the site’s addresses.

Re-running after adding devices. Paste the full list again — already-onboarded addresses come back Skipped (an identical config exists), so only the new ones are created.

• 25 addresses per run is a deliberate bound — onboarding is synchronous and probes real devices; keep batches modest and run the wizard again for the next pool. (The API caps a single sample call at 10 addresses, which the wizard never reaches: it probes one address per call.)
• The per-address probe happens once and is not retried — an auth failure won’t hammer a device toward lockout.
• Pick the recipe carefully. Without one nothing gets created at all: the probe has nothing to fetch and every address fails with “No recipe resolved for this address”.
• Onboarding is a composition of the normal create paths — every object it makes is an ordinary network object / source / tracked config you can edit or delete afterwards, and each config is seeded with a correlation address so change attribution works from the start.

• Tracked configs & transports — the objects onboarding creates.
• Recipes & scrub sets — the recipe a batch shares, and what it masks.
• Credentials & the vault — the shared credential a batch uses.
• Collectors — onboarding onto a specific collector.
• Snapshots, diff & drift — collecting and baselining what you onboarded.