Ciao a tutti, nel post di oggi voglio parlarvi di come ho affrontato la migrazione del mio vecchio “Homelab” su un “nuovo” PC sfruttando Claude, le skill di Matt Pocock e una serie di agenti custom. Vi parlerò di cosa è andato bene e di cosa non lo è andato affatto (cercando di capire anche il perchè), i fallimenti lungo il percorso sono stati diversi e vi spiegherò come li ho affrontati e che strade ho preso.

Spoiler: la migrazione si è conclusa con successo!

Situazione di partenza

Il mio homelab era un Raspberry pi 4B con 4GB di ram, sistema operativo raspbian e una serie di servizi avviati come container docker (incluso home assistant, n8n, node red e altri servizi sviluppati da me per gestire la domotica di casa). Da diverso tempo il carico dei servizi aveva portato a saturare la RAM del mio povero PI, con una continua riallocazione su swap dei file in memoria.

Il “nuovo” homelab è un mio vecchio PC con 8GB di ram (abbastanza per poter gestire comodamente tutti i servizi), un processore i7 di 9 generazione e un SSD da 500GB. Non è sicuramente una macchina di punta con eccellenti performance ma abbastanza per gestire il carico richiesto.

Obiettivo della migrazione

L’obiettivo generale della migrazione era ovviamente migrare tutto dal raspberry al nuovo PC, facendo attenzione a questi punti:

Backup: I backup dei container e dei volumi era gestita da backrest e da rclone (per caricare sul cloud i backup effettuati). Questo aspetto doveva essere preservato

Downtime domotica: il downtime della domotica doveva essere al minimo e dovevano essere prese tutte le opportune precauzioni per gestire un eventuale rollback se qualcosa fosse andato storto

Docker: Ogni servizio sul PI era gestito con docker e docker compose, scelta fatta per agevolare un eventuale cambio di PC e per isolare i servizi dal sistema operativo.

Proxmox: con questa migrazione volevo passare da Debian a Proxmox, soprattutto per portare Home Assistant da container ad HAOS. Non ero però certo se il PC avrebbe retto il carico di Proxmox + HAOS + Debian (per il resto dei container). Questo punto andava analizzato e approfondito

Step 1 – Setup ambiente e strumenti

Utilizzo da anni Obsidian come second brain e per questo progetto ho creato una directory dedicata al progetto, con l’obiettivo di centralizzare tutti i file markdown, scratchpad, ticket e materiali prodotti da questa migrazione. L’ho fatto nel mio vault obsidian perchè è qui che gestisco tutti i progetti e con la sincronizzazione attiva sapevo che nulla sarebbe andato perso.

Una volta creata la directory ho creato sotto .claude/agents questi agenti:

• Un agente specializzato in home assistant (con le regole e configurazioni del mio ambiente)
• Un agente specializzato proxmox

Successivamente ho creato un file CLAUDE.md con le caratteristiche del raspberry, le caratteristiche del PC, i miei obiettivi di migrazione e le agent skill da usare.

Infine, per questa migrazione ho utilizzato le skill di Matt Pocock, fantastiche per dare ordine alle attività. Se non le avete mai viste vi consiglio di guardarle perchè le trovo utilissime, le trovate sul sito AI Hero. Una volta installate, dalla CLI di Claude (o del vostro provider preferito) lanciate il comando /setup-matt-pocock che vi permetterà di impostare le regole generali di utilizzo di questi strumenti. Ad un certo punto vi chiederà dove salvare i ticket che lui man mano creerà, io ho scelto di salvarli in locale nella directory .scratch.

Questo è stato il mio punto di partenza.

Step 2 – Scelta del sistema operativo

Il pc avrebbe retto proxmox oppure dovevo continuare con Debian? Per capirlo sono partito con il comando /wayfinder (con modello Opus), utile per capire la direzione quando non si sa bene dove andare o quale strada prendere.

L’utilizzo di questo comando ha portato un’analisi che è durata molte ore, con diverse domande alle quali ho dovuto rispondere (spezzato su diverse sessioni a causa dell’esaurimento dei token). Riassumendo molto, gli step di questa sessione di analisi sono stati:

• Collezione e analisi di metriche del raspberry attuale (a cura di un subagents), per capire il carico e le risorse utilizzate dai servizi attuali.
• Separazione delle metriche di Home Assistant container da quelle degli altri servizi, a cura di un subagents
• Domande-risposte su alcuni aspetti quali backup, alta affidabilità, gestione della macchina, gesitone degli aggiornamenti, ecc.
• Creazione di un file di appunti dove tutto ciò che veniva scoperto e le scelte prese venivano appuntate. Questo è un punto fondamentale, senza di questo avrei sprecato moltissimi token in fasi successive perchè avrei dovuto ri-analizzare i dati.
• Gestione dei test post migrazione

Alla fine di questo processo erano stati generati alcuni ticket con le decisioni prese, alcuni ticket di approfondimento (es. come gestire i container su Proxmox) e alcuni ticket di correzione di situazioni anomale (es. due servizi avevano una policy di backup errata che non li faceva mai partire )

Ad ogni modo il verdetto era che Proxmox con HAOS e Debian sarebbe potuto girare sul PC con 8GB di RAM e i5 di 9 generazione.

Personalmente non ero convinto al 100% di questa strada ma ho comunque preso la decisione di installare Proxmox sul PC, con l’idea di testare realmente l’installazione di HAOS e dei container e decidere in un secondo momento se il PC avrebbe retto.

Step 3 – Installazione Proxmox e server MCP

Ho installato Proxmox sulla macchina e ho configurato il suo server MCP: questa mossa va sempre nella direzione di fornire a Claude dati reali e aggiornati.

Step 4 – Sistemazione anomalie Raspberry

Prima di procedere con la pianificazione della migrazione ho utilizzato la skill /grill-me-with-docs per fare un’analisi approfondita del raspberry per:

• Analizzare servizio per servizio alla ricerca di problemi nei log docker
• Individuare le anomalie di configurazione (docker-compose o configurazioni specifiche)
• Verificare che tutti i backup fossero corretti
• Verificare che la strategia di backup fosse corretta per tutti i servizi (utilizzo backrest + rclone)
• Pulizia vecchi log senza retention policy

Una delle anomalie riscontrate era su Mealie, un servizio di ricette che usa mia moglie, per il quale veniva fatto il backup del volume docker senza fare l’export del database. A livello di backup ovviamente non veniva sollevato nessun errore, ma non sarei mai stato in grado di effettuare un restore corretto del servizio ricopiando la directory con i file del database.

Alla fine della sessione mi sono ritrovato con diversi ticket, ognuno focalizzato sulla sistemazione di un singolo problema. Per ogni ticket, in una nuova sessione, ho usato il comando /implement <ticket> per correggere il problema.

Una volta elaborati e conclusi tutti i ticket generati ero pronto per fare una sessione di planning su come gestire la migrazione.

Step 5 – Pianificazione migrazione

Tramite il comando /grill-me-with-docs ho avviato una sessione di qualche ora per definire le strategie di migrazione.

Ho richiesto fin da subito una migrazione “graduale”, portando sul nuovo PC prima di tutto i servizi meno critici per poi arrivare ai servizi che gestivano la domotica.

Alla fine di questa sessione mi sono ritrovato con diversi ticket nella directory .scratch e una roadmap di migrazione molto dettagliata.

Ogni servizio da migrare corrispondeva ad un ticket, più altri dedicati ad attività di contorno (preparazione ambiente, verifiche dei backup, test, ecc)

Step 6 – Migrazione

Ho elaborato il piano di migrazione con ticket volutamente piccoli ed atomici, in modo tale da gestirli uno alla volta.

La migrazione è stata divisa in due momenti differenti: nella prima fase ho migrato i servizi non legati alla domotica (circa 10 applicazioni, una alla volta), nella seconda fase invece ho migrato tutti i servizi della domotica (Home Assistant, n8n, node-red e altre mie applicazioni) in una volta unica. Per poter fare ciò ho fatto preparare a Claude tutti i servizi sulla nuova macchina (immagini container già scaricate, volumi già pronti, ecc ) e durante la migrazione ho fatto solamente una cosa: backup degli ultimi dati sul PI, spostamento backup sul nuovo Homelab, spegnimento da una parte, accensione dall’altra e verifica del funzionamento (sia da parte di Claude che da parte mia)

Strategia

Tralasciando la suddivisione della migrazione nelle due fasi, ci sono stati alcuni elementi comuni e di cui ora vi parlerò.

La finestra di contesto era ciò che più mi preoccupava di più, non volevo saturarla oltre i 150/200 mila token (per evitare un degrado delle performance ed un aumento delle allucinazioni) ma nello stesso tempo volevo mantenere un’unica sessione, elaborando tutti i ticket insieme.

La strategia che ho adottato è stata la seguente:

• Finestra di contesto unica, elaboravo un ticket alla volta con il comando /implement <ticket>. Lavorando un ticket alla volta ho perso in velocità ma questo mi ha permesso di tenere sotto controllo la migrazione
• Alla fine di ogni elaborazione veniva aggiornata la roadmap e un file scratchpad con le note della migrazione (regole che avevo aggiunto sul file CLAUDE.md).
• Prima i iniziare un nuovo ticket lanciavo il comando /compact per ridurre il contesto e partire il più pulito possibile, preservando un contesto minimo. A fine migrazione il contesto compattato occupava circa 25k token, più 50k token aggiunti di default da claude (il suo contesto, server mcp, ecc).
• Come modello ho utilizzato sempre Opus, sia in fase di brainstorming che in fase di migrazione. A tal proposito ho notato che durante la fase operativa era molto più capace rispetto a Sonnet 5 di individuare i problemi ed uscirne, motivo per il quale ho mantenuto questo modello, a discapito dei token consumati. L’unico momento in cui utilizzavo Sonnet era nel momento in cui venivano lanciati i test post migrazione, tramite subagent dedicato.

Difficoltà incontrate

Ora che abbiamo visto la strategia soffermiamoci sulle difficoltà che ho incontrato.

Limiti giornalieri

Possiedo un account PRO di Claude e questo non mi ha dato molto “respiro”, spesso esaurivo i token a disposizione ed ero obbligato ad aspettare. La sessione di brainstorming è durata 5/6 finestre Claude, mentre la migrazione vera e propria circa 4 giorni.

Test

Nelle regole di CLAUDE.md c’era l’istruzione che tutto ciò che andava migrato doveva prevedere un piano di test che erificasse che tutto fosse operativo come prima. Ho notato che non sempre il piano di test era accurato e venivano fatti dei test sommari (es. di raggiungibilità del servizio). Questo punto l’ho risolto cambiando le regole nel file CLAUDE.md, aggiungendo che i test dovevano essere gestiti da un sottoagente dedicato. Ho quindi creato un agente dedicato con le regole che doveva seguire nella gestione dei test (scrittura ed esecuzione), posizionato in `.claude/agents.

Step 7 – Verifiche post migrazione

Dopo aver completato la migrazione avevo pianificato delle finestre di controllo a 2 ore, dopo una notte, dopo una settimana, a seguito del quale avrei dichiarato conclusa la migrazione e avrei spento il mio amato PI. Cosa controllare era già stato definito in fase di analisi, ogni momento di verifica aveva un ticket dedicato con l’elenco delle principali cose da controllare (principalmente log e varie segnalazioni che avrei fatto io).

Conclusioni

Questa migrazione da una parte mi ha insegnato molto e dall’altra mi ha confermato alcuni aspetti che già conoscevo. Riassumo i punti più importanti che secondo il mio punto di vista sono emersi:

Lavorare “vibe” non funziona Nella vita sono uno sviluppatore e non ho mai creduto nel “vibe coding” e questa migrazione me lo ha confermato. Nel mondo dello sviluppo visto molti lavori creati con questo approccio, ma con enormi problemi architetturali o di scalabilità: funzionavano? si, ma poi presentavano il conto dopo una prima fase iniziale.

Molti aspetti di questo progetto li ho dovuti governare: scartare proxmox, boicottare la doppia VM per le app della domotica, migliorare la gestione dei test. Tutti questi sono esempi di come rimane fondamentale (almeno per me) mantenere un controllo sul progetto e sulla direzione che gli agenti stanno prendendo. Se mi fossi fatto trasportare (puro “vibe”) probabilmente avrei migrato tutti i servizi su una macchina con Proxmox, ritrovandomi con gli stessi problemi di performance dai quali scappavo.

L’importanza del lavoro strutturato L’utilizzo di un sistema di ticketing, la parte di analisi e plan in fase iniziale e le skill di Matt Pocock hanno contribuito in modo significativo all’esito positivo della migrazione. Questo aspetto vale nella vita e anche con i nostri agenti.

Contesto minimale Mantenere un contesto sotto i 150/200k token diminuisce sensibilmente le allucinazione e la perdita di attenzione del modello nei confronti di quello che stiamo facendo. Per farlo è stato fondamentale lavorare con sottoagenti (che hanno un contesto separato da quello principale), spezzare il lavoro in sottoticket piccoli ed atomici e lavorare molto con il comando /compact prima di lavorare un ticket.

File appunti (scratchpad) e roadmap La presenza di questi due file nella directory del progetto sono stati fondamentali. Averli mi ha permesso di avere un file sempre aggiornato con la situazione attuale e mi ha permesso di poter avviare una nuova istanza Claude da strumenti differenti, senza dover dipendere da una singola chat con tutto il contesto.

Spero che questo articolo vi sia stato utile, alla prossima!