Case Study: Building an Enterprise Infrastructure Management Platform

Timeline: October 2025 – February 2026 | Role: Architect, Engineer, Project Lead | Environment: 5-node cluster, 56 devices, 15 VMs

---

Executive Summary

When I set out to evaluate how emerging technology could improve IT operations, I didn’t write a whitepaper. I built a complete enterprise-grade environment from scratch, designed an infrastructure management platform with 8 custom API servers exposing 336 tools, and measured every session to prove the business case. The result: a 7-10x productivity multiplier across 48 tracked sessions, with peak sessions exceeding 15x for multi-system coordination tasks , all running on a $240/year open-source stack that replaces $75K-$109K in commercial equivalents.

This case study documents the strategic thinking, technical architecture, and measured outcomes of building an enterprise infrastructure management platform.

The Challenge

Enterprise IT organizations face a convergence of pressures in 2026: shrinking teams, expanding infrastructure complexity, and a technology market flooded with vendor promises but short on operational proof. The fundamental question isn’t whether automation can help , it’s how to design an operations strategy that delivers measurable, repeatable results.

The specific challenges I set out to solve:

• Multi-system coordination overhead: Routine operations like deploying a server touch 5-6 different platforms (virtualization, IPAM, monitoring, documentation, logging, firewall). Each context switch costs time and introduces error risk.
• Documentation drift: Infrastructure documentation falls out of sync with reality within days of being written. Manual updates can’t keep pace with operational changes.
• Tribal knowledge dependency: Each platform requires domain expertise. Cross-system operations require either a generalist who knows every API or a coordination effort between specialists.
• Tool sprawl without integration: Modern infrastructure runs on dozens of best-of-breed tools that don’t natively communicate. Custom integration code is expensive to build and maintain.
• No way to measure operational value: The industry talks about productivity, but almost no one measures it rigorously in infrastructure operations.

Strategic Approach

Rather than adopting a vendor platform, I took an architecture-first approach: build the infrastructure foundation that makes automation effective, then measure the results.

Three design principles guided every decision:

1. API-First Everything

Every system in the stack was selected for its API quality. If a platform doesn’t expose its functionality programmatically, it becomes a bottleneck , both for human automation and for any AI-augmented operations you add later. This meant choosing NetBox over spreadsheets for IPAM, Naemon over GUI-only monitoring tools, and Loki over solutions that lock data behind proprietary interfaces.

2. Single Source of Truth

NetBox serves as the authoritative CMDB. Monitoring configuration is derived from NetBox data. Documentation references NetBox records. When the platform needs to know what’s in the environment, it queries one system , not five. This eliminates the configuration drift that plagues most operations teams.

3. Measure Everything

Every working session was logged with structured efficiency metrics: actual time, estimated manual equivalent, productivity multiplier, and task category. This isn’t anecdotal , it’s 48 data points over four months with consistent methodology.

Solution Architecture

The platform has three layers: infrastructure services, an API integration layer, and operational governance.

Infrastructure Layer

A 5-node Proxmox cluster provides the compute foundation: 40 cores, 320GB RAM, and 10TB NVMe across five Simply NUC Ruby 2 nodes. This runs 15 virtual machines hosting the complete operations stack:

• NetBox , IPAM/DCIM and single source of truth (56 devices, 15 VMs)
• Naemon + Thruk , Network and service monitoring (65 monitored hosts, 102 service checks)
• Grafana + Loki , Centralized logging (13 hosts, 8 dashboards, 30-day retention)
• Ansible , Configuration management (16 managed hosts)
• MediaWiki , Operational documentation (50+ pages, structured SOPs)
• Vaultwarden , Credential management (18 secrets, API token storage)
• pfSense , Firewall and network segmentation (pre-cutover, VLAN-ready)
• WordPress , External portfolio and content platform

API Integration Layer: 8 Custom API Servers, 336 Tools

The Model Context Protocol (MCP) is a standardized interface between operations tools and external systems. I built eight custom API servers , each one wrapping a platform API into discoverable, schema-validated tools accessible through natural language or programmatic requests:

API Server	Tools	Capabilities
NetBox	80	Complete IPAM/DCIM: devices, IPs, VLANs, interfaces, prefixes, custom fields, configuration contexts
pfSense	51	Firewall rules, NAT, VPN, DHCP/DNS, interfaces, gateways, routing
UniFi	50	Network devices, clients, WLANs, port profiles, DPI, firewall rules
MediaWiki	45	Page CRUD, categories, templates, search, project/task tracking
Proxmox	40	VM lifecycle, containers, snapshots, cluster resources, storage, tasks
WordPress	31	Posts, pages, media, comments, taxonomy, plugins, themes, settings
SSH Gateway	30	Remote execution, file ops, Docker management, systemd, system monitoring
Vaultwarden	9	Credential retrieval, API tokens, SSH keys, folder management

Every API server follows the same pure-Python pattern: no external dependencies, JSON schema validation on all inputs, authenticated via Vaultwarden-managed credentials, and communicating over stdio (no network exposure). The platform discovers available tools dynamically , it doesn’t need pre-configuration for specific infrastructure.

Operational Governance Layer

Automation without governance is a liability. The platform includes:

• 8 Standard Operating Procedures covering documentation creation, project management, session logging, and hardware library management
• Structured efficiency tracking with monthly archives, automated metrics templates, and a dynamic summary dashboard
• Credential isolation , no hardcoded secrets. All authentication flows through the Vaultwarden API server with audit-logged access
• Documentation-as-code , wiki pages serve as both human reference and operational context, with templates ensuring consistency

Implementation Highlights

NetBox-to-Naemon Automation Pipeline

One of the most impactful integrations: monitoring configuration derived entirely from the CMDB. Six custom fields in NetBox (mon_enabled, mon_check_type, mon_hostgroup, mon_criticality, mon_check_interval, mon_parent) control what gets monitored and how. When I toggle a checkbox in NetBox and click Save, a webhook triggers Ansible, which queries the NetBox API, renders Jinja2 templates into valid Naemon configuration, validates syntax, and reloads the monitoring daemon. End-to-end latency: 5-10 seconds. Manual steps: zero.

Before this pipeline, adding a device to monitoring required 7 steps across 3 systems and 10 minutes of work. Now it’s automatic. 65 hosts and 102 service checks are managed entirely through NetBox , no one touches Naemon config files.

Multi-System Orchestration

The highest productivity multipliers come from operations that span multiple systems. Deploying a new monitoring server , which traditionally requires 12 manual steps across 5 web interfaces , becomes a single request. The platform orchestrates the sequence: clone the VM in Proxmox, register it in NetBox with correct IP and role, configure monitoring via the automation pipeline, create documentation in MediaWiki, set up logging agents via SSH, and update firewall rules in pfSense.

This isn’t theoretical. It’s how I actually operate the environment. The platform has authenticated, validated access to every system through the API layer, and it handles the coordination that would otherwise require an engineer to context-switch between platforms.

Centralized Logging in One Day

Deploying Grafana Loki across 13 hosts with 8 custom dashboards , a project that would typically take a team several days , was completed in a single working session. The platform created the VM, deployed Docker containers, wrote Ansible roles for Promtail deployment, configured the Docker Loki log driver on container hosts, and built all 8 Grafana dashboards. Total cost: $0 in software licensing, replacing $15K-$50K/year in Splunk equivalent capability.

Measured Results

Every session was tracked with structured efficiency logging. After 48 sessions over four months:

Metric	Value
Total Platform Hours	90.65 hours
Estimated Manual Equivalent (Low)	605 hours
Estimated Manual Equivalent (High)	873 hours
Average Productivity Multiplier	7-10x
Peak Session Multiplier	15x+ (multi-system coordination)
Total Sessions Tracked	48
Annual Software Cost	$240 (API platform licensing)
Commercial Software Equivalent	$75,000 – $109,000/year

These aren’t projections or vendor benchmarks. They’re measured outcomes from actual infrastructure operations, logged session by session with time, manual estimates, and multiplier calculations.

Productivity by Category

The highest multipliers consistently appeared in three categories:

• Multi-system coordination (10-15x): Operations touching 3+ platforms where the platform handles all API calls and sequencing
• Documentation creation (6-8x): Structured wiki pages, SOPs, and architecture documents generated from actual system state
• Troubleshooting and diagnostics (8-12x): Correlating data across monitoring, logging, and configuration systems to identify root causes

Lower multipliers (2-4x) appeared for simple, single-system configuration changes , tasks where the overhead of describing the change is close to the time of making it manually. This is expected and honest. Automation doesn’t accelerate everything equally.

Business Impact

Beyond the raw productivity numbers, this project demonstrates several principles relevant to enterprise IT leadership:

• Technology readiness is an infrastructure problem. The platform is only as capable as its tooling. Organizations that invest in API-first architecture and structured data systems will be positioned to adopt automation , including AI. Those running on spreadsheets and manual processes won’t.
• Small teams can operate like large ones. A single engineer with the right platform can manage infrastructure that would traditionally require a 3-5 person team. This has direct implications for IT staffing models and operational costs.
• Governance enables speed. SOPs, naming standards, and structured documentation aren’t overhead , they’re what make automated operations reliable and auditable. Better operational discipline leads to better outcomes.
• Open source eliminates vendor lock-in risk. Every component in this stack can be replaced independently. The API integration layer is the differentiator, not any individual platform. This is a strategic architecture choice, not a cost optimization.

Key Takeaways

1. Start with the infrastructure, not the automation. Build API-first systems with a single source of truth before adding AI or automation capabilities. The integration layer is relatively straightforward once the foundation is solid.
2. Measure relentlessly. Without structured efficiency tracking, technology adoption becomes a faith-based initiative. With data, it becomes a business case.
3. The multiplier comes from composition. Individual API calls aren’t impressive. Chaining 15 API calls across 6 systems in the right sequence to complete a complex operation in 30 seconds , that’s where API-first automation delivers transformative value.
4. Security is a design constraint, not an afterthought. Centralized credential management, audit logging, and no-hardcoded-secrets discipline are prerequisites for giving automated systems operational access.
5. This is a leadership capability. The executives who understand how to design technology strategies, measure outcomes, and govern automated operations will lead the next wave of IT transformation.

Technologies Used

---

This case study documents a real, operational system , not a proof of concept or demo environment. The infrastructure runs 24/7, manages production workloads, and is the platform I use daily for infrastructure operations. All metrics are from actual tracked sessions with consistent methodology.

Interested in the technical details behind any component? Check out the Technology Lab for the full architecture, or explore the blog for deep dives into specific implementations.