homelab-deploy/CLAUDE.md

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Project Overview

homelab-deploy is a message-based deployment system for NixOS configurations using NATS for messaging. The binary operates in three modes:

1. Listener mode - Runs on NixOS hosts as a systemd service, subscribes to NATS subjects, executes nixos-rebuild on deployment requests
2. MCP mode - MCP server exposing deployment tools for AI assistants
3. CLI mode - Manual deployment commands for administrators

Build Commands

# Enter development shell
nix develop

# Build the binary
go build ./cmd/homelab-deploy

# Run tests
go test ./...

# Build with Nix
nix build

Architecture

NATS Subject Structure

Subjects follow deploy.<tier>.<target>:

• deploy.<tier>.<hostname> - Deploy to specific host
• deploy.<tier>.all - Deploy to all hosts in tier
• deploy.<tier>.role.<role> - Deploy to hosts with role in tier
• deploy.responses.<request-id> - Response subject for request/reply
• deploy.discover - Host discovery subject

Planned Package Structure

cmd/homelab-deploy/main.go    # CLI entrypoint with cobra subcommands
internal/listener/            # Listener mode (NATS subscription, nixos-rebuild execution)
internal/mcp/                 # MCP server mode
internal/nats/                # NATS client wrapper
internal/deploy/              # Shared deployment execution logic
nixos/module.nix              # NixOS module for listener service

Key Design Patterns

• Request/Reply over NATS: Deployer sends request with unique reply_to subject, listener responds with status updates
• NKey authentication: All NATS connections use ed25519 NKey authentication
• Concurrency control: Only one deployment per host at a time (in-memory lock)
• Tiered access: MCP has separate credentials for test-tier vs admin (all tiers) access

Message Formats

Request: {"action": "switch|boot|test|dry-activate", "revision": "<branch-or-commit>", "reply_to": "<subject>"}

Response: {"hostname": "<name>", "status": "accepted|rejected|started|completed|failed", "error": "<code>|null", "message": "<details>"}

Dependencies

Key Go libraries to use:

• github.com/nats-io/nats.go - NATS client
• github.com/mark3labs/mcp-go - MCP server implementation

Build Commands

Run commands through the Nix development shell using nix develop -c:

# Build
nix develop -c go build ./...

# Run tests
nix develop -c go test ./...

# Run single test
nix develop -c go test -run TestName ./path/to/package

# Lint
nix develop -c golangci-lint run

# Vulnerability check
nix develop -c govulncheck ./...

# Test Nix build
nix build

# Run the binary (prefer this over go build + running binary)
# To pass arguments, use -- before them: nix run .#default -- --help
nix run .#default

Testing Procedures

Before committing, run the following checks:

1. nix develop -c go test ./... - Unit tests
2. nix develop -c golangci-lint run - Linting
3. nix develop -c govulncheck ./... - Vulnerability scanning
4. nix build - Verify nix build works

Commit Message Format

Use conventional commit format:

feat: add new feature
fix: fix a bug
docs: update documentation
refactor: refactor code without changing behavior
test: add or update tests
chore: maintenance tasks

Version Bumping

Follow semantic versioning:

• Patch (0.0.x): Bugfixes
• Minor (0.x.0): Non-breaking changes adding features
• Major (x.0.0): Breaking changes

Update the const version in main.go. The Nix build extracts the version from there automatically.

When to bump: If any Go code has changed, bump the version before committing. Do this automatically when asked to commit. On feature branches, only bump once per branch (check if version has already been bumped compared to master).