Automation / AI

Automation is being introduced incrementally rather than attempting to automate the entire environment at once.

The first objective is to eliminate repeatable manual tasks, make changes more consistent, and create workflows that are understandable and reversible.

The longer-term objective is to connect infrastructure, monitoring, documentation, and AI through controlled automation layers without giving any single tool unrestricted access to the environment.

n8n provides the primary workflow-orchestration platform for the home lab.

It can connect applications, APIs, alerts, webhooks, infrastructure services, and future AI workflows into repeatable processes.

This makes n8n useful for tasks such as reacting to events, collecting data from multiple systems, sending notifications, updating documentation, or triggering controlled administrative workflows.

The platform also provides an important separation layer between a future AI agent and the systems it may eventually be allowed to interact with.

GitHub is being used as the source-control foundation for development, documentation, and automation work.

The portfolio website provides the first practical CI/CD implementation: changes are developed locally, committed to Git, pushed to GitHub, and automatically deployed through Vercel.

That workflow provides hands-on experience with version control, deployment pipelines, rollback history, change tracking, and the separation between development and production deployment.

The same principles can later be extended to home-lab configuration and automation rather than making production changes manually without version history.

Public repositories are used for sanitized examples, portfolio content, and documentation that does not expose sensitive operational details.

Private repositories are intended for configuration that may contain internal addressing, ports, DNS names, topology mappings, infrastructure scripts, and other operational information.

Passwords, API keys, tokens, private keys, and other secrets should not be committed to either public or private Git repositories.

This creates a clear boundary between demonstrating technical work publicly and protecting the information required to operate the actual environment.

The planned AI Network Agent will begin as a read-oriented assistant rather than an autonomous infrastructure administrator.

Its first role will be to understand the lab architecture and documentation so it can answer questions about services, dependencies, network design, and operational procedures.

Later stages can incorporate selected monitoring and observability data so the agent can summarize environment health, help identify anomalies, and assist with root-cause analysis.

Any future ability to make changes will be mediated through authenticated automation workflows and explicit controls rather than unrestricted direct access to Proxmox, UniFi, storage, or other critical platforms.

A long-term goal is to interact with the environment conversationally from a laptop rather than having to remember every management interface, command, and dashboard location.

The value is not simply natural-language control. The more important goal is to create a common interface that can retrieve documentation, summarize telemetry, explain dependencies, and eventually initiate approved workflows.

The conversational layer should remain an interface to controlled systems rather than becoming a substitute for authentication, authorization, auditability, or change management.

Network automation is intended to reduce repetitive administration and provide more consistent documentation and operational workflows.

Potential use cases include inventory updates, configuration validation, monitoring responses, documentation generation, and controlled device-management workflows.

Because the network is segmented into multiple trust zones, automation must preserve the same least-privilege boundaries used by manually administered services.

Infrastructure as Code is one of the primary next-stage capabilities for the lab rather than a completed feature.

The planned workflow uses GitHub for version control and change history, Ansible for configuration management, Terraform or OpenTofu for declarative infrastructure provisioning, Docker Compose for repeatable application stacks, and GitHub Actions for CI/CD orchestration.

The goal is to replace more one-off manual changes with repeatable definitions that can be reviewed, tested, documented, and reproduced.

Operational repositories will remain private where they contain internal network details, while public repositories will be sanitized for portfolio use. Secrets will remain outside source control.

AI-assisted operations are intentionally designed around human approval.

Read-only access, analysis, and recommendations can be introduced earlier because they carry substantially less operational risk than direct infrastructure changes.

Actions that modify routing, firewall policy, virtualization, storage, identity, or other critical services should pass through narrowly scoped workflows with authentication, authorization, logging, and explicit approval where appropriate.

The objective is to gain the efficiency of automation without losing accountability or creating an unrestricted administrative path into the environment.

Automation should make the environment more predictable, not merely more complicated.

A useful automated process should be repeatable, observable, auditable, and easier to recover from than the manual process it replaces.

The long-term architecture therefore combines Git-based change control, n8n orchestration, monitoring and observability data, and AI assistance behind clearly defined security boundaries.