Often, the culprit isn’t the AI models themselves. It’s that they’re being applied without careful thought to providing AI with the appropriate semantic context to guide reasoning and action. Without the right context, infrastructure AI systems quickly drown in seas of data and fail to deliver value.

The Context Problem in Infrastructure AI

When we deploy AI agents in business applications, we’re careful to provide them with rich context: customer data, transaction histories, business rules, and relationship mappings. Palantir, for example, is famous for its thoughtful use of semantic ontologies to layer contextual meaning onto business data. But in infrastructure, we often throw AI at raw telemetry data, configuration files, and log streams without the semantic understanding that makes these data points meaningful.

Consider a simple scenario: an AI agent detects high CPU utilization on a server. Without semantic context for the AI about how the server fits into the environment and applications, the agent might:

• Gather a large pile of metrics about the server, blowing the context window
• Restart the server during peak business hours
• Scale resources without understanding cost implications
• Miss recent infra changes upstream or downstream of the server that explain the issue

The same telemetry data becomes actionable intelligence when the AI understands the server’s role, its relationships to other systems, the business criticality of its workloads, and the operational context around it.

What Makes Infrastructure Context Different

Enabling AI with semantic context for infrastructure goes beyond injecting simple asset inventories into the AI’s context. It requires capturing:

Physical and Logical Topology: How devices connect, which services depend on which infrastructure, and how failures cascade through the environment.

Operational Context: Historical changes, business criticality ratings, and operational parameters that govern how infrastructure should behave.

Configuration Relationships: How configuration changes in one system affect others, which settings are interdependent, and what the intended state should be.

Without this semantic foundation, AI agents operate in a vacuum, making poor use of their limited context windows to churn through telemetry, resulting in inaccuracies or in some cases driving decisions that are operationally disastrous.

The Semantic Map Solution

A semantic map for infrastructure serves as the knowledge graph that AI agents need to make informed decisions. It’s not just documentation, it’s a living, machine-readable representation of your infrastructure’s reality.

This semantic layer transforms raw infrastructure data into contextual intelligence:

• Device telemetry becomes “the primary database server in the customer-facing application stack is showing signs of stress”
• Configuration drift becomes “a security policy change that could impact compliance for financial services workloads”
• Network anomalies become “unusual traffic patterns between the development and production environments that violate segmentation policies”

Building Your Infrastructure Semantic Map

Creating an effective semantic map requires more than asset management, it demands a comprehensive understanding of infrastructure relationships and context. It’s no surprise that NetBox, the most widely used system of record for documenting and modeling networks and infrastructure, is increasingly being deployed as the standard semantic map for network and infrastructure AI.

What we’re seeing from teams leveraging NetBox as the semantic map is that the most successful AI operations implementations focus on:

Relationships, Not Just Inventory: The connected nature of NetBox’s data model, which encodes real-world relationships between infrastructure elements and enforces realistic constraints, results in critical context used by AI agents to drive exploration of telemetry and reason about the infrastructure.

Easily Exposing Semantic Context to AI: NetBox MCP is effectively an API for exposing NetBox’s data model directly to AI agents. It’s no surprise that the project has seen huge interest. The open source nature of NetBox and the normalized nature of the core NetBox data model is also a superpower for AI use cases: every major LLM already knows NetBox’s data model and can navigate it adeptly.

Delivering Context with Confidence: Static documentation becomes stale. Your semantic map must evolve with your infrastructure through automation and integration. For all the reasons network and infrastructure automation must be driven by a source of truth, so too must AI operations. Managing intent and eliminating drift in your infrastructure from your source of truth are critical to creating confidence in the context you are providing your AI agents.

The infrastructure teams succeeding with AI aren’t necessarily the ones with the most sophisticated LLM models, they’re the ones with the most effective semantic context. They’ve invested in building comprehensive maps of their infrastructure that provide the contextual foundation AI agents need to be effective. These teams are accelerating with AI, while others feel like their AI efforts are wasted.

At NetBox Labs, we’re fully invested in making NetBox the best semantic map for network and infrastructure AI. Our partners, customers, and community are leading the charge by building AI agents atop NetBox MCP or other connections. And we’re pushing the AI operations limits by building our own deeply capable agents, like NetBox Copilot. Across all these dimensions, we’re learning, investing in, and sharing the most effective approaches for connecting AI with NetBox’s semantic map.

The question isn’t whether AI will transform infrastructure operations, it’s whether your infrastructure management stack is ready to provide the semantic context that makes AI transformation possible.

The post Why AI for Infrastructure Fails Without a Semantic Map appeared first on NetBox Labs.

At NetBox Labs we work with the teams operating the largest and most automated infrastructure environments in the world. Hyperscale operators building massive AI datacenters at incredible speed. Enterprises managing tens of thousands of network devices across hundreds of sites. Teams where NetBox isn’t just a documentation tool — it’s the system of record at the center of their automation stack.

These teams push NetBox hard. They’re syncing data from CMDBs and discovery platforms, running CI/CD pipelines that provision infrastructure programmatically, and exporting complete datasets into analytics and visualization systems. And the common thread in every conversation we have with them is the same: the standard REST and GraphQL APIs are fantastic for interactive use and moderate-scale automation, but when you need to load 500,000 devices or export two million IP addresses, per-object API calls hit a wall.

Today we’re announcing TurboBulk — a high-performance bulk data API for the NetBox Labs platform that processes tens of thousands of objects per second. Insert, upsert, delete, and export millions of rows in minutes instead of hours. Built in partnership with several of our large-scale AI datacenter customers, and available now as a customer preview for NetBox Cloud and NetBox Enterprise premium tier customers.

Why Bulk Operations Need a Different Approach

The NetBox REST API is designed around individual objects. You POST a device, you get back a fully validated, serialized device with all its relationships resolved. Every custom validator runs. Every webhook fires. Every changelog entry is created synchronously. That’s exactly what you want when you’re creating a device from a form or updating a description from a script.

But that per-object overhead adds up. Even on a well-provisioned, performance-tuned NetBox Community deployment, the REST API typically sustains 100-200 objects per second with full validation and serialization. Loading 100,000 devices takes over eight minutes. A million takes over an hour. And real-world bulk workflows don’t involve just devices — they involve interfaces, IP addresses, cables, connections. A single datacenter buildout can easily produce hundreds of thousands of objects across a dozen models. Iterating on a large environment’s worth of infrastructure designs can involve millions.

TurboBulk takes a fundamentally different approach. Instead of processing objects one at a time through the ORM, it operates at the database level — bulk SQL operations that process entire datasets in single statements, wrapped in atomic transactions. The results NetBox Labs customers are seeing is throughput that’s orders of magnitude faster while maintaining the data integrity guarantees that matter.

The Platform Picture

If you’ve been paying attention to what we’ve been building at NetBox Labs, TurboBulk fits into a larger story about what the NetBox Labs platform becomes at scale.

TurboBulk is one of a growing set of capabilities — alongside Visual Explorer, Event Streams, Branching, and NetBox Copilot — that differentiate the NetBox Labs platform for production grade use cases and provide value for the most demanding infrastructure environments. Visual Explorer depends on TurboBulk’s export engine to deliver interactive visualizations of massive-scale infrastructure directly from your live source of truth. Event Streams turns the NetBox Labs platform’s state changes into real-time data feeds for automation and security. TurboBulk makes it possible to read and write data at the scale these workflows demand.

As the environments our customers manage grow larger and more automated, the NetBox Labs platform grows with them.

How It Works

Bulk Exports and Intelligent Caching

The most immediately valuable capability for most teams is bulk export. Instead of paginating through the REST API one page at a time — which for a million objects means thousands of round trips, each with serialization overhead — TurboBulk generates a complete export file server-side and makes it available for download in JSONL or Parquet format. Filters and field selection let you scope the export to exactly what you need.

What makes this particularly powerful for operational workflows is the caching layer. TurboBulk computes a deterministic cache key from your export parameters and checks whether the underlying data has changed since the last export by consulting NetBox’s audit log. If nothing has changed, the cached file is returned immediately — no query, no serialization, no generation. Clients that already have the file can send their cache key and receive an HTTP 304 — no data transferred at all.

This changes what’s practical to build. Analytics dashboards, visualization tools, and sync pipelines can request fresh data frequently, only downloading when something has actually changed. We use this pattern ourselves — it’s what powers the data layer behind Visual Explorer. When you’re navigating across complex, detailed infrastructure views — drilling from a 3D floorplan into a rack elevation, tracing a cable path across a dense fabric — the experience feels real-time because TurboBulk’s cached exports deliver complete, consistent snapshots from your live NetBox data without the latency of regenerating them on every request.

Bulk Writes: Stage, Merge, Commit

For teams that need to write at scale — initial data population, ongoing syncs, iterative infrastructure design — TurboBulk’s write path takes a fundamentally different approach from the REST API. Instead of processing objects one at a time through the ORM, it operates at the database level.

A write operation starts with a data file — we recommend JSONL for most use cases. The file is uploaded and an asynchronous job is created. On the server side, incoming rows are ingested using PostgreSQL’s native COPY protocol — the fastest path into Postgres — streaming into a temporary staging area in configurable chunks to keep memory usage constant regardless of dataset size. The final operation — insert, upsert, or delete — executes as a single bulk SQL statement that merges the staged data into the target table. The entire pipeline is wrapped in an atomic transaction: either every row commits, or none do. There is no partial state.

This is what makes the performance difference fundamental rather than incremental. We’re not optimizing the per-object path — we’re replacing it with a set-based approach that lets PostgreSQL do what it’s built to do.

Knobs for Power Users

TurboBulk is designed for operators who understand their data and want explicit control over the tradeoffs. A few examples:

Validation modes — Three levels that let you choose the right balance of speed and safety. None relies on database constraints only — the fastest mode, appropriate for trusted sources. Auto (the default) adds SQL-based pre-validation rules for models like IPAM prefixes where database constraints alone aren’t sufficient. Full runs Django’s model validation on every object — 30 to 60 times slower, but the right call for untrusted data or complex models like cables.

Changelogs and event dispatch — Audit trail and webhook/event-rule dispatch are supported and enabled by default, so downstream systems stay in sync. Both can be disabled per-operation for initial loads where the overhead isn’t justified.

Dry-run mode — Validates data through the full pipeline without committing. Ingested, staged, merged, validated — then rolled back. Fix your data, run again. This makes it practical to iterate on large datasets without risk.

Branching — TurboBulk integrates with NetBox Branching, so you can load or delete within an isolated branch, review the changes, and merge to main when ready.

Performance in Practice

Here’s what this looks like with real data. We recently tested TurboBulk against a production-scale NetBox dataset from a large real-world infrastructure environment: tens of millions of objects — several hundred thousand devices, nearly ten million interfaces, millions of cables and IP addresses.

Using the standard REST API, the export managed a few hundred thousand objects before running out of memory. At roughly 170 objects per second, the full dataset would have taken over 23 hours — if it could fit in memory at all.

TurboBulk exported the entire dataset in about 10 minutes. More than 24,000 objects per second, under 500 MB of memory. Over 100x faster, handling an order of magnitude more data, using a fraction of the memory. On a laptop — not a tuned production server.

This isn’t a synthetic benchmark. It’s a real-world dataset running through the same pipeline our customers use.

Customer Preview — Get Started

TurboBulk is available now as a customer preview, included in the premium tier of NetBox Cloud and NetBox Enterprise. Reach out to your customer success representative or contact us to get it enabled on your account.

The Python client library, comprehensive documentation, and progressive example scripts are available at netboxlabs/netbox-turbobulk-public on GitHub.

TurboBulk was built in partnership with several of our large-scale AI datacenter customers, and we’re continuing to develop it based on real-world feedback. If your team is pushing the limits of what’s possible with NetBox at scale — we built this for you.

The post Bulk Operations at Scale: Introducing NetBox TurboBulk appeared first on NetBox Labs.

Later this summer, in June, NetBox will celebrate ten years of existence. When DigitalOcean released NetBox as open source in 2016, nobody was projecting 20,000 stars. The project found an audience because it solved a real problem, and the community that formed around it never let up.

By the Numbers

The history of the GitHub stars given to the NetBox repo tells a significant story.

The first 10,000 stars took about six years. The second 10,000 took four. The project now has 391 contributors, 14,904 commits, and more than 3,000 forks. There have been 351 releases since v1.0, with the latest, v4.5.4, shipping on March 3. That works out to roughly one release every ten days, a pace that has held for years.

The Community Behind It

Those numbers come from real people. NetBox Community is the open source project, hosted at github.com/netbox-community/netbox under the Apache 2.0 license. NetBox Labs, as the commercial steward of NetBox, employs a core (and rapidly growing) team of engineers who maintain and develop it. In addition, nearly 400 community contributors have shaped the project over the past decade – filing issues, writing code, reviewing pull requests, and helping build an ecosystem of plugins and integrations around the core.

Open source software like NetBox deserves sustained investment, and that investment comes from real product value delivered to real customers. NetBox Labs builds products for organizations managing complex, critical infrastructure on top of NetBox. When customers adopt those products, the revenue funds dedicated engineering teams who carry NetBox and other community projects forward full-time.

What the Community Built Makes What Comes Next Possible

Ten years of community contributions built the most widely adopted open source network source of truth in the world. That means a structured, consistent data model covering devices, interfaces, IP space, circuits, cabling, and the relationships between all of it. That data model is now the foundation for something the original contributors could have never anticipated, with AI agents that can understand your network and infrastructure.

NetBox Copilot is an AI-powered assistant that understands your network and infrastructure. It uses the structured context in NetBox to let teams query, manage, and automate infrastructure through natural language, answering questions like “Which devices are missing management IPs?” in seconds because the community spent a decade making sure that data was modeled correctly. Copilot has also moved beyond read-only operations for NetBox Labs customers to create, update, and delete records, with human approval on every write.

The broader shift led to NetBox Labs becoming the system of record platform that makes AI-driven infrastructure operations possible. NetBox Labs is building the platform layer on top – from Copilot to Discovery to Assurance. The same structured knowledge graph that teams rely on for automation and compliance is now what makes AI agents trustworthy when they operate on production networks.

What’s Ahead

The growth is still accelerating. The contributor base is still expanding. The project shipped 351 releases in ten years, and that cadence has not slowed.

To everyone who has starred, filed an issue, submitted a pull request, answered a question in Slack, or built a plugin: this milestone is yours. The community’s work is what made NetBox the system of record for network infrastructure, trusted by more than 10,000 teams worldwide. Sign up for the NetBox Labs newsletter to stay informed on where NetBox and NetBox Labs go next.

The post NetBox Community Hits 20,000 GitHub Stars appeared first on NetBox Labs.

The post Understanding Cable Profiles in NetBox 4.5 appeared first on NetBox Labs.