Running Infrahub at scale means more network data, more automation, more linked repositories, and more engineers making changes at the same time.
As repositories, schemas, and datasets grow, the processing that follows a change—regenerating configurations and documentation, recomputing derived values, or validating a Proposed Change—should stay tied as closely as possible to what actually changed.
With Infrahub 1.11, when you merge a branch, update the schema, or commit to a linked repository, regeneration, recomputation, and validation are more targeted to the definitions and data affected by the change.
Where Infrahub can determine exactly which definitions and data a change affects, it re-runs only that work. Where it can’t, it regenerates a broader set so no artifact or derived value is left out of date.
Your team can also keep working while background processing continues. Active change operations are dispatched ahead of lower-priority tasks, so creating branches, reviewing Proposed Changes, and generating artifacts no longer has to wait behind every background task already in the queue.
Infrahub 1.11 also gives your team more visibility and recovery options when something goes wrong. You can inspect what each webhook delivery sent, what came back, and why it failed—then retry it after correcting the configuration. And you can roll back an interrupted merge so the branch and its Proposed Change return to a reviewable state.
Large inventories are also easier to work with. Object and IPAM lists sort and filter on the server, and each user chooses how dates and times are displayed.
Changes trigger only the processing they require
Most changes a network team makes have a clear boundary. A branch might add a rack to one site, update a service definition, correct a set of interface descriptions, or change one Generator in a repository shared across the automation team.
Previously, the processing triggered after a merge or repository update was generally broader than the change itself. Merging a branch re-ran every Generator and regenerated every artifact for its members.
A commit to a linked repository could recompute every Transformation-based computed attribute in the instance, for every object of its kind. Schema constraint validation could also run across parts of the schema that the change had not touched.
With 1.11, regeneration, recomputation, and constraint validation are limited to only the definitions and data that the change could affect.
- When you merge a branch or Proposed Change, artifact and Generator definitions are regenerated only when their inputs changed, and processing is limited to the objects touched by the change. Across the scenarios used to validate this work, the number of regeneration tasks created after a merge fell by between 73% and 100%.
- After a schema update, recomputation is limited to attributes whose dependencies could have been affected. How narrow that recomputation can be depends on the type of Transformation:
- Jinja2 Transformations: The template shows which values the attribute reads, so only the objects affected by the change are recomputed.
- Python Transformations: Infrahub can’t yet identify which objects read the changed data, so every object of that kind is recomputed. Narrowing this scope is the next step for our work in this area.
- During Proposed Change checks, merges, and rebases, constraint validation is limited to the kinds and fields involved in the change.
When a dependency can’t be determined precisely, processing falls back to a broader scope so the resulting artifacts and derived values remain current.
Some changes are intentionally broad. Updating a device type, naming convention, or computed description may affect thousands of objects. In those cases, Infrahub recomputes the affected objects in batches instead of creating a separate background task for each one, and skips any value that didn’t change.
On the reference dataset used during development, a large post-merge recomputation went from about 1,500 background tasks to two, and from about 275 seconds to about one second. Results will vary with the dataset, schema, and automation definitions in each environment.
Your team can get the configurations, documentation, and derived values associated with a routine change without waiting behind processing for unrelated data. As repositories, schemas, and datasets grow, the processing triggered by a change stays more closely tied to its actual scope.
Re-run only affected automation after a linked repository update
Changes to automation in a linked Git repository can also trigger regeneration and recomputation. Generators, Transformations, and the GraphQL queries they use typically live together in a repository shared by an automation team. Previously any commit to that repository could re-run every Generator across its targets and recompute every computed attribute produced by a Transformation, whether the commit concerned them or not.
In Infrahub 1.11, a Generator or Transformation is re-run only when something it depends on actually changed: its source file, its GraphQL query, its definition, or a declared dependency. An edit followed by its exact revert triggers no work at all.
Within a Proposed Change, each decision to run or skip is recorded in the task log, naming the file, query, or definition field responsible, so a reviewer can see why a Generator ran without tracing the repository themselves.
Infrahub detects one dependency on its own: the file named by an entry’s file_path. Most Python Transformations and Generators read more than that, such as a helper module beside them or a shared package elsewhere in the repository. Those are declared with the watch key in .infrahub.yml, and naming a directory covers every file beneath it.
python_transforms: - name: cabling_plan class_name: CablingPlan file_path: "transforms/cabling_plan.py" watch: files: - transforms/ # directory entries are recursive - shared/naming.py
Declaring watch is not required to keep outputs current. A Python Transformation or Generator without watch continues to re-run after every commit to its repository.
Adding watch allows that processing to be limited to commits that affect the declared dependencies, so a README fix or a change to another team’s Generator in the same repository no longer re-runs yours. Jinja2 Transformations need no declaration.
If you maintain Python Transformations or Generators, add watch to their entries as part of moving to 1.11, so they re-run only when a commit affects them. See Declaring extra dependencies with watch for the full syntax.
Keep active work moving during background processing
After a merge, artifact generation, computed-attribute recomputation, IPAM reconciliation, profile refreshes, and other followup, processing may continue in the background.
On a large instance, some of that work can take time. Previously, active operations and background tasks shared a single queue and were dispatched in the same order regardless of whether anyone was waiting on them.
Infrahub 1.11 introduces three task-priority lanes. Operations that engineers are actively waiting on are dispatched at high priority, including:
- branch creation, merges, rebases, deletion, and validation
- Proposed Change merges
- schema operations
- Generator definition runs and Transformation rendering
- on-demand artifact generation
Tasks created as part of those operations keep the same priority through completion.
API requests can also carry a priority. The web interface marks interactive requests as high priority and background traffic as low priority. Under sustained load, lower-priority requests are asked to retry before they consume API and database capacity.
In our own testing on one of our reference data center solutions, an engineer could create a branch, make a change, open a Proposed Change, and merge it while a full generation chain was still running.
Those operations continue while the instance is working rather than waiting for it to go quiet. They take longer on a busy instance than on an idle one. How much longer depends on the capacity available alongside the background work.
Priority determines the order in which work is dispatched; it doesn’t add processing capacity. If an instance’s workers are already saturated, available worker capacity still determines how quickly tasks can complete. Scaling out task workers therefore remains the way to increase that capacity, and results will vary depending on the background load of each instance.
Infrahub 1.11 adds the priority lanes, the classification of operations, and priority-aware API admission. Work on this continues in 1.12, including measuring how large instances behave under heavy load.
Find and retry failed webhook deliveries
When you connect Infrahub to a deployment pipeline, ticketing system, monitoring platform, or another downstream system, troubleshooting usually starts with a few questions: Did the webhook fire? What was sent? What came back? Why did it fail?
Every webhook delivery is now recorded as its own task. You can inspect:
- the request URL and headers
- the response status and body
- how long the target took to respond
- the reason a delivery failed
Credentials and other sensitive header values are masked in the recorded request.
Expected failures such as an unreachable target, TLS problem, timeout, HTTP error, or configuration issue are reported with a readable reason and remediation guidance rather than leaving the cause buried in a traceback.
Failed deliveries are retried automatically up to three times, two minutes apart. If the problem requires a configuration change, such as correcting a URL, header, or signing key, you can update the webhook and retry the original delivery.
The retry uses the payload captured when the event first fired and the current webhook configuration, while the original attempt remains available for reference.
Your team now has a direct record of what was sent and what happened next, so a failed integration can be investigated and retried from the original event.
Recover interrupted merges without rebuilding the change
A merge can be interrupted if the worker processing it stops before completion.
While a merge is running, writes to both the source and default branches are blocked so the merge can complete against a stable state. If the worker stops partway through, the branch is marked as failed and the default branch remains protected from further writes until the merge is recovered.
The new infrahub recover merge command rolls back the partial merge and returns the source branch and any associated Proposed Change to an open, reviewable state. Timestamps on affected objects, attributes, and relationships are restored to their pre-merge values.
Once the underlying problem is resolved, your team can put the same branch through validation and review again. Recovering from an interrupted merge no longer requires restoring the entire instance from backup or manually reconstructing the change.
Navigate large inventories more easily
Object and IPAM lists can now be sorted and filtered from the UI, with sorting performed on the server across the complete result set rather than only the current page.
You can sort by multiple fields, set their precedence, filter from a column, and sort by supported attributes on a related object when a column references a single related object. For example, you can sort devices first by site and then by role, or organize prefixes by namespace while reviewing address capacity.
The selected sort is stored in the URL, so the resulting view can be bookmarked or shared.
Users can also choose their preferred date format and timezone, while administrators can set organization-wide defaults. Personal preferences follow the user anywhere they sign in with the same account.
Other UI improvements include:
- sorting Proposed Changes, with the newest created appearing first by default
- clearer branch context and one-click branch switching
- current values appearing immediately after records are created, edited, or deleted
- more specific labels for hierarchical relationships
- parent fields pre-filled when adding a child from a hierarchical object
- Mermaid diagrams rendered in Markdown artifacts
Across the Infrahub ecosystem
Three related tools released in the same cycle make it easier to get started with Infrahub and operate it in production:
- Infrahub Marketplace: Start from a curated catalog of schemas and collections for networks, data centers, and cloud environments. Collections contain schemas tested to load together, so you can begin with an existing model and adapt it to your own network.
- Infrahub Collect: Gather the logs, diagnostics, and configuration needed for a support case from Docker Compose or Kubernetes deployments into a single archive. The tool is read-only, can run against a degraded production instance without stopping or restarting containers, masks values identified as credentials, and records what it was able to collect.
- Infrahub Backup 2.3.0: Remove old backups automatically according to a retention policy, restore the latest backup without specifying its name, and update the tool in place, reducing the manual steps required for scheduled backup and recovery.
Before you upgrade
Infrahub 1.11 includes several breaking changes and upgrade considerations. Review the full release notes before upgrading.
Get Infrahub 1.11
Infrahub 1.11 reduces the regeneration, recomputation, and validation created around routine changes while giving your team more control when integrations or merges fail.
Read the full release notes for the complete changelog, upgrade steps, known limitations, and configuration details.
