IPAM · Terraform-native · Cloud and on-prem

IP address management for infrastructure as code

One source of truth for every range you own, across cloud and on-premise, with a Terraform provider as the primary interface. Every allocation comes from the same authority, so two teams cannot be handed the same block.

Start freeSee how it works

Free tier, no card. Or scan what you already run:npx nxip-cli scan aws azure

main.tf
resource "nxip_subnet" "web" {
  environment   = "production"
  region        = "eu-west-2"
  prefix_length = 24
}

# No CIDR. nxip allocates one against every
# range you own, so it cannot collide.

resource "aws_subnet" "web" {
  cidr_block = nxip_subnet.web.cidr
}
10.0.0.0/16production · eu-west-237.5% used
  • App tier
  • Data tier
  • Transit and endpoints
  • Kubernetes pods
  • free
24,576 of 65,536 addresses, across 6 subnets, so the pool is 37.5% used. The gaps are free space, drawn where it actually falls.

Already running address space? Start from what exists

Nobody starts from a clean sheet. Discovery reads AWS and Azure with the credentials you already have, reports what collides, and writes a manifest you review before anything is imported. Read-only, and nothing leaves your machine.

$npx nxip-cli scan aws azure
nxip-cli · scan
Once it is in, the map places every pool: cloud regions resolve themselves, and on-prem sites take a latitude and longitude from metadata.
The nxip map, showing seven address pools placed across Oregon, Virginia, London, Manchester, Frankfurt, Singapore and Sydney, each marker coloured by how allocated that pool is.
Cloud regions place themselves. On-prem sites take a latitude and longitude from metadata, so a datacentre sits on the map next to the VPCs it peers with.
Every PR gets reviewed against real, live address space
A plain terraform plan can tell you a subnet is being created. It can't tell you what CIDR it'll get, or how full that leaves the pool - only nxip has visibility into everyone else's allocations.
$ terraform apply
Terraform will perform the following actions:

  # nxip_subnet.payments will be created
  + resource "nxip_subnet" "payments" {
      + cidr             = "10.0.32.0/24"
      + environment      = "production"
      + family           = "IPV4"
      + id               = (known after apply)
      + landing_point    = (known after apply)
      + metadata         = (known after apply)
      + name             = "payments"
      + parent_subnet_id = (known after apply)
      + prefix_length    = 24
      + region           = "eu-west-2"
    }

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
terraform plan cannot name the block, because nothing has asked nxip for one yet. The apply does, and 10.0.32.0/24 comes back into state: the first free /24 in the pool drawn at the top of this page.
On a real pull request
ResourceStatusCIDRDestinationUtilization
nxip_subnet.payments_production✅10.101.16.0/24subnet us-east-1 region block12% → 18%
See how the PR bot works →
Built for how infrastructure actually gets provisioned
Every allocation is an API call, auto-picked or manually registered, concurrency-safe. Manage it directly, or through the nxip Terraform provider.
Hierarchical subnets
Nest subnets to match a real address plan (region → VPC → AZ, or site → zone → VLAN), with auto-resolution onto an existing structure, or explicit parent_subnet_id nesting when you need it.
Terraform-native
A published provider on the public Terraform Registry (uk-sw/nxip), with nxip_pool and nxip_subnet resources, drift detection, and import support for infrastructure you already have.
Collision-aware PR reviews
A GitHub Action comments on every PR touching a subnet with the exact CIDR it’ll get and the utilization impact on shared capacity, before terraform apply runs, not after a plan fails.
Multi-cluster Kubernetes CIDR authority
Carve guaranteed non-overlapping pod and service CIDR blocks for EKS, AKS, and GKE clusters, checked against every other cluster and every other piece of address space in your organization, before the cluster exists.
A plan/apply loop without Terraform
nxip-cli gives on-prem and non-Terraform teams the same plan/apply reconciliation loop from a YAML manifest, plus a scaffold command that expands a whole new site’s addressing plan across multiple clouds in one shot.
Multi-environment, multi-region
Pools are scoped by environment and region, so production and staging never collide, and the same declarative config works whether or not a given region exists yet.
IPv4 and IPv6
Both address families are first-class, with the same hierarchy and auto-resolution model, not an IPv6 afterthought bolted onto an IPv4-only schema.
Free-form metadata
Tag any subnet with your own key/value pairs (vpc_id, cost_center, owner) stored and returned as-is, so the systems that already track ownership can read it straight from nxip.
Scoped API keys
Every key carries its own Admin / Member / Read-only role, so a CI pipeline’s credentials never need more access than the job actually requires.
Pricing
Start free. No card required.
Free
$0
Evaluate nxip against real infrastructure.
  • 6 IP pools
  • 20 subnets
  • 4,096 IPv4 addresses
  • 1 seat
  • Community support
Sign up
Starter
$39/mo
Outgrown solo evaluation, not yet a full platform team.
  • Unlimited pools
  • 80 subnets
  • 16,384 IPv4 addresses
  • Up to 5 seats
  • Admin/Member/Read-only roles
Upgrade to Starter
Team
$119/mo
Staging + prod, for platform teams.
  • Unlimited pools
  • 500 subnets
  • 262,144 IPv4 addresses
  • Up to 25 seats
  • Email support
Upgrade to Team
Enterprise
Contact us
Compliance requirements, custom scale.
  • Unlimited pools, subnets and addresses
  • Unlimited seats
Contact us
Running a security review? Where your data lives, who processes it and our questionnaire answers are on thetrust page.