Getting your data into nxip

Nothing yet, starting fresh

No existing infrastructure to bring in - you're just trying nxip out, or standing up something new. Getting started walks through creating your first pool and subnet directly, with curl, in a couple of minutes.

From there, pick a declarative path once you're doing this for real: Terraform or nxip-cli.

Deployed in AWS or Azure

The path most real estates need. Read-only, no nxip account required, and nothing leaves your machine until you choose to load something in. It finds what's actually deployed, including the collisions between AWS and Azure that neither cloud's own IPAM can see, then emits a manifest that registers it exactly as it is.

npx nxip-cli scan aws azure

Start with Environment discovery for the full walkthrough, including how collisions are detected, which overlaps are expected (CGNAT, link-local), and how to share a report safely.

You already know your CIDRs

Maybe it's a datacenter you can't run a scan against, a cloud nxip doesn't support yet, or you just know off the top of your head that the office VPN is 10.20.30.0/24. You don't need a scan for this - you need to register the exact block you already have, not have nxip hand you a different one.

Every path into nxip that creates a subnet takes an explicit cidr as an alternative to asking for a prefixLength and getting the next free block. Use whichever surface matches how you already work - all three register the same thing, a 10.20.0.0/16 pool for a London datacenter with the office VPN's real /24 inside it.

The API, with curl

curl -X POST https://nxip.dev/v1/pools \
  -H "x-api-key: $NXIP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "London DC",
    "cidr": "10.20.0.0/16",
    "family": "IPV4",
    "environment": "production",
    "region": "dc-lon1"
  }'

curl -X POST https://nxip.dev/v1/subnets \
  -H "x-api-key: $NXIP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "office-vpn",
    "environment": "production",
    "region": "dc-lon1",
    "family": "IPV4",
    "cidr": "10.20.30.0/24"
  }'

Terraform

resource "nxip_pool" "london_dc" {
  name        = "London DC"
  cidr        = "10.20.0.0/16"
  family      = "IPV4"
  environment = "production"
  region      = "dc-lon1"
}

resource "nxip_subnet" "office_vpn" {
  environment = nxip_pool.london_dc.environment
  region      = nxip_pool.london_dc.region
  family      = nxip_pool.london_dc.family
  cidr        = "10.20.30.0/24"
}

See the Terraform quick start for getting the provider and an API key set up first.

nxip-cli

$ cat datacenter.yaml
pools:
  - name: London DC
    cidr: 10.20.0.0/16
    family: IPV4
    environment: production
    region: dc-lon1

subnets:
  - name: office-vpn
    environment: production
    region: dc-lon1
    family: IPV4
    cidr: 10.20.30.0/24

$ nxip plan -f datacenter.yaml     # dry run, nothing is written
$ nxip apply -f datacenter.yaml

Either way, nxip won't hand you a different block: cidr registers exactly what you give it, and fails if it's already taken or falls outside its pool - it never silently substitutes something else.

Tracked in a spreadsheet

Guided CSV import is designed, not built yet. Today, the practical path is the one above: most spreadsheets already have name, CIDR, and region columns, which map directly onto an nxip-cli manifest. Copy them across, adjust environment names to match how you actually label things, and nxip plan will tell you exactly what it's about to create before anything happens.

Missing something you need now? Tell us.

Already in nxip, want Terraform to manage it

This is the one direction that doesn't add anything new to nxip - it's the opposite one. If you've already got pools or subnets in nxip, created by hand, by a script, or by a discovery scan, and now want Terraform managing them going forward, that's importing existing resources into Terraform, not this page.