How IPCraft organizes your network data.
Every IPCraft account belongs to an organization. Your organization is your tenant boundary. All subnets, addresses, and settings are scoped to your organization and completely isolated from other tenants at the database level using PostgreSQL row-level security.
Folders are top-level groups that group your subnets by purpose, location, or environment. Examples:
Folders are optional. Subnets can exist without a folder assignment.
Subnets represent CIDR blocks in your network. They form a hierarchy: a /16 can contain multiple /24s, which can contain /28s, and so on.
Automatic nesting: When you create a new subnet, IPCraft automatically finds its parent in the tree. Adding 10.1.1.0/24 when 10.1.0.0/16 already exists will nest the /24 under the /16.
Overlap detection: Subnets are CIDR blocks, so any two either nest — one fully contains the other — or occupy entirely separate space. Containment is expected and auto-nested; creating an exact duplicate of a subnet already in the same VRF is rejected.
Splitting: You can split any subnet into equal parts (powers of 2). Splitting a /24 into 4 creates four /26 subnets. Address records in the original subnet are moved into whichever new subnet contains them, so hostnames, MACs, and statuses survive the split. If you'd rather start clean, the split dialog has an option to discard the records instead.
Utilization: Each subnet shows what percentage of its usable addresses are assigned. The tree view color-codes this: green (<70%), yellow (70-85%), red (>85%).
Roll-up counts: A parent subnet's usage includes the addresses recorded in its child subnets, so a /16 whose /24s are filling up doesn't read as empty. Wherever a count includes descendants — like the dashboard's IP Address Footprint — it's marked with an asterisk (230/65534*). The subnet's own detail view shows only the addresses recorded directly in it, with a separate note for how many live in its children.
Container subnets: Some large subnets exist only to give your address plan structure — a 10.10.0.0/16 that designates "corp" space while its child /24s hold the actual assignments. Nobody reserves IPs out of the /16 itself, so measuring its utilization is meaningless: at /16 scale it reads as a permanent <1%, and its 65,000+ addresses of phantom capacity dilute your dashboard's overall utilization into a rounding error. Untick Track IP usage in the subnet's edit dialog to mark it as a container: the tree shows a Container badge instead of a utilization bar, and the subnet drops out of the dashboard's capacity, utilization, and status-mix numbers. Child subnets are unaffected — they keep their own bars and stats — and you can still record addresses in a container if you need to. New subnets are tracked by default.
Carving out child subnets: To allocate new space inside a parent, use the + action on its row in the subnet tree. Pick a size (say, a /24) and IPCraft computes the free blocks that don't collide with any existing subnet in the same VRF, shows how many remain, and pre-fills the create dialog with the block you choose — no manual CIDR math, no after-the-fact overlap surprises. The same computation is available to scripts via the free-blocks endpoint.
Gateway: A subnet's gateway field and an address record with the gateway status are kept in sync: setting one updates the other. Set the gateway on the subnet and IPCraft creates (or re-flags) the matching address record; mark an address as gateway and the subnet's gateway field follows.
Addresses represent individual IP assignments within a subnet. Each address tracks:
For subnets /22 and smaller, the UI shows all usable IPs with available addresses highlighted for easy assignment.
Beyond folders, three optional dimensions help model real networks:
10.0.0.0/24) can exist once per VRF — useful for multi-tenant networks and overlapping RFC 1918 space.Each has its own page in the app sidebar and full CRUD support in the API. When importing CSVs, VLANs, VRFs, and locations referenced by name are created automatically.
The Overlaps page surfaces subnets that share address space but are not in a direct parent/child relationship in the tree — the cases worth a second look. Because subnets are CIDR blocks, an overlap is always one of two kinds: a duplicate (two subnets with the exact same CIDR, which can happen across different VRFs or for VRF-less subnets) or a containment (one subnet fully inside another without being its tree child). Normal nesting never appears here. A healthy address plan shows an empty Overlaps page.
Every change — create, update, delete, split, import, export — is recorded in the Activity log with a timestamp, the acting user, the source (web or API key), and a field-level diff of what changed. How far back the log retains depends on your plan (7 days on Free, up to 730 on Enterprise).
Entries are chained with a SHA-256 tamper-evidence hash. Click Verify integrity on the Activity page to re-check the chain; IPCraft reports how many entries verified and skips any that predate hashing.
IPCraft's data model follows a natural network hierarchy:
Organization
└── Folder (Production)
├── Subnet (10.0.0.0/16 — US East)
│ ├── Subnet (10.0.1.0/24 — Web)
│ │ ├── 10.0.1.1 — gateway-01 (Gateway)
│ │ ├── 10.0.1.2 — web-01 (Assigned)
│ │ ├── 10.0.1.3 — web-02 (Assigned)
│ │ └── 10.0.1.4 — (Available)
│ └── Subnet (10.0.2.0/24 — Database)
└── Subnet (10.0.0.0/24 — Management)
Each plan has limits on how many resources you can create:
Plans also set limits on VLANs, VRFs, locations, webhooks, and API keys — see the full limits table in the API reference. When you hit a limit, the API returns 402 Payment Required with a message to upgrade.