Project / active

Network Automation Scripts

Small automation and documentation workflows for network-adjacent systems, updates, service checks, and configuration review.

This project is about building a cautious operations workflow for the lab: update visibility first, AI-assisted review second, and automation only where the risk is understood.

With the pace of AI tooling and the cybersecurity risks that come with constantly changing software, I wanted better visibility into what needed attention across my systems. The goal is not to blindly auto-update everything. The goal is to know what changed, what matters, what can be safely handled, and what needs a maintenance window.

Problem

As the lab grew, updates became harder to reason about. There are VMs, LXCs, Docker containers, host-level systems, and services that matter for daily use. Some updates are routine. Some require reboots. Some might affect core services like DNS, remote access, Home Assistant, Docker, or media workloads.

Security updates add another layer. If a high-priority vulnerability appears, I want to know about it quickly. But going fast without a plan can create broken services, surprise reboots, and complex recovery. The real problem is balancing security urgency with operational stability.

Approach

The current version uses Semaphore to check the main VMs. It runs update checks and pushes a Home Assistant notification with the number of updates available. From there, I manually work with an AI agent to review the updates, summarize what changed, and decide what should be prioritized.

Current patterns include:

  • Use Git-backed configuration where practical.
  • Review updates before applying them instead of blindly auto-updating everything.
  • Use AI assistance to summarize release notes and flag vulnerability relevance.
  • Keep reports readable enough to commit and revisit.
  • Use Semaphore/Ansible experiments as a learning path for repeatable maintenance.
  • Prefer read-only checks and human review before promoting automation into core-service changes.
  • Treat automation as a learning tool first, then promote it only when it becomes reliable.
  • Use snapshots and backups before higher-risk updates where practical.
  • Keep Home Assistant notifications as a lightweight signal that something needs review.

Current Workflow

The workflow is still fairly manual:

  1. Semaphore runs update checks against selected systems.
  2. Home Assistant receives an update-count notification.
  3. I review the updates with help from an agent.
  4. The agent helps summarize what looks routine versus what might be security-relevant.
  5. I decide whether to snapshot, schedule downtime, update manually, or wait.
  6. I verify the important services afterward.

That is not fully automated yet, but it already provides useful visibility. The first win was knowing when updates are available without logging into every system one by one.

Result

The useful result so far is a maintenance habit, not a perfect automation platform. I have a path for checking key systems, getting a notification, and using AI to help reason through update priority. That is enough to make the lab feel more manageable while still keeping the actual change control human-owned.

This project also gives me a practical way to learn Ansible and Semaphore without immediately giving automation broad write access to the reliable core of the lab.

What Still Needs Work

The next gap is coverage. I want the workflow to include Docker containers, host-level devices, and more service-aware health checks. It should not only ask “are updates available?” It should also help answer “what is affected, what is risky, and what should happen next?”

I also want a better place for reports to live. Home Assistant notifications are useful, but a fuller internal dashboard or intranet-style site could collect update reports, service inventory, health checks, vulnerability notes, and maintenance history in one place.

Next Pass

A strong v1 would look like this:

  • Automated checks through Semaphore for selected systems.
  • Docker container and host-level update visibility.
  • A generated report that an agent can review and summarize.
  • Update priority ratings based on security relevance, reboot need, and breakage risk.
  • Low-risk updates handled automatically only after the workflow has proven reliable.
  • High-risk or security-sensitive updates escalated with a clear alert and maintenance-window recommendation.
  • Snapshots, backups, and rollback notes included before risky changes.
  • Post-update verification for important services.

The professional signal I want this project to show is that I care about keeping systems current, especially for security issues, but I also understand that automation without a plan can make recovery harder. The point is not just to automate updates. The point is to build an update process that is visible, reviewable, and safe enough to trust.