Does this replace Arista AVD?

No. AVD still generates the configuration — PyAVD runs inside Infrahub and renders the EOS CLI. What changes is where the data behind it lives: modeled in Infrahub rather than maintained as per-device files.

Is Ansible still required?

Not for generation. PyAVD runs directly in Infrahub’s workers. Deployment runs through the bundled Ansible runner or through CloudVision, whichever fits your environment.

Do we still write host_vars by hand?

No. The generators assemble each device’s PyAVD inputs from the fabric model, so the inputs are produced from the design rather than maintained separately.

Can we onboard an existing fabric?

Modeling an existing fabric and importing its configuration is done today through a guided engagement rather than a self-serve path. Talk to the team about what that involves.

The reference design covers Arista through AVD. Model non-Arista equipment in the same source of truth alongside it. For a design that spans Cisco, Arista, and Dell, see the AI data center reference design.

Does it cover every AVD feature?

No. This is a reference design covering a defined set of AVD capabilities. Read the supported capabilities before planning a deployment.

INFRAHUB + ARISTA AVD INTEGRATION

Standardize your design with Infrahub and generate with AVD

Infrahub is the design layer and source of truth for teams running Arista AVD. Build data center fabrics from one design and generate the AVD inputs for every device.

Explore the Arista AVD Reference Design →

Manage the design AVD implements

Capture the architecture, standards, and engineering rules and reuse them across fabrics, racks, sites, and data centers.

Model the fabric with the infrastructure it supports

Relate switches and interfaces to compute, GPU clusters, storage, security, Kubernetes, circuits, and services.

Review design changes before they become configuration

Change the design data on a branch, see what will change, and approve it before AVD produces the EOS configuration.

DESIGN STANDARDS

Standardize the design, then adapt it site by site

Every new fabric needs its own set of AVD inputs. Define the architecture and design standards once, then generate those inputs for every fabric and device.

Generate a new fabric’s inputs from the design: Model the hardware and the fabric pattern once, then generate each device’s interface assignments, topology, and routing conventions.
Engineers work at the site level: Specify the site, rack, capacity, or service requirements and generate the rest from the established design.
Concurrent changes stay coordinated: Prefixes, addresses, VLAN IDs, and ASNs come from managed pools so two changes in flight don’t take the same resource.

CONNECTED INFRASTRUCTURE

Manage the Arista fabric in the context of the data center

Model the fabric alongside the compute, GPU clusters, storage, firewalls, load balancers, Kubernetes, circuits, and services it connects.

Deliver a new GPU rack as one coordinated change: Leaf connectivity, server connections, addressing, VLANs, cluster relationships, and services move together.
Answer dependency questions directly: Which servers connect to this leaf, which services depend on this link, which racks use this address pool.
Other teams work from the same relationships: Compute, platform, and operations read the same model the AVD inputs are generated from.

Read the Infrahub + Arista AVD documentation →

CHANGE CONTROL AND GOVERNANCE

Review changes before they become configuration

Engineers change the design data on isolated branches and submit Proposed Changes. Reviewers see topology, addressing, allocations, relationships, generated artifacts, and validation results before approval.

Catch mistakes in the design: Review moves earlier in the workflow, before AVD produces the configuration.
Other teams request what they need: Platform, compute, storage, and application teams ask for connectivity, addressing, or VLANs through interfaces and APIs, and each request becomes a Proposed Change.
Network engineering keeps the standards: The network team sets the design standards, validation rules, resource policies, and approval requirements.

HOW IT FITS

Add a design and source-of-truth layer to your existing AVD workflow

Infrahub
Serves as the network design, data, and change process

Arista AVD / PyAVD
Generates the EOS configuration from the AVD inputs

ANTA
Validates the network

CloudVision
Delivers the configuration and monitors the Arista network

Arista EOS
Runs the fabric

Teams already running AVD adopt the integration incrementally by moving selected data into Infrahub and generating the AVD inputs from it. The existing PyAVD, ANTA, Git, CI, and CloudVision workflows stay in place.

ARISTA AVD REFERENCE DESIGN

Start from a working blueprint

What you get

The Infrahub + Arista AVD reference design is a working blueprint for operating AVD from a modeled network design.

A complete working build: You get the Arista data model, the Generators, and the PyAVD integration that render the EOS configuration.
Ready to run and adapt: Clone it, read the code, and shape it to your design and standards.
A reference implementation: It covers a defined set of AVD capabilities. It's not a certified network design.

Get it on GitHub

Read the docs

See it in action

Everything shown in the demo ships as a loadable reference design you can use as‑is or fork to fit your environment.

FAQ

Where AVD ends and Infrahub begins

How does the integration compare to using AVD alone?

AVD still generates the configuration, with PyAVD rendering the EOS CLI. What changes is where the data behind it lives. The data is modeled in Infrahub, with the AVD inputs derived from that design, rather than maintained as per-device files.

How does the integration compare to CloudVision?

It sits before it. CloudVision delivers the configuration and monitors the Arista network, and Infrahub holds the design the configuration is generated from. Teams running CloudVision keep running it.

How does the integration compare to running AVD from YAML and Git?

The design is modeled as structured data instead of maintained as YAML files, so each device’s AVD inputs are derived from it rather than edited by hand. Git, CI, and the existing PyAVD workflow stay in place.

How does an existing AVD deployment adopt this incrementally?

You move selected data into Infrahub, generate the AVD inputs from it, and leave the existing PyAVD, ANTA, Git, CI, and CloudVision workflows as they are.

Get started  your way →

Infrahub Community

Open source and forever free. All the schema flexibility and Git-style version control you need to explore at your own pace.

Download on GitHub →

Infrahub Enterprise

Built for scale, complexity, and production reliability: HA, advanced integrations, and SLA-backed support.

Request a demo →