Help

If your fleet already lives in another monitor, you do not need to retype it. TowerOps can import a CSV of devices, the file your existing tool can already produce, and create every device with the same identity rules and plan limits as the manual form.

The CSV format

name and ip are required; every other column the parser accepts is optional:

Column	What it does
name	a label for the device
ip	IPv4 or IPv6 address the agent polls
snmp_community	a per-device community string. Leave it empty and the credential probe finds the right one instead, a community in this column stamps the device and skips the probe.
snmp_version	1, 2c, 3 (defaults to your organization's setting). SNMPv3 rows cannot carry a username in a column, in the preview, assign each v3 row an SNMPv3 credential set or let the credential probe discover its credentials.
credential_set	the name of an SNMPv3 credential set to bind to the row. Only mappable while the bulk-credentials import feature is on for your account; off, the column is dropped in the mapping step.
site	a site name that already exists in your organization
description	free text stored on the device
check_interval	seconds between polls for this device
lifecycle	active, paused or retired
purchased_on	purchase date
warranty_expires_on	warranty expiry date
eol_on	vendor end-of-life date
agent	the name of an installed agent; the device is assigned to that poller, so a split fleet does not need a second pass through the UI
id	the id column of a TowerOps export. A row carrying it is matched to that device, so an edited IP or name re-addresses the existing device instead of duplicating it, which is what turns the import into a repeatable update path.

Finding credentials automatically

You do not need to copy community strings out of the old tool. Import the file without the snmp_community column, then add your credential sets under Organization Settings → Credentials in priority order. When each imported device is polled and no credential answers, the credential probe walks those sets until one succeeds and pins the winner on the device.

Only fill the snmp_community column for devices whose community is deliberately unique, the value is stamped onto the device and the probe is skipped for it.

A header row is optional. With one, column order doesn't matter:

name,ip,snmp_community,snmp_version,site
Core Router,10.0.0.1,public,2c,Main Office
Backhaul Tower 4,10.0.0.14,public,1,Tower 4

Without a header the parser reads only the five positions above, name, ip, snmp_community, snmp_version and site, in that order; a header row is what unlocks the rest of the columns, so an export that carries them must keep it.

Core Router,10.0.0.1,public,2c,Main Office
Backhaul Tower 4,10.0.0.14,public,1,Tower 4

Where each tool puts the values

• LibreNMS: export devices from the API (GET /api/v0/devices) or the Devices page's CSV export; the import maps its hostname, IP and location columns automatically.
• The Dude: export the device list from Files → Export (or copy the table); name and address columns map automatically.
• Zabbix: export hosts from Configuration → Hosts → Export; the import maps its name, IP and location columns automatically.

What the import does with each row

Every row becomes one device through the same code path as the New Device form, the same validations, the same (organization, site, IP) duplicate rule, and the same plan device limit. After the import you see a per-row report: imported, skipped because the device already exists, held back by your plan limit, or failed with the reason.

Open the import page