Infrahub Profiles Manage Infrastructure and Network Standards at Scale

Network and infrastructure teams face the persistent challenge of maintaining consistent configurations across thousands of devices while standards are continuously evolving.

Configuration drift is common. Devices start to diverge from documented standards and exceptions pile up without documentation. Teams lose track of which configurations are intentional versus accidental.

When things break, troubleshooting turns into guesswork, inconsistent policies create security vulnerabilities, and compliance audits become weeks-long digs.

Traditional approaches, such as Git-based workflows, database frameworks, and vendor
tools, all treat standards as one-time snapshots. Once infrastructure is deployed, evolving those standards means writing custom scripts or manually updating thousands of objects. Each approach creates more opportunities for drift.

Infrahub Profiles eliminate drift by design, maintaining persistent connections between standards and infrastructure.

When a Profile is changed, those changes propagate to your infrastructure automatically—no scripts, no manual updates, no missed devices. Exceptions are documented and stay discoverable through audit trails and change management processes.

The result: infrastructure that matches documented standards, evolves cleanly as requirements change, and provides complete audit trails showing what changed, when, why, and who approved it. Less configuration drift means fewer issues.

Does this sound familiar?

Consider a common scenario: A team manages a data center with hundreds of network devices. They've designed standard configurations for DNS servers, NTP servers, and syslog targets for each region. Their initial spine-leaf design includes specific port allocations for uplinks and downlinks, and some ports are reserved as spares.

Six months later, capacity planning shows they need to activate those spare ports across the entire deployment. But things have changed, and those network standards they wrote six months ago are no longer valid.

In the meantime, exceptions have already been made to the standards as they previously existed. What comes next is a pile of error-prone manual updates, and exceptions to the templates that must be manually checked against earlier sets of exceptions and overrides. If something gets missed, a deployment could break spectacularly.

How traditional approaches to managing network standards fall short

Template-based approaches

such as Git + Ansible or Terraform

• What they do well: Initial deployment through templates and variables.
• The limitation: Templates are snapshots, not living standards. Updates require manually re-executing automation across all infrastructure
• The pain: You end up running through 20 different files to find and modify the template. You don't have a common place to see and maintain it. And there's no visibility into why a value has its specific configuration. Is it following the standard or does it need to be different? This lack of traceability makes troubleshooting and auditing extremely difficult.
• Result: On top of all the manual work to update the template, you end up with exceptions to standards captured in a dozen override files with no history, context, or reason why they exist.

Database frameworks

• What they do well: Track infrastructure state as structured, queryable data.
• The limitation: Once objects are created, the connection to their template is severed.
• The pain: Updating the build script has no effect on existing objects. You have to write custom bulk-update scripts repeatedly. What's more, standard data becomes centralized in ways that are hard for external systems to consume, limiting integration capabilities.
• Result: Network standards are static artifacts, not living governance.

Configuration context systems

• What they do well: Hierarchical configuration inheritance (global → regional → site).
• The limitation: Configuration contexts are essentially free-form JSON data structures that don't integrate well with existing data in the system. They're not easily queryable through APIs and lack the capability to understand inheritance models or track where specific values originated.
• The pain: Exception management becomes difficult because there's no easy way to identify where exceptions have been made or understand the reasoning behind them. You lose visibility into whether a configuration follows the standard or represents a necessary deviation.
• Result: Without proper metadata and traceability, it's a struggle to maintain governance as infrastructure scales .

The root of the problem is merging the physical and logical

At the core of the limitations found in these approaches is a conceptual problem. They merge two distinct concerns that should remain separate: the physical and the logical.

The physical layout represents the unchanging reality of the hardware, e.g., this switch model has 48 ports. The logical utilization covers how that hardware is being used, e.g., ports 1-24 are server-facing, 25-48 are uplinks, 45-48 are spare.

When the physical and logical are merged in a single template or device type, changing the logical design requires touching every physical instance. Templates can't distinguish between "this never changes" and "this evolves with our design."

The result is infrastructure design that's frozen at creation time and can't dynamically evolve.

Infrahub Profiles are living network standards

Infrahub Profiles solve the challenge of managing infrastructure and network standards at scale by maintaining a persistent, intelligent connection between standards and the objects that inherit from them. Profiles separate the static physical definition from the dynamic logical layer, allowing infrastructure designs to evolve throughout their entire lifecycle.

Here are four crucial ways in which Profiles are different from traditional approaches to managing network standards:

• Persistent lifecycle connection: This is the crucial difference. When an object is created using an Infrahub Profile, that relationship is maintained forever. If you change the Profile, the changes propagate automatically to all associated objects. Think of it like the relationship between a class and its instances in object-oriented programming. When you update the class definition, all instances reflect the change. But individual instances can still override specific methods when needed.
• Separation of physical and logical: Infrahub separates the physical, defined in templates, from the logical, defined in Profiles. This separation means you can use the same physical device template in different contexts (spine vs. leaf vs. access) by applying different Profiles. When a design evolves, you update the Profile, not thousands of individual objects.
• Implementation-agnostic data model: Profiles work at the schema level, not the rendered configuration level. For example, a network engineer defines DNS servers for US-East region once. Infrahub Transformations render the configs appropriately for IOS, NXOS, Junos, Linux—whatever the infrastructure uses. This flexibility is essential for modern multi-vendor environments. You shouldn't need three different "definitions" of the same logical standard just because they run on three different vendor platforms.
• Exception management as a first-class concept: Real-world infrastructure always has exceptions, such as a legacy system that needs a different DNS or a compliance zone with additional security requirements. Profiles make exceptions visible and governable. Example: You override a Profile value at the object level. The Infrahub UI clearly shows "this value overrides the Profile." The branch-based workflow requires documenting why the override was made. The approval workflow can enforce a review before the exception is accepted. At any later date, the business justification for each deviation is still visible.

These Profile features are what enable automation at scale. You define the settings that need to be applied, not to individual devices, but to the logical arrangement of those concepts. Your automation is no longer a widget by widget thing.

The alternative to Profiles isn't just a lot of work. It's also infrastructure that can't evolve gracefully. To maintain network standards at scale you need to separate what doesn't change (physical layout) from what evolves (logical design), and make standards persistent, exceptions visible, and evolution automatic. That's what Profiles deliver.

Infrahub Profiles make the difference between version 1.0 of your automation stack that doesn't scale, and battle-hardened automation that handles real-world complexity.

Working with Infrahub Profiles

Define your standards

Create a Profile for any object type in your schema. For a regional data center, a team might define:

• DNS servers: 10.1.1.1, 10.1.1.2
• NTP servers: 10.1.2.1, 10.1.2.2
• Syslog target: 10.1.3.1
• Default SNMP community settings

Apply the standards

The most common application method is to assign Profiles to object templates. When devices are created from that template, they automatically inherit the Profile's values. But you can also apply Profiles directly to existing objects, individually or in bulk.

Create a modular, hierarchical composition

Apply multiple Profiles to the same object with priority-based resolution:

• Global Profile (priority 100): Company-wide security settings
• Regional Profile (priority 200): US-East DNS, NTP, logging
• Site Profile (priority 300): Site-specific overrides

The highest priority Profile wins for any given attribute. This creates a natural organizational hierarchy without duplication.

Enjoy full visibility

Every attribute in the Infrahub UI shows its source. Examples:

• Inherited from Profile: US-East-DC-Standard
• Set by Template: Arista-7050-Spine
• Explicitly configured (overrides Profile)

When troubleshooting, you can immediately understand where a configuration came from and whether it's standard or an exception.

Integrate change management

Profile changes go through Infrahub's branch-based workflow:

1. Create a branch.
2. Modify the Profile.
3. Preview exactly which objects will be affected.
4. Submit for review.
5. After approval, merge. Changes propagate automatically.

This workflow enables a complete audit trail and preview before impact. There are no moments of, "Oops, I just changed 1,000 devices!"

Real-world use cases for Infrahub Profiles

• Standardizing regional infrastructure: Create a Profile for each region that defines DNS, NTP, syslog, and AAA servers, then assign it to device templates for that region. Every new device automatically inherits the regional standards. When it's time to migrate to new NTP infrastructure, updating a single Profile updates hundreds of devices, no scripting required.
• Evolving network designs: Consider an initial spine-leaf design that reserves ports 45-48 on each leaf switch as spares. When network growth requires activating those ports, simply update the interface Profile from spare to server-facing. The change propagates across the entire deployment without custom scripts or manual updates.
• Managing interface standards: Create role-based Profiles for different interface types. Example: Server-Port-Standard with 802.1X, port-security, and specific VLANs; User-Port-Standard with different authentication settings; and Uplink-Port-Standard for inter-switch links. When enabling 802.1X across a wired network, updating the Profiles updates thousands of ports automatically.
• Compliance and audit: When auditors need proof of when security settings were applied and by whom, Profiles, combined with Infrahub's change management, provide complete audit trails. You can generate reports showing which devices follow standards, which have documented exceptions, and the approval history for each deviation—turning weeks of audit preparation into hours.

What's ahead for Infrahub Profiles

The current implementation requires manual Profile assignment. We're actively developing capabilities for automatic Profile application based on object characteristics. For example:

• Auto-apply Profiles when a device is assigned to a specific region
• Auto-apply interface Profiles when an interface role changes
• Bulk Profile application to existing objects matching specific criteria

These enhancements will enable even more powerful workflows, where you can define standards once and let Infrahub ensure they're applied consistently as your infrastructure grows and changes.

Ready to get started with Infrahub Profiles?

To get a quick feel for how Profiles work, think about your most common configuration patterns—those DNS servers, NTP settings, or interface configurations that are repeated across dozens or hundreds of objects.

Pick one of those common standards and define a Profile for it in Infrahub. Next, apply that Profile to existing infrastructure objects.

Congratulations! You're now managing that pattern as a standard instead of individual configurations.

To dig deeper:

• Dive into the Profiles documentation
• Download the free Community edition of Infrahub and build some Profiles
• Request a demo for a personalized review of how Profiles can help your team manage network standards at scale