Building My Own Ops Center – A Homelab Project for Linux, Automation, Security and AI

What started as a small admin panel for my homelab has gradually grown into something much bigger: my own infrastructure operations platform, which I simply call Ops Center.

This is not a commercial product, nor is it something I am trying to reinvent as an alternative to established enterprise platforms.

It is primarily a personal homelab and learning project.

I wanted an environment where I could experiment with Linux, automation, containers, monitoring, security, high availability and AI-assisted operations — and where breaking something is part of the learning process.

The original idea was quite simple: instead of constantly jumping between SSH sessions, monitoring dashboards, container management tools and various scripts, why not try to bring everything together in one place?

That simple idea has grown quite a bit.

One place to operate the homelab

Ops Center provides a central view of the infrastructure and currently manages multiple Linux servers and Docker hosts.

The main dashboard gives me a quick overview of server availability, services, containers, pending security updates, vulnerabilities, active alerts and recent automation jobs.

Behind the interface, the platform itself is built around a FastAPI backend and React frontend, with most components running as containers using Docker Compose.

Ansible provides much of the automation layer, while Prometheus, Grafana, Loki and Alertmanager provide monitoring, metrics, logging and alerting.

There are currently around 28 containers just supporting the Ops Center platform itself.

And yes, running that many containers to manage a homelab may be slightly excessive. 😄

But that is also part of the fun.

Infrastructure automation with Ansible

One of the main goals was to make common Linux administration tasks available directly from the platform.

Ansible is therefore heavily integrated into Ops Center.

From the web interface I can run tasks such as:

• Host bootstrap and configuration • System and package inventory • Health and service checks • Security patching • Full system patching • Reboot checks and controlled reboots • Docker inventory • Container operations • Docker image management • Network and volume inspection • Docker Compose stack deployment and management

For potentially disruptive operations, I deliberately added confirmation and approval mechanisms.

Automation is useful, but I don't want an AI agent or an accidental click deciding that rebooting a server is a good idea without asking first.

Security intelligence – not just another CVE list

[IMAGE 3 – INSERT SECURITY INTELLIGENCE IMAGE HERE]

Another area I've spent quite a bit of time experimenting with is vulnerability management.

Simply displaying thousands of CVEs isn't particularly useful. What I really wanted to know was:

Which vulnerabilities should I actually care about in my environment?

Ops Center collects security information from several sources, including CISA Known Exploited Vulnerabilities (KEV), FIRST EPSS and Linux security advisories.

That information can then be correlated with the actual systems, packages and containers running in the environment.

Instead of only looking at CVSS severity, vulnerabilities can be prioritized using information such as:

• Severity and CVSS • CISA KEV status • EPSS exploit probability • Whether a fixed version exists • Which hosts or containers are affected • How many systems are affected • The importance of the affected system

This gives me a much more useful view than simply sorting vulnerabilities by publication date or CVSS score.

The goal is to answer a much more operational question:

"What should I patch first?"

The advisory view takes this one step further by showing advisories that actually affect systems in the environment, including the relevant packages, CVEs, severity and number of affected hosts.

This is something I've wanted from the beginning: less vulnerability noise and more information that can actually help make patching decisions.

Container management

Container management has also become a fairly large part of Ops Center.

I wanted something similar in concept to the workflows I like from tools such as Portainer, but integrated into the rest of my own platform.

Docker hosts are registered centrally, and I can open an individual host to inspect and manage:

• Containers • Images • Networks • Volumes • Docker Compose stacks • Events • CPU, memory and storage utilization

Existing Compose stacks can also be discovered and adopted into Ops Center, while new stacks can be deployed directly from the interface.

The important part for me wasn't necessarily replacing existing container management tools.

It was learning how these functions actually work and integrating them with the rest of the infrastructure management workflow.

Building an application catalog

Once stack deployment worked, the next logical experiment was an App Catalog.

The idea is fairly simple: select an application, fill in the required configuration and let Ops Center generate and deploy the resulting Docker Compose stack.

The catalog can consume existing self-hosted application templates, making it possible to browse and deploy applications without manually creating every Compose file from scratch.

Again, there are already excellent tools that do this.

Building my own version is about understanding the process behind it and seeing how far I can integrate it with inventory, monitoring, security scanning and automation.

Experimenting with high availability

Then came one of those questions that tends to make homelab projects considerably more complicated:

What happens if the server running Ops Center goes down?

So naturally, I started experimenting with HA as well.

The database layer uses PostgreSQL with Patroni and etcd, allowing database leadership and replication to be managed between nodes.

Redis uses replication and Sentinel for monitoring and failover.

Keepalived/VRRP is used for virtual IP and failover functionality, while Nginx Proxy Manager sits in front as the reverse-proxy layer for publishing the platform and its services.

Part of this is deliberately over-engineered for a homelab.

I don't actually need enterprise-style HA to keep my house running.

But building it provides a much better understanding of concepts such as quorum, replication, failover, split-brain scenarios, service discovery and what actually happens when infrastructure components disappear unexpectedly.

Reading about HA is useful.

Pulling the plug on a node and seeing whether your design survives is considerably more educational.

Adding AI agents to infrastructure operations

Now for probably the most experimental part of the project: AI agents.

Instead of having one general AI assistant trying to understand everything, Ops Center has multiple specialized agents with different responsibilities.

Currently these include agents focused on areas such as:

• Linux operations • Monitoring • Security • Containers • Networking • Patching • Automation • General infrastructure operations • Chat and coordination

The idea isn't to simply add a chatbot to a dashboard.

I want the agents to have actual operational context.

For example, a Linux agent should be able to inspect Linux hosts and services. A container agent should understand Docker hosts and container state. A security agent should be able to correlate vulnerability information with the systems that are actually affected.

Agents can inspect infrastructure, analyze problems and propose or execute operational tasks through the automation layer.

However, there is an important rule:

Anything capable of making a meaningful change to infrastructure requires manual approval.

I want AI to assist with operations, not silently become root on everything and hope for the best. 😄

The Ops Floor

Because apparently a normal list of AI agents wasn't unnecessary enough, I also built an Ops Floor.

This is a visual 2D/3D operations room where each specialized agent has its own workstation and identity.

Linux Ops, Monitoring, Security, Containers, Network, Patching, Automation and the other agents are represented visually, while a coordinator sits in the middle.

The interface shows which agents are online, idle, working, processing tasks or encountering errors.

Selecting an agent gives access to its capabilities, current task and recent activity, and I can open a chat directly with that specific agent.

It doesn't make the infrastructure run any faster.

But it does make watching nine AI agents work considerably more entertaining. 😄

More importantly, the visualization is an experiment in making multi-agent systems easier to understand. Instead of having invisible processes running somewhere in the background, I can immediately see which component is responsible for what.

Talking to the infrastructure through Nextcloud Talk

I've also been working on integrating the agents with Nextcloud Talk.

The idea is that I shouldn't necessarily need to open Ops Center every time I want information from the environment.

I can communicate with the agents through chat and ask questions about infrastructure status or request operational tasks.

For example, the long-term goal is to make conversations such as these possible:

"Are there any Linux servers that need patching?"

"Check the Docker hosts for unhealthy containers."

"Why is this service generating alerts?"

"Show me which critical vulnerabilities currently have fixes available."

The agent can gather the relevant information from Ops Center and return it directly in the conversation.

For actions that modify infrastructure, the same approval model still applies.

Observability underneath everything

A platform managing infrastructure also needs visibility into itself.

Ops Center therefore includes an observability stack based around Prometheus, Grafana, Loki and Alertmanager.

Metrics provide visibility into server and application health, Loki handles centralized logging, and Alertmanager handles operational alerts.

This also creates an interesting feedback loop.

Ops Center monitors the infrastructure.

But because Ops Center itself consists of infrastructure, it also has to monitor itself.

That has resulted in some interesting debugging sessions.

Why build something that already exists?

This is probably the most obvious question.

There are already mature products for almost every individual feature I've built.

Portainer manages containers.

Ansible/AWX handles automation.

Grafana handles visualization.

Prometheus handles metrics.

Various vulnerability management platforms handle CVEs.

There are plenty of AI assistants.

So why build another platform?

Because the goal isn't really the platform itself.

The goal is learning how all of these pieces fit together.

When you build the integration yourself, you quickly run into problems that aren't obvious when looking at an architecture diagram.

Authentication, API design, secrets management, failure handling, asynchronous jobs, database migrations, container networking, HA state, monitoring, security boundaries and dozens of other small details suddenly become real problems that need solving.

That's where I find most of the learning happens.

AI-assisted development

AI has also been part of the development process itself.

I've been using AI-assisted coding tools while developing Ops Center, particularly for generating and reviewing code, troubleshooting, iterating on the UI and exploring different implementation approaches.

That has been an interesting learning experience on its own.

AI can generate code incredibly quickly, but designing the architecture, defining requirements, testing the results and deciding whether something is actually a good idea still requires understanding the underlying systems.

And AI can be surprisingly creative when it comes to finding new ways to break things. 😄

For me, the most useful combination has been using AI to accelerate development while treating the homelab as the environment where those ideas have to prove that they actually work.

Still a work in progress

Ops Center isn't finished, and I'm not sure it ever really will be.

There are still plenty of things I want to experiment with: better self-healing capabilities, deeper monitoring integration, more capable AI agents, improved security correlation, better automation workflows and further HA testing.

And I'm sure I'll think of another unnecessary feature before those are finished.

But that's exactly what I wanted from the project.

A place where I can experiment with Linux, automation, containers, observability, security, high availability and AI in an environment I actually operate.

Not a commercial product.

Not production infrastructure.

Just a homelab project built out of curiosity and an interest in understanding how things work.

And probably a little bit of over-engineering. 😄