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 safe sample probe in the middle so a wrong credential can’t spray your whole fleet into lockout.

Open it from Configuration Tracker → Configs → Onboard (bulk).

Every address in one onboarding run shares a single header:

• Transport and its settings (e.g. ssh)
• Credential (often one just-in-time or stored credential for the whole batch)
• Recipe (e.g. “Cisco IOS — running-config”)
• Port (optional; blank uses the transport default)
• 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, up to 25 addresses per run. A stop-on-first-error toggle lets you abort the batch on the first failure instead of continuing.

Before creating anything, the wizard probes up to 10 of the addresses — actually connecting with the shared credential and recipe — and persists nothing. This catches a bad shared credential or wrong transport before you spray it across the pool. Each sampled address comes back as:

Result	Meaning
OK	Reached and authenticated.
Auth failed	Reached, but the credential was rejected.
Unreachable	Couldn’t connect.
Error / invalid	Bad address, or another error.

If the sample looks wrong, go Back, fix the profile, and re-probe — nothing has been created yet.

The import creates objects for the addresses that make sense to onboard. For each address, in isolation, it creates a network object, a source (with a deterministic name so re-runs are idempotent) and a tracked config, then probes the device once. Each address ends as:

Status	Meaning
Created	Network object, source and tracked config created; first probe done.
Skipped	An identical source already exists (same transport + address + port + recipe) — nothing duplicated.
Unreachable	Couldn’t connect; nothing left half-created.
Auth fail	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. 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) is audited.

When it finishes, you’re back on the Configs list with the new tracked configs in place — ready to collect and pin baselines.

A rack of identical switches. One SSH credential, the matching vendor recipe, paste the 25 management IPs, sample a handful, 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 (identical source exists), so only the new ones are created.

• 25 per run / 10 sampled are deliberate bounds — onboarding is synchronous and probes real devices; keep batches modest and run the wizard again for the next pool.
• The per-address probe happens once and is not retried — an auth failure won’t hammer a device toward lockout.
• Onboarding is a composition of the normal create paths — every object it makes is an ordinary source / tracked config you can edit or delete afterwards.

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