---
title: "How Ansible® Automation Powers the Uber Corporate Network at a Global Scale"
description: "Uber’s corporate network spans offices across six continents and around 5,000 devices, creating a configuration-management problem involving continuous updates, regional variation, and hardware from multiple vendors. The post explains why Uber uses Ansible for on-premises network configuration while Terraform handles cloud provisioning and Puppet manages configuration on running machines. Its Daily Nightly Enforcement workflow backs up each region’s running configuration to a private GitHub repository, gathers device facts, renders vendor-specific golden configurations through inventory variables and Jinja templates, and pushes them overnight, with failures triggering alerts. Inventory groups encode desired state across regions, functions, and operating systems, while custom roles, formatters, cleanup jobs, and occasional Ansible or Python modules address scale and vendor-specific gaps. The conclusion says this automation makes the diverse network manageable, stable, updated, and ready for daily use, although some hardware still requires other portals."
---

# How Ansible® Automation Powers the Uber Corporate Network at a Global Scale

[Uber](https://yomu.fyi/company/uber) · Apr 30, 2026

**Type:** Explainer

## Summary

Uber’s corporate network spans offices across six continents and around 5,000 devices, creating a configuration-management problem involving continuous updates, regional variation, and hardware from multiple vendors. The post explains why Uber uses Ansible for on-premises network configuration while Terraform handles cloud provisioning and Puppet manages configuration on running machines. Its Daily Nightly Enforcement workflow backs up each region’s running configuration to a private GitHub repository, gathers device facts, renders vendor-specific golden configurations through inventory variables and Jinja templates, and pushes them overnight, with failures triggering alerts. Inventory groups encode desired state across regions, functions, and operating systems, while custom roles, formatters, cleanup jobs, and occasional Ansible or Python modules address scale and vendor-specific gaps. The conclusion says this automation makes the diverse network manageable, stable, updated, and ready for daily use, although some hardware still requires other portals.

## Context

The post focuses on configuration management for Uber’s on-premises corporate network hardware. It distinguishes this work from cloud provisioning with Terraform and describes Ansible’s role across regional offices, diverse vendors, operating systems, and device types.

## Approach / What changed

Uber registers network hosts in Ansible inventory groups organized by region, function, and operating system. Daily Nightly Enforcement runs playbooks that back up running configurations to GitHub, gather facts, render golden configurations through Jinja templates, mask and format sensitive output, and push the results to devices. Failures stop enforcement for the affected device and trigger alerts; custom Ansible and Python modules cover gaps in public collections.

## Takeaways

- Ansible inventory variables represent the desired network state independently of vendor syntax, then Jinja templates render configurations for specific operating systems and hardware.
- Daily Nightly Enforcement backs up configurations before changes, stores configuration history in GitHub, generates golden configurations every 24 hours, and applies them overnight.
- Multi-vendor automation requires planned architecture, formatting and repository cleanup, and sometimes custom Ansible or Python modules; some hardware still requires other network portals.

## FAQ

### What happens to manual network changes that are not recorded in the inventory?

They are overwritten during the overnight enforcement process. Uber treats untracked manual adjustments as technical debt, using the desired inventory state to restore consistency and maintain a versioned record.

### How does Uber adapt one automation system to different network vendors?

Inventory variables are kept network-agnostic and translated into vendor-specific syntax through separate Jinja templates. When public collections or templates are insufficient, Uber develops custom Ansible or Python modules, while some vendors require coordination with other portals.

### What happens when a backup or generated configuration fails?

Enforcement stops for that device when an error occurs in the backup or golden-configuration generation steps. The workflow also sends an alert to an external system.

**Tags:** [Ansible](https://yomu.fyi/topic/ansible), [Configuration Management](https://yomu.fyi/topic/configuration-management), [Jinja](https://yomu.fyi/topic/jinja)

- Source: [Uber](https://www.uber.com/us/en/blog/ansible-automation-powers)
- Source URL: https://www.uber.com/us/en/blog/ansible-automation-powers
- Ingested by Yomu: 2026-09-17T04:00:56.238Z

[Read original post](https://www.uber.com/us/en/blog/ansible-automation-powers)