DEV Community

Mike
Mike

Posted on

Opencode for network systems administration. OMG.

#ai #aiops

I've been running a homelab for a few years now. Nothing fancy - a Proxmox box, couple Docker hosts, a router running OpenWrt, and a VPS for public-facing stuff. The usual.

The problem was documentation. I had stuff scattered across text files, random markdown docs, and my own memory. When something broke at 2am, I'd be digging through half-remembered configs trying to figure out what I did six months ago.

The Setup

I started using OpenCode (formerly Claude Code) a while back and it's become my actual systems admin tool. Not just for coding - for keeping my infrastructure documented and maintained.

Here's what I've got it doing:

Network Topology Documentation

I have an LLM Wiki pattern set up. Structure looks like this:

raw/          -- source documents (immutable)
wiki/         -- markdown pages maintained by OpenCode
wiki/index.md -- table of contents
wiki/log.md   -- append-only record of changes
Enter fullscreen mode Exit fullscreen mode

When I add a new server or service, I dump the raw info in raw/ and tell OpenCode to ingest it. It creates summary pages, updates the index, links related concepts. Single source can touch 10-15 wiki pages and that's fine - it's supposed to work that way.

Security Audits

This is where it gets useful. I have a sysops user with SSH keys deployed across all my servers. OpenCode connects as that user and runs actual security audits.

What it checks:

  • SSH configuration (key-only auth, no root login)
  • Firewall rules (UFW status, open ports)
  • Docker security (privileged containers, image sources)
  • System updates (pending security patches)
  • Authentication logs (failed login attempts)

The output: Comprehensive markdown reports with risk ratings, specific findings, and actual bash commands to fix issues. Not generic advice - commands tailored to my setup.

Example output:

| Server | Overall Rating | Risk Level | Critical Issues |
|--------|---------------|------------|-----------------|
| Router (192.168.1.1) | ⚠️ MODERATE | Medium-High | 2 |
| Proxmox (192.168.1.67) | ✅ GOOD | Low | 0 |
| Docker1 (192.168.1.231) | ⚠️ MODERATE | Medium | 0 |
Enter fullscreen mode Exit fullscreen mode

Findings like "🔴 Admin Interface Exposed to WAN - LuCI accessible on ports 8080/8443 from internet" with actual fix commands:

uci delete uhttpd.main.listen_http
uci delete uhttpd.main.listen_https
uci add_list uhttpd.main.listen_http='192.168.1.1:8080'
uci commit uhttpd
/etc/init.d/uhttpd restart
Enter fullscreen mode Exit fullscreen mode

Live Device Management

I recently added a NETGEAR GS308Ev4 switch to the network. Instead of just documenting it exists, I had OpenCode:

  1. Connect to the web interface via Chrome DevTools MCP
  2. Log in and navigate the management UI
  3. Extract live port statistics - traffic counters, error rates, link status
  4. Document everything in the wiki with actual data

Port 1: 333.9 GB received, 48.6 GB sent, 0 CRC errors

Port 5: 219.6 GB received, 316.1 GB sent, 0 CRC errors

...etc

Now I have real traffic data in my docs, not just "it's a managed switch."

The Workflow

Daily: Nothing. It just sits there.

Weekly/Monthly: I'll have it run security audits, check for drift between documented state and actual state.

When adding hardware:

  • Add raw source file with device info
  • Tell OpenCode to ingest it
  • It creates/update all the related wiki pages
  • Updates indexes and logs automatically

When something breaks: I ask it to check the wiki first, then diagnose based on documented topology.

What's Actually Different

Before, my docs were always out of date. I'd document something when I set it up, then never touch it again. Six months later the docs were worthless.

Now the docs get updated whenever something changes. OpenCode maintains them the same way I'd maintain code - iteratively, with proper linking and structure.

The security audits catch stuff I'd miss. Like having MongoDB exposed on a public-facing VPS. Or the router admin panel accessible from the internet. These are obvious in retrospect but easy to overlook when you're just trying to get stuff working.

The Real Value

It's not about having an AI do my job. It's about having a tool that:

  1. Actually documents what I build - not perfect docs, but current docs
  2. Finds security issues I miss - because I get tunnel vision on the thing I'm fixing
  3. Gives me actionable commands - not "consider restricting access" but sudo ufw delete allow 27017
  4. Maintains context - it knows my network topology, so questions don't need a 20-minute briefing

I still make the decisions. I still run the commands. But I don't have to hold the entire infrastructure map in my head anymore.

If You're Thinking About Trying This

You don't need a complex setup. Start with:

  1. A markdown wiki structure that makes sense to you
  2. One source of truth for raw data (don't let the AI edit these)
  3. Let the AI maintain the derived docs (summaries, indexes, linked pages)
  4. Give it SSH access to actually check things (key-only, restricted sudo)

The key is treating it like a junior sysadmin who writes good documentation, not a magic fix-everything tool. It needs direction, it needs context, and it will make mistakes you have to catch.

But when it works? You have infrastructure documentation that stays current without you having to remember to update it. That's worth the setup time.

Tools mentioned:

  • OpenCode (cli-based AI coding assistant)
  • LLM Wiki pattern (Karpathy's approach to knowledge management)
  • Chrome DevTools MCP (for web UI automation)
  • Standard SSH/sysadmin tooling

Network: Proxmox, Docker, OpenWrt, Ubuntu servers, managed switches - nothing exotic.

Top comments (0)