There's a moment every infrastructure administrator knows well. You're sitting in a meeting, someone asks what should be a simple question, and the room goes quiet. Not because nobody cares — but because the answer lives in three different systems, two people's heads, and a spreadsheet nobody has touched in eight months.
My moment came when a senior stakeholder asked how many domains our organization owned.
Nobody knew.
Not approximately. Not even in the right ballpark. The actual answer, as I would eventually discover after several days of research across two domain registrars, a DNS server, an email thread, and a conversation with a colleague who holds most of the institutional knowledge about our certificate renewals — was dozens. More than fifty. Fewer than a hundred. Spread across two registrars. Some active. Some parked for brand protection. Some with auto-renew mysteriously turned off. A few already expired. And until recently, no single place where you could see all of them at once.
That meeting was the moment I decided to build something.
The Problem Every Administrator Recognizes
If you work in IT infrastructure — whether you're three years in or thirty — you know the feeling of flying blind. Not because you're incompetent. Because the tools that should exist either cost a fortune, require a six-month implementation project, or are designed for enterprises with dedicated operations teams and vendor relationships you don't have.
What most administrators actually have is this: a virtualization environment, some cloud subscriptions, a handful of registrar accounts, a monitoring platform that's 60% configured, and the accumulated tribal knowledge of whoever has been around the longest.
When that person is out sick, or leaves, or simply isn't in the room when the question gets asked — the organization discovers, sometimes painfully, just how much it didn't know about itself.
I've been in infrastructure for over thirty years. I've watched this pattern repeat at organizations of every size. And I've always believed that the right tool, built thoughtfully, could change it.
So I built one.
The Organization
The environment I work in is a public insurance authority — a state-managed entity that provides residential earthquake coverage through a network of participating insurers. It's a mid-sized organization with a footprint that reflects years of organic growth: on-premise virtualization, multiple cloud subscriptions, a portfolio of public-facing domains representing various programs and brand protection efforts, and a core policy and claims platform that sits at the center of everything the business does.
Like most organizations of its kind, it had grown faster than its documentation. The infrastructure was solid. The visibility into that infrastructure was not.
What We Built — and What It Took
The Infrastructure Intelligence Portal is a self-hosted web application that gives any member of the infrastructure team — or any stakeholder with access — a live, plain-English view of the organization's entire technology footprint.
At the time of this writing it tracks:
- Several hundred servers — a mix of on-premise virtual machines and cloud instances across multiple subscriptions
- Dozens of domains across two registrars, with expiration dates, auto-renew status, annual costs, and ownership contacts
- SSL certificate expiration monitoring with urgency flags
- A Gap Punch List that surfaces every server missing an owner, a department, or other critical metadata
- A temperature widget pulling live data from a physical sensor in the server room
- Server-level detail cards showing resource usage, network connectivity, jumpbox routing, and a plain-English biography of each machine
It runs on a single Python process. It cost nothing to build beyond time. And it looks, if I may say so, genuinely professional.
Here's how we got there.
The Technology Stack — No Magic, Just Craft
Python — The Backbone
The portal is served by a custom Python HTTP server with a hardened wrapper to survive the security scanners that kept taking it down by hammering the port. The server exposes a set of API endpoints that the frontend calls on load and on demand. Python handles data merging, gap analysis, biography generation, temperature proxying, and JSON serving. No framework. No dependencies beyond the standard library and a few well-chosen packages. Deployable on any machine with Python installed.
PowerShell + PowerCLI — On-Premise Inventory
The on-premise collector is a PowerShell script using VMware's PowerCLI module. It connects to the virtualization management platform, iterates every virtual machine, and extracts everything useful: name, power state, guest OS, CPU, memory, disk, network adapters, IP addresses, custom attributes, tags, and cluster placement. The key insight here was using the platform's custom attributes and tags as the metadata layer. Owner, Department, Environment, Notes — all stored in the virtualization platform, all pulled into the portal on each collection run. This means the portal reflects reality as soon as you update the source, with no intermediate database to maintain. The collector also filters out internal system VMs that the platform creates automatically — those cluster service agents that clutter every inventory and can't be tagged. One line of PowerShell eliminates the noise entirely.
Cloud PowerShell Modules — Cloud Inventory
The cloud collector uses Azure PowerShell modules to iterate virtual machines across multiple subscriptions. The organization runs several cloud subscriptions — development, QA, production, infrastructure — and each gets collected independently into its own subfolder, then merged by a Python script into a single unified inventory. The multi-subscription merge was one of those problems that seems trivial until it isn't. The solution was disciplined: each collection run outputs to a named subfolder, and the merger reads all subfolders, deduplicates by machine name and subscription ID, and produces a single clean JSON. Timestamps are shown for each subfolder so stale collections are immediately visible. Cloud tags — Owner, Department, Environment — flow through exactly the same way as on-premise custom attributes. One metadata model, two platforms.
JSON — The Glue
The portal is driven entirely by JSON files: server inventory, VLAN definitions, jumpbox routing rules, domain and certificate data, and physical host management addresses. No database. No ORM. No migration scripts. JSON files that any text editor can open, any Python script can process, and any administrator can understand.
HTML, CSS, JavaScript — The Interface
The portal UI is a single HTML file. No React, no Vue, no build pipeline. Just well-crafted vanilla JavaScript, CSS custom properties, and an open-source icon library. The design went through several iterations. The first version was warm and approachable — cream backgrounds, friendly typography, plain-English labels. It worked. But as the portal matured and began to carry real operational weight, it felt too casual for what it had become. The current theme is a deep slate dark mode — dark backgrounds, gold amber accents, soft white text — modeled on the aesthetic of professional infrastructure tools like Grafana and Datadog. It looks like a tool a well-funded engineering team built. It was built by one administrator with time, curiosity, and a clear problem to solve.
Domain Registrars — Domain Intelligence
Domain management was the last frontier, and in some ways the most revealing. By exporting the domain lists from both registrars and writing a Python parser to merge them into a single structured data file, the portal now surfaces the complete domain portfolio in one view. The combined export contained dozens of domains — far more than anyone on the team had realized. Several had auto-renew turned off with expiration dates approaching. One had already lapsed into an expired state. None of this was visible anywhere before. Now it's all in one place, color-coded by urgency, with the right contacts documented for each domain and certificate.
The Lessons That Generalize
This project was built for a specific organization, but the lessons belong to every administrator who has ever stared at a ticket queue and thought there has to be a better way.
What Comes Next
The portal is not finished. It never will be, and that's appropriate — a living infrastructure deserves a living tool.
On the near-term roadmap: deeper integration with the organization's monitoring platform, a temperature history graph for the server room, richer certificate tracking with automated expiration checks, and eventually a presentation to leadership that frames the portal as the knowledge foundation for a major application modernization initiative already underway.
The domains question that started this whole project? I can answer it now. In under ten seconds. And the next time someone asks in a meeting, I will not be the one going quiet.
A Note to Administrators Just Starting Out
If you're early in your infrastructure career, here is the most practical advice I can offer: build things that solve real problems, then tell the story of what you built.
The technology in this portal — Python, PowerShell, JSON, HTML — is all learnable. None of it requires a certification. All of it is documented online. What it requires is the willingness to sit with a messy problem long enough to understand it, and the patience to build a solution one piece at a time.
The tools you build for your clients and your employers are the best evidence of your professional commitment. Not your resume. Not your certifications. The actual thing you built, running in production, solving a problem that existed before you arrived.
Build the dashboard nobody built.