01 - Visione e Obiettivi

Cosa è st4ck

st4ck e' la piattaforma self-host che sostituisce in modo controllato i servizi cloud commerciali e l'ecosistema software Synology proprietario. Ospita chat, archivio documenti, foto, knowledge base, password vault, archivio email, autenticazione unificata, e backup multi-livello geograficamente distribuiti.

Obiettivi strategici

• Vendor independence: stack interamente Docker su Linux puro. Migrazione hardware in mezza giornata.
• Orizzonte 10 anni: scelte tecnologiche basate su software con track record solido (ZFS/btrfs, Postgres, Authentik, Matrix), non su mode passeggere.
• Sovranita' dati: 100% dati a casa o presso famiglia. Cloud usato solo come terzo livello di backup cifrato.
• Resilienza: due siti geograficamente separati con replica live. Internet domestico down = sistema continua a funzionare in LAN.
• Costo razionale: nessun nuovo hardware da comprare per partire (riuso totale del parco esistente).
• Sicurezza per default: 2FA obbligatorio ovunque, E2EE chat, backup cifrati, zero porte aperte sul router.

Cosa NON e' st4ck

• Non e' un servizio commerciale: nessuna SLA, nessuna fatturazione, uso strettamente personale e familiare.
• Non sostituisce mail server attiva (solo archiviazione: l'invio resta su provider esterno tipo ProtonMail/Outlook).
• Non sostituisce calendario/contatti (restano su Outlook).
• Non federa con altri Matrix server: chat e' chiusa.

Utenti target

Inizio: 2 utenti (Aldo + moglie, accesso paritario per ridondanza umana).
Fase 2: 4 utenti (+ 2 figli).
Massimo previsto: 10-15 utenti (parenti stretti / amici fidati).

02 - Architettura ad Alto Livello

Topologia 2-siti

Due siti fisicamente separati connessi via VPN site-to-site UniFi (Site Magic, mesh WireGuard). Cloudflare DNS + Tunnel come unico ingress pubblico. Nessuna porta aperta su router di nessuno dei due siti.

Edge satelliti (modulo j4rv1s)

Asse aggiuntivo introdotto dal modulo j4rv1s: satelliti voice-first WiFi distribuiti in casa che parlano via Wyoming protocol al G8. Wake word locale on-device, audio mai esce dal satellite finche' non scatta il trigger. Brain (STT/LLM/TTS/skill) tutto containerizzato dentro st4ck.

Modulo j4rv1s — riferimenti incrociati nel dossier: §03 (2× HA Voice PE in inventario hardware), §05 sotto-sezione "Modulo j4rv1s" (7 container brain + 18 skill compatte), §06 (override AdGuard j4rv1s.d0mus.com), §08 (3 righe retention conversation/audit/memory), §11 sub-step Fase 0/1/2/4 (j4rv1s F0a-F7 integrati cronologicamente), §14 (decisione "Modulo j4rv1s integrato in st4ck"), §15 (ISSUE-011 sequencing + decisione differita D2 con 3 opzioni service node LLM), App. A (BOM edge satelliti + 7 container nello stack a regime). Design doc completo separato: /Users/user1/st4ck/j4rv1s/docs/design.html (v0.3, 12 decisioni risolte + 5 differite).

Identity flow (Authentik OIDC hub)

Pattern "1 IdP → N services": ogni servizio ha un OIDC client registrato in Authentik come SSO provider. Login utente avviene una volta su 1d.d0mus.com, sessione 8h valida per tutti i servizi. SPoF tracciato (ISSUE-001 break-glass) ma il design è giusto: meglio 1 IdP da hardenare che 11 da maintenare.

Principi architetturali

• Compute separato dallo storage: NUC esegue applicazioni, NAS conserva dati. Sostituibili indipendentemente.
• Identita' centralizzata: tutto autenticato via Authentik (OIDC + TOTP/WebAuthn).
• Tre livelli di backup: locale orario, NAS giornaliero, cloud catastrofico. Nessun single point of failure.
• Split-horizon DNS: dalla LAN i servizi si raggiungono direttamente; internet down non blocca l'uso interno.
• Failover manuale ma rapido: niente HA cluster (split-brain rischiosi), ma promote/demote codificato in runbook.

03 - Hardware e Ruoli

Inventario operativo

Hardware da dismettere

Recupero totale stimato dalla dismissione: ~750-1000 EUR, parzialmente ricicla per UCG-Ultra + UPS aggiuntivo casa genitori.

Profilo elettrico aggregato

04 - Storage e Dischi

HP EliteDesk 800 G8 - layout dischi

Vincolo hardware: il G8 ha 2 soli slot M.2 e nessuna SATA bay interna; il cassettino 2.5" recuperato dal G5 NON e' meccanicamente compatibile con il chassis del G8 (montaggio scartato dopo verifica). Di conseguenza il terzo disco vive esterno via USB-C 3.2 Gen2.

SSD esterno: e' il Samsung 870 EVO 500 GB originariamente destinato al DS718+ per la PoC iniziale di ch4t (Postgres + Redis su usbshare1); con la migrazione dell'architettura al G8, lo stesso disco viene riusato in enclosure USB-C UASP (~25 EUR, chip JMS583/RTL9210/ASM2362, no SMR) e dedicato al repository Restic locale. Throughput sostenuto ~1000 MB/s, ampiamente sufficiente per snapshot orari e dedup. Mount stabile via UUID in /etc/fstab con opzioni nofail,x-systemd.device-timeout=10s per evitare boot bloccati se l'enclosure non e' presente.

Altri dischi del parco: il Samsung 256 GB M.2 SATA precedentemente nel G8 viene rimosso (slot ceduto al 990 PRO 1 TB). Il 970 EVO+ 500 GB del NUC10 e' destinato al G8 replica futuro a casa genitori. Una chiavetta USB consumer (es. 256 GB) e' stata valutata e scartata per questo ruolo: endurance e IOPS random write inadeguate al workload Restic continuativo.

Allocazione su Samsung 990 PRO 1 TB (primary btrfs)

/                   ~  50 GB
/var/lib/docker     ~ 150 GB   (immagini + overlay)
/srv/data           ~ 600 GB   (volumi DB latency-critical)
   |
   +-- pg-authentik/        Postgres Authentik
   +-- pg-synapse/          Postgres ch4t (Matrix)
   +-- pg-seafile/          Postgres Seafile
   +-- pg-immich/           Postgres + ML Immich
   +-- pg-paperless/        Postgres Paperless
   +-- pg-vaultwarden/      Postgres Vaultwarden (o sqlite)
   +-- redis/               Redis multi-tenant
   +-- synapse-state/       media_store + signing key
swap (file)         ~   8 GB
margine libero      ~ 200 GB

Allocazione su Kioxia XG6 512 GB (secondary btrfs)

/srv/data2          ~ 500 GB
   |
   +-- caddy/               data + cert Let's Encrypt
   +-- authentik-media/     templates e media Authentik
   +-- seafile-objects/     block storage Seafile
   +-- paperless-index/     indice full-text Whoosh
   +-- mailpiler-sphinx/    indice ricerca mail archive
   +-- adguard/             config + query log
   +-- caddy-cert/          certificati LE renewabili

Allocazione su Samsung 870 EVO 500 GB (USB-C esterno, ext4)

/srv/restic-local   ~ 500 GB
   repository Restic con snapshot ORARI di:
   - /srv/data
   - /srv/data2
   - /etc, /home//configs
   Dedup automatico -> 30-60 giorni di history
   Mount stabile via UUID in /etc/fstab

DS720+ #1 - hot storage casa

Layout fisico

Esposizione e cartelle

Esposto via NFS al G8 primary, percorso interno LAN, banda 1 Gbit. Cartelle:

• /foto — Immich library (incluso ML face cache parziale)
• /documenti — Seafile data dir
• /knowledge — Paperless-ngx archive (originali + OCR)
• /archivio-mail — Mailpiler raw .eml store (indici su NVMe locale, vedi ISSUE-005)
• /backups/clients — Kopia repository per endpoint famiglia

DS720+ #2 - mirror genitori e backup locale casa

Layout fisico

Ruoli sovrapposti

• Snapshot Replication da DS720+ #1: ricezione block-level ogni 15 min via Site Magic VPN, in stato r/o. Diventa r/w solo in failover (manualmente promosso).
• Repository Restic giornaliero: shared folder dedicata per dump cifrati provenienti dal G8 primary.
• Replica Kopia: il repository Kopia di DS720+ #1 entra automaticamente nella Snapshot Replication, niente config extra.

DS918+ - cold storage film

Layout e ruolo

Configurazione esistente conservata (HDD spinning storici). Disattivare progressivamente i servizi Synology (Drive, Photos, Mail) in Fase 2-3. Esporre solo NFS read-only di /film al G8.

Decisione differita: upgrade DS918+ a TrueNAS-on-commodity-hardware se DSM diventa incompatibile in futuro (vedi RA-006). Familiarizzazione lab TrueNAS Scale prevista in Fase 3 su DS720+ #2 dual-boot.

05 - Stack Software

Sistema operativo G8

Identita' unificata

Applicazioni

Servizi interni (LAN / VPN-only)

Servizi raggiungibili solo da LAN o via UniFi Site Magic VPN: nessun record DNS su Cloudflare, nessuna route cloudflared, nessuna esposizione pubblica. Risolti unicamente da AdGuard Home interno.

Infrastruttura di supporto

Modulo j4rv1s

Modulo applicativo dedicato all'assistente personale voice-first multi-room. Edge: 2 satelliti WiFi (HA Voice PE) gia' inventariati in §03. Brain: 7 container dentro st4ck. Solo j4rv1s.d0mus.com e' esposto pubblico (riga gia' presente nella tabella Applicazioni); gli altri 6 container vivono internal-only su apps-net. Design completo in /Users/user1/st4ck/j4rv1s/docs/design.html (v0.3, 2026-05-08).

Riuso servizi st4ck (zero duplicazione): Authentik (SSO dashboard), Caddy (reverse proxy), cloudflared (esposizione pubblica), Redis condiviso DB 3 (working memory j4rv1s), Home Assistant h0me.d0mus.com (orchestratore Wyoming + skill home_*), Blinko/Paperless/Vaultwarden/Immich/Synapse/Mailpiler (skill di consultazione/azione su questi servizi), Restic+Kopia (backup volumi j4rv1s-* e wyoming-* nei pattern esistenti), SQLite via Litestream verso NFS DS720+ #1 (no Postgres dedicato).

LLM router cost-tuned a 5 livelli: L1 regole/intent lookup (50% richieste, 0€), L2 Llama 3.1 8B locale (30%, 0€), L3 Mistral Small 3.x EU default (15%, ~3-5€/mese), L4 Claude Haiku 4.5 (4%, on-demand tool-use), L5 Claude Sonnet 4.6 (1%, solo on-demand esplicito). Anthropic Opus mai automatico.

Skill plugin (priorita' di sviluppo)

18 skill modulari, naming inglese, trigger vocali italiani (mappa in j4rv1s/skills/intents_it.yaml). Hot-reload in dev, versionate in git.

Successor candidates per servizio (mitiga RA-007 e WI-7)

Per ogni servizio dello stack, "successor candidate" è l'alternativa OSS già valutata che potrebbe sostituirlo se l'upstream viene abbandonato, acquisito da vendor non graditi, o cambia drasticamente le condizioni. Non è un piano di migrazione attivo: è la capability dormiente da poter attivare se uno dei rischi WI-7 si manifesta.

Pattern: per ogni servizio core esiste un successor con caratteristiche comparabili e migrazione <2 settimane. Questo è il vincolo di scelta originale degli ADR §14: "selezionare servizi con migrazione possibile in giorni-settimane, non mesi". Nessun servizio nello stack attuale è "lock-in cementato".

06 - Hostname e DNS Strategy

Hostname pubblici (gestiti da Cloudflare)

I record DNS dei servizi pubblici sono CNAME verso il tunnel Cloudflare (*.cfargotunnel.com). Le hostname puntano dinamicamente al tunnel attivo (sito A o B in caso di failover). I servizi LAN-only (vedi b4ckup.d0mus.com) non hanno alcun record su Cloudflare DNS: esistono solo nel DNS interno di AdGuard Home.

DNS interno - split-horizon

AdGuard Home gira sul G8 e risponde a tutta la LAN. Le voci di override mappano gli hostname pubblici a IP locali (split-horizon), e in piu' AdGuard ospita i record dei servizi interni privi di DNS pubblico.

# Override hostname pubblici -> IP LAN (split-horizon)
ch4t.d0mus.com    -> 192.168.1.10   (G8 primary LAN)
1d.d0mus.com      -> 192.168.1.10
dr1v3.d0mus.com   -> 192.168.1.10
ph0t0.d0mus.com   -> 192.168.1.10
kb.d0mus.com      -> 192.168.1.10
4rch1v3.d0mus.com -> 192.168.1.10
v4ult.d0mus.com   -> 192.168.1.10
h0me.d0mus.com    -> 192.168.1.10
br41n.d0mus.com   -> 192.168.1.10
j4rv1s.d0mus.com  -> 192.168.1.10
w3b.d0mus.com     -> CDN Cloudflare (non override, e' statico)
st4ck.d0mus.com   -> CDN Cloudflare (non override, e' statico via CF Pages)

# Hostname interni (NESSUN record su Cloudflare DNS, solo AdGuard)
b4ckup.d0mus.com  -> 192.168.1.10   (Kopia Server, LAN/VPN-only)

Certificati TLS

Caddy usa DNS-01 challenge via API Cloudflare per ottenere certificati Let's Encrypt validi. Lo stesso certificato funziona per:

• Accesso da fuori (via tunnel Cloudflare)
• Accesso da LAN (via DNS override)

Niente warning browser, niente dipendenza da porte 80/443 esposte. Rinnovo automatico ogni 60 giorni con internet attivo.

Il certificato per b4ckup.d0mus.com (servizio LAN-only) si ottiene comunque tramite DNS-01: il record TXT _acme-challenge viene creato temporaneamente in Cloudflare DNS solo durante la validation, senza esporre alcun A/AAAA pubblico per l'hostname.

Comportamento in caso di internet down

07 - Network e Site-to-Site VPN

Topologia di rete

UniFi Site Magic

Mesh WireGuard gestita dalla console UniFi (incluso senza costo aggiuntivo). Setup ~10 minuti. Routing automatico bidirezionale, no NAT, latenza tipica 5-30 ms tra i due siti su FTTH italiana.

Traffico atteso fra siti

Apertura porte

Zero porte aperte sui router di entrambi i siti. Ingress pubblico solo via Cloudflare Tunnel (uscente). Inter-sito solo via WireGuard di Site Magic (uscente da entrambi i lati).

08 - Replica e Backup

Strategia 3-2-1 estesa

Tre copie indipendenti, due tecnologie diverse, una off-site (qui sono due off-site).

Replica live G8 -> G8

Replicato il subvol critico /srv/data (DB e state). NON replicato /srv/data2 (rebuild deterministico al boot). NON replicato /srv/restic-local (per definizione locale).

Tool: btrbk (cron, ogni 15 min)
Trasporto: SSH over Site Magic (WireGuard)
Encrypted: si (WireGuard)
Snapshot retention sul replica: 96 (= 24 h granularita' 15 min)

Replica live DS720+ -> DS720+

Synology Snapshot Replication, configurata via DSM:

• Source: cartelle /foto, /documenti, /knowledge, /archivio-mail su DS720+ #1
• Destination: stesse cartelle su DS720+ #2 (in stato r/o standby)
• Schedule: ogni 15 minuti
• Retention destination: 30 giorni (snapshot recuperabili)
• Trasporto: SSH dentro tunnel Site Magic

Backup B2 cloud

Backup endpoint famiglia

Lo stack copre anche il backup selettivo di cartelle dai dispositivi della famiglia (Mac, Windows, Linux Zorin) verso il G8, indipendente dai backup server-side dei dati st4ck.

Client supportati:

• macOS (primario, tutti i Mac di famiglia): brew install --cask kopiaui, login item per autostart
• Windows: installer MSI ufficiale da kopia.io, scheduled task automatico
• Linux Zorin OS: pacchetto .deb ufficiale (Zorin e' Ubuntu-based, KopiaUI gira su GTK)

Time Machine resta complementare sui Mac. Time Machine via SMB sul DS720+ #1 copre il caso "rebuild totale del Mac via Migration Assistant" dopo guasto SSD o nuovo acquisto. Kopia copre il caso "recupero selettivo file/cartella nel tempo, da qualsiasi dispositivo, con storia lunga e dedup". Ruoli distinti, non sovrapposti.

Posizione nel modello 3-2-1. Gli endpoint famiglia diventano una sorgente dati aggiuntiva, e il loro repo Kopia su DS720+ #1 entra automaticamente nella replica Snapshot Replication verso DS720+ #2 (Layer 4) e nel backup B2 cloud (Layer 5). Quindi anche le cartelle dei Mac eredita off-site + cloud senza configurazione extra.

Data retention policy per servizio

Politica esplicita di conservazione dati per ciascun servizio, separata in 3 colonne: dati attivi (UI utente), copie di backup (Restic locale/B2 cloud), log applicativi. Necessaria per (a) prevedere la crescita storage, (b) rispettare il principio GDPR di conservazione limitata anche se l'eccezione "uso domestico" si applica solo in parte (i terzi che entrano nei sistemi escono dall'eccezione), (c) avere una posizione difendibile se un familiare chiede cancellazione.

Eccezioni / override: qualsiasi familiare puo' richiedere cancellazione anticipata dei propri dati personali (vedi runbook off-boarding in docs/runbooks/offboarding.md, da scrivere come da ISSUE-009 in §15). La cancellazione e' best-effort: i log applicativi anonimizzati (es. timestamp di azioni, IP) restano fino al ciclo di rotation. I backup Restic/Kopia/B2 non vengono espunti retroattivamente — i dati dell'utente decadono naturalmente al termine della retention 3y dell'ultimo snapshot.

Storage growth check: review semestrale dello spazio occupato su DS720+ #1 e su B2. Se Immich supera 5 TB o B2 supera 50 EUR/mese, riapertura discussione in famiglia su downgrade qualita' foto storiche / esclusione film backup.

09 - Modello di Sicurezza

Sicurezza stratificata su 5 layer. Le mitigazioni elencate qui sono le primary; il dettaglio operativo (configurazione, comandi, runbook) vive nelle sezioni di riferimento per evitare duplicazione narrativa.

Hardening account Cloudflare (L1 + L2 trasversale): hardware key 2FA + email separata + Certificate Transparency monitoring + API token scope minimo (Zone:DNS:Edit per d0mus.com, no account-wide). Tracciato come ISSUE-010 P0 da chiudere in Fase 1 step 0. Risk register per scenari long-term in RA-001..008.

10 - RTO / RPO Matrix

Recovery Time / Recovery Point Objective per scenario di failure. Visione "what happens if X breaks": RPO = quanto di lavoro si perde, RTO = quanto serve per tornare operativi.

Scenari frequenti (drill semestrale)

Scenari hardware (mitigati da replica)

Scenari critici (BCP totale)

Tono: verde = recovery rapido, esperienza utente impattata minimamente · ambra = downtime accettabile, utente avvisato · rosso = downtime esteso, recovery dipende da rete + tempo di download da B2. Drill DR semestrale (vedi §13) verifica gli scenari ambra+rosso in produzione.

11 - Phasing del Rollout

Fase 0 - Preparazione (settimana 1)

Fase 1 - Core stack (mesi 1-2)

Output Fase 1 Chat e password manager funzionanti, identita' centralizzata, due livelli di backup attivi, infrastruttura voice j4rv1s pronta (container running, OIDC client registrato). Sistema "production-ready" per 2 utenti. CF account hardenato. LUKS at-rest attivo.

Fase 2 - Espansione apps (mesi 3-4)

Output Fase 2 Stack completo a singolo sito, 4 utenti, funzionalita' 100%, Synology lock-in eliminato. j4rv1s con voice loop attivo + 3 skill core funzionanti in 2 stanze. Decision point a fine Fase 2: j4rv1s copre ~50% casi d'uso target. Proseguire F3-F7 e' opzionale, dipende da uso reale.

Fase 3 - Disaster recovery off-site (mesi 5-6)

Output Fase 3 Ridondanza geografica live. RPO 15 min. RTO 30 min. Drill DR esercitato.

Fase 4 - Maturazione (mesi 7-12)

Pausa-consolidamento prima di Fase 4 (raccomandazione syst3m): 6 mesi minimum di operate-and-learn dopo Fase 3 chiusura. Non aggiungere nuovo scope finché lo stack reale non ha visto fault, recovery, drift. Pattern Lean: build → operate → learn → expand.

* opzionali — proseguire solo se le 4 fasi precedenti hanno mostrato uso reale che giustifica.

12 - Costi (Capex + Opex)

Capex (una tantum)

Recupero da dismissioni (parziale offset)

Capex netto effettivo: indicativamente zero o leggermente positivo (recuperi vendite >= acquisti). Il fatto che esca a "zero" e' dovuto alla densita' di hardware gia' presente.

Opex (mensile)

Equivalente annuo: ~310-400 EUR/anno.

13 - Operations e Manutenzione

Calendario tipico

Notifiche e alerting

• Uptime Kuma sul G8 replica: probe HTTPS su tutti gli hostname pubblici ogni 60 s
• Alert via Telegram bot privato + email backup
• Alert su backup falliti, certificati LE in scadenza, container restart loops
• Healthcheck.io self-hosted (futuro): dead-man-switch per cron pg-backup

Documentazione runbook

Mantenuta in repository Git privato GitHub: docker-compose.yml, .env.example, configurazioni, README di deploy passo passo, runbook DR. Il repo non contiene secrets (file .env e' gitignored).

Monthly homelab check — OPS-001..009 (audit homelab 2026-05-08)

Pattern industry homelab maturo: maintenance day mensile (~1 ora) per tenere a bada i piccoli rischi quotidiani che gli audit tecnologici non vedono (polvere, batterie, configs di rete). Identificato dall'audit homelab-architect.

Pattern: creare un calendar reminder ricorrente "homelab maintenance day" (1°/mese, ~1 ora) che esegue la checklist OPS-006 (quotidiano integrato altrove), OPS-007 (verifica scrub passato), OPS-008 (config export). OPS-001/002/003/004/009 sono trimestrali/annuali, agganciare a check del mese di apertura quarter. OPS-005 è one-time, fare entro Fase 3.

Plan B Cloudflare — exit strategy (mitigazione RA-001)

st4ck dipende da Cloudflare per 5 servizi: DNS, Tunnel, Pages (landing+docs), Access (Zero Trust auth), WAF. Compromissione/cambio policy/pricing 5x → blast radius enorme. Questo capitolo documenta le alternative OSS o low-cost per ciascuno, con stima effort di migrazione. Non è un piano di migrazione attivo: è la capability dormiente da poter attivare in 1-2 settimane se necessario.

Effort totale migrazione full-CF → self-hosted: ~5-7 giornate work. Il dossier contiene già il "codice originale" (Caddyfile + compose con blocchi commentati) per la maggior parte: non è "lock-in cementato", è "lock-in pragmatico". Trigger di attivazione Plan B: (a) CF cambia free tier in modo che renda costoso lo stack (>30 EUR/mese), (b) CF deprecata uno dei servizi che usiamo, (c) policy CF cambia in modo che colpisce dati famiglia (es. obbligo di scansione contenuti). Trigger di review: annuale, in coincidenza con re-run audit syst3m.

Bus factor mitigation — letter to family + DR runbook (RA-002)

st4ck è attualmente operato da una sola persona (Aldo). Se Aldo è indisponibile temporaneamente o permanentemente, la famiglia perde accesso ai dati propri. Mitigazione progressiva basata su 3 layer: documento accessibile, runbook step-by-step, persona di fiducia onboarded.

Cosa NON inserire nella letter: recovery key Restic/Kopia/B2 in plaintext (rischio compromissione fisica casa). Pattern raccomandato: passphrase Restic/Kopia generate da Vaultwarden via account "family-emergency" condiviso, accesso al quale è gated dietro la master Vaultwarden personale di Aldo (catena di accesso) + recovery key Vaultwarden in busta separata.

Effort iniziale stimato: letter L1 ~1 ora, runbook L2 ~4 ore (scrittura + test mentale per ogni scenario), L3 onboarding ~2 ore + ripetizione annuale. Status: tutti TODO. Priorità: chiudere L1+L2 prima di Fase 1 (vedi action items in §15).

Awareness training famiglia (audit c0mpl14nc3 ISO A.6.3)

Il modello di sicurezza st4ck prevede 4-6 utenti familiari come endpoint reali. Senza awareness training, ciascuno di loro è un vettore di phishing/social engineering che bypassa MFA e password manager. Necessario almeno una sessione "family security 101" nei primi 30 giorni post-Fase 1.

Effort: ~2 ore prima sessione + ~30 min refresh annuale per persona. Status: TODO. Priorità: dopo onboarding 2 utenti iniziali Fase 1.

DPA archive — vendor compliance documentation

Per i pochi vendor cloud che st4ck usa (Cloudflare, Backblaze, Mistral, Anthropic), conviene archiviare i Data Processing Agreement (DPA) versionati nel repo. In caso di domande di audit familiare ("dove vanno i miei dati?") o di incidente con il vendor, si ha il riferimento contrattuale a portata di mano.

Effort: ~30 min download + commit iniziale, ~30 min/anno review. Status: TODO. Cartella: docs/dpa/ da creare al primo commit.

14 - Decisioni e Rationale

ADR-light registry: ogni decisione architetturale ha ID stabile (D-NNN), data, status (ACTIVE / SUPERSEDED / DEFERRED), alternativa scartata, motivo. Raggruppate per area tematica.

Identita' & Auth

Application stack

Storage & Backup

Network & Hosting

Ops & Lifecycle

Riepilogo: 22 decisioni totali (ADR-light, raggruppate in 5 aree). Status: 21 ACTIVE / 1 SUPERSEDED (D-034 -> D-035 landing m41n a st4ck). Decisioni differite tracciate nella sub-sezione "Decisioni differite" di §15. Pattern industry: Architecture Decision Records (ADR) leggero, sufficiente per scala 1-persona. Date prima del 2026-05-03 = baseline pivot da DS718+ legacy.

15 - Open Questions e Next Steps

Stato avanzamento fasi

Snapshot al 2026-05-08. Aggiornato manualmente quando milestone completate. Per il backlog operativo dettagliato vedi backlog & next steps.

Output Fase 0 atteso: hardware G8 pronto + ordini hardware avviati + documentazione completa. Manca: A1 (acquisto hw key 2FA opzionale), A3 (NVMe move), A4 (BIOS), A5 (ordine HA Voice PE), A7 (enclosure backup). Vedi backlog Tier A.

Open questions per fase

ISSUE tracker — audit interno

Output cumulativo degli audit interni (vedi audit log): arch + perf (2026-05-06), cyb3r + c0mpl14nc3 (2026-05-07), refresh + syst3m (2026-05-08). Severity P0 = da chiudere prima di Fase 1; severity P1-P3 = differita ma tracciata.

Riepilogo: 14 ISSUE totali · 11 OPEN (di cui 5 P0 pre-Fase 1, 2 P0 differite a Fase 2/3, 2 P1 da audit homelab, 1 tracking, 1 P1 deferred) · 3 RESOLVED (006 PDF→HTML, 008 retention policy, 010 CF 2FA TOTP) · 0 DEFERRED. Top 2 P0 cronologicamente vincolati: #007 LUKS (Fase 1 step 1), #004 chattr +C Postgres (Fase 1 step 4). Nuove 2026-05-08 da audit homelab: #012 UniFi config backup, #013 UDM config backup, #014 HA Voice firmware rollback.

Dettaglio ISSUE (testo esteso)

Vedi action items dettagliati di ogni ISSUE nel testo originale qui sotto. Tabella sopra è il quick reference.

1. ISSUE-001 - Authentik Single Point of Failure di accesso. Se Authentik down, tutti gli 11 servizi diventano inaccessibili (no login). Manca procedura di emergenza. Action: aggiungere a §13 una sotto-sezione "Authentik down - procedura break-glass" che definisca: (a) container con utente locale admin pre-configurato in vault offline (Vaultwarden export su carta o YubiKey), (b) bypass temporaneo OIDC per servizi che lo permettono (Synapse, Vaultwarden, Paperless), (c) RTO target per ripristino Authentik < 30 min con restore Postgres da snapshot btrfs. Owner: Aldo. Deadline: prima di Fase 1.
2. ISSUE-002 - Failover cloudflared non documentato. §06 dichiara che gli hostname puntano "dinamicamente al tunnel attivo (sito A o B in caso di failover)" ma il meccanismo concreto non e' specificato. Action: esplicitare in §13 ops: (a) named tunnel cloudflared replicato sui due G8 con stesso UUID e credenziali, (b) priorita' di routing CF Tunnel via metric / weight, (c) detection del down (heartbeat?), (d) tempo medio di switchover. Aggiungere step in runbook DR di Fase 3. Owner: Aldo. Deadline: prima di Fase 3 (deploy del 2nd cloudflared).
3. ISSUE-003 - DB sprawl Postgres 14 vs 16-alpine. Blinko vincolato a PG14 dall'upstream, resto dello stack su PG16. Doppia superficie CVE, doppia immagine da pull, drift baseline. Action: a fine Fase 2, testare Blinko su PG16 in staging (Prisma di solito tollera). Se OK, collassare a singolo Postgres 16. Se NO, valutare alternative (Memos / Trilium) con compatibilita' PG16 nativa. Owner: Aldo. Deadline: fine Fase 2.
4. ISSUE-004 - chattr +C mancante su volume Postgres. btrfs CoW penalizza random write dei DB. Senza nodatacow sul subdir Postgres, latency commit -30/-50% rispetto al possibile. Action: nel runbook Fase 1 aggiungere step "mkdir /srv/data/postgres && chattr +C /srv/data/postgres" PRIMA del primo docker compose up. Trade-off accettato: niente snapshot btrfs sul subdir (i backup PG passano per pg_dump e Restic). Owner: Aldo. Deadline: Fase 1, step 4.
5. ISSUE-005 - Indici Mailpiler potenzialmente su NFS. Bind path indici (MariaDB + Sphinx/Manticore) deve forzatamente essere NVMe locale, non NFS DS720+ #1. Se finiscono su NFS, search query passa da sub-secondi a secondi. Action: in deploy Mailpiler (Fase 2), separare volume data/ (NFS, raw .eml) da volume indexes/ (NVMe /srv/data2). Documentare in runbook Fase 2. Owner: Aldo. Deadline: Fase 2.
6. ISSUE-006 - Rigenerazione PDF dossier manuale. RISOLTA 2026-05-08: il PDF e' stato eliminato dal progetto. La documentazione e' ora HTML statico (st4ck/dossier.html nel repo) servito direttamente da CF Pages, print-friendly via CSS @media print + bottone Stampa nella toolbar. Niente piu' rigenerazione, niente piu' file binari da committare, niente piu' drift HTML/PDF. Implicazione: per archiviare offline o stampare, l'utente usa il bottone Stampa del browser che produce un PDF print-on-demand A4 con stile light forzato.
7. ISSUE-007 - LUKS at-rest encryption (promosso da "decisioni differite" a P0 dopo audit cyb3r/c0mpl14nc3). NVMe del G8 oggi non cifrati a riposo: chiunque acceda fisicamente al disco (furto, manutenzione tecnica, smaltimento futuro) legge tutto in plaintext (vault, foto, mail, chat, secrets). Coperto sia da audit tecnico (cyb3r scenario S3) che da audit GDPR (art. 5(f) integrita' e riservatezza). Action: setup LUKS gia' in fase di install Ubuntu (step 1 di Fase 1, gia' aggiornato in §11). Passphrase salvata in 3 posti: YubiKey, safe fisico, Vaultwarden offline export. Trade-off: passphrase a ogni boot — accettato; se diventa fastidioso valutare TPM2-LUKS auto-unlock dopo Fase 1 stabile. Owner: Aldo. Deadline: Fase 1 step 1.
8. ISSUE-008 - Data retention policy esplicita per servizio. Stack mantiene foto/mail/chat for-ever senza policy scritta: rischio storage runaway + posizione difficile davanti a richiesta di cancellazione di un familiare (GDPR art. 5(c) minimizzazione + art. 5(e) conservazione limitata). Action: tabella retention introdotta in §08 del dossier (3 colonne: dati attivi, backup, log applicativi, per ognuno degli 11 servizi). Storage growth check semestrale. Owner: Aldo. Deadline: CHIUSO con v1.6. Estensione 2026-05-08 (v1.7): aggiunte 3 righe per il modulo j4rv1s (conversation 10gg, audit skill 30gg, episodic+semantic memory indefinita) come da decisione 8 design doc j4rv1s.
9. ISSUE-009 - Procedura off-boarding utente assente. Cosa succede quando un familiare esce dal sistema (separazione, figli adulti che vogliono autonomia, decesso)? Oggi: revoca Authentik basta lato login, ma residui dati personali in Synapse, Immich, Vaultwarden, Blinko, Mailpiler, Home Assistant, Kopia. GDPR art. 17 (diritto alla cancellazione). Action: scrivere docs/runbooks/offboarding.md come checklist runbook: (1) deactivate Authentik user, (2) Synapse POST /_synapse/admin/v1/deactivate/{user}, (3) Vaultwarden delete user, (4) Immich delete user (cascade album), (5) Blinko delete user, (6) Mailpiler purge mailbox, (7) HA delete person + recorder data, (8) Kopia delete repository entry, (9) export e consegna dati personali in archivio cifrato all'utente uscente prima della cancellazione. ETA per esecuzione: ~1 ora per utente. Owner: Aldo. Deadline: pre-Fase 2 (quando si onboarda 4 utenti, l'eventuale off-boarding diventa caso d'uso reale).
10. ISSUE-010 - Hardening account Cloudflare. Compromise dell'account CF = MITM totale di tutto lo stack (tunnel rerouted, certificate issuance, DNS hijack). Audit cyb3r scenario S1 = catastrofico. Action: (a) hardware key 2FA (YubiKey/Titan) come unico fattore secondario sul login CF, (b) email separata mai usata altrove (es. cf-st4ck@d0mus.com alias), (c) Certificate Transparency monitoring webhook con alert (es. Cloudflare Abuse Reports + crt.sh feed), (d) API token usato da Caddy ridotto a scope minimo Zone:DNS:Edit per d0mus.com (non account-wide), rotazione semestrale, (e) abilitare CF "User > Security > Login monitoring" con alert email su nuovo browser/IP. Owner: Aldo. Deadline: Fase 1 step 0 (prima ancora di qualsiasi deploy).
11. ISSUE-011 - Sequencing modulo j4rv1s vs fasi st4ck. Il modulo j4rv1s ha dipendenze incrociate non banali con la roadmap st4ck principale: (a) j4rv1s F0a (scaffold codice + blocchi compose/Caddyfile commentati) é eseguibile in Fase 0 di st4ck, (b) j4rv1s F0b (deploy container internal + OIDC client + DNS) richiede st4ck Fase 1 chiusa con Authentik+Caddy+cloudflared live, (c) j4rv1s F1 (voice loop) richiede in piú i 2× HA Voice PE fisicamente arrivati a casa (lead time Nabu Casa 2-4 settimane: ordinare in Fase 0), (d) j4rv1s F2 (brain + skill loader) richiede j4rv1s F1 chiusa + immagini custom j4rv1s-api/j4rv1s-worker buildate e pushate su GHCR. Action: rispettare l'ordinamento documentato nei nuovi sub-step di Fase 0/1/2 in §11. Trigger di rilascio dossier v1.8: al completamento di j4rv1s F2 aggiornare nuovamente §03/§05/§08 con stato post-deploy (decisione D4 design doc j4rv1s) - inclusi eventuali drift dalle stime (latency reale, opex misurato, skill aggiunte). Owner: Aldo. Deadline: sequenziamento implicito nelle fasi st4ck; nessuna scadenza esplicita oltre quelle già nelle fasi.

Risk register architetturale (audit syst3m, 2026-05-08)

Output dell'audit syst3m (system architecture specialist, lente 3-10 anni). Rischi long-term distinti dalle ISSUE operative sopra: le ISSUE si chiudono in giorni/settimane, i rischi RA si mitigano gradualmente nel tempo e non hanno deadline rigide.

Top 3 RA da mitigare entro Fase 1: RA-001 Plan B Cloudflare (~2 ore doc), RA-002 letter to family + DR runbook (~4 ore), RA-008 calendar reminder per review syst3m annuale (~5 min).

Decisioni differite (rivedere a fine Fase 2)

• Cifratura LUKS dischi: aggiungere o no? RISOLTA 2026-05-07: promossa a ISSUE-007 (P0 Fase 1 step 1) dopo audit cyb3r/c0mpl14nc3. Si fa LUKS sui due NVMe a install time.
• Replica anche dei film? Decisione: probabilmente NO (riacquisibili, alto volume)
• Deploy bridge Matrix (mautrix-whatsapp/signal/telegram)? Decisione: solo se chiesto da utenti
• Upgrade DS918+ a TrueNAS-on-commodity-hardware: solo se DSM diventa incompatibile in futuro
• Consolidamento Restic → Kopia (issue da audit, P1): Kopia parla nativo S3/B2 e ha gia' repository server in stack. Valutare se sostituire Restic con un Kopia repo policy "server-side" che copre sia endpoint che dati server. Riduce stack a 1 tool di backup. Decisione: a fine Fase 3 quando entrambi i repo sono in produzione e si puo' confrontare ergonomia retention policy.
• Passkey/WebAuthn in Authentik (issue da audit, P3): Authentik supporta nativamente. Aggiungere come fattore alternativo a TOTP per UX moderna e backup contro lock-out. Decisione: dopo onboarding 2 utenti iniziali, abilitare passkey opzionale.
• AdGuard wildcard *.d0mus.com (issue da audit, P2): ridurre i ~11 override individuali a 1 wildcard + eccezioni (w3b su CF Pages). Decisione: dopo deploy completo Fase 2 quando lista servizi e' stabile.
• AdGuard secondary su DS720+ #1 (issue da audit, P1): DNS HA, router con primary+secondary. Decisione: insieme a riconfigurazione DS720+ #1 in Fase 2.
• Split docker-compose per dominio applicativo (issue da audit, P1): da monolitico a compose.identity.yml + compose.chat.yml + ecc. Riduce blast radius degli update. Decisione: a fine Fase 2, quando lo stack monolitico avra' raggiunto ~12 servizi e il refactor sara' giustificato.
• Image signing + SBOM tracking (issue da audit cyb3r, P3): oggi le immagini Docker sono pull con tag mobili (latest, stable) e nessuna verifica firma. Watchtower auto-update amplifica il supply chain risk. Pattern industry 2025+: Sigstore/cosign per image signing, Syft per SBOM generation, Grype per CVE scanning. Decisione: introdurre in Fase 4 quando Watchtower passa a notify-only e si pinnano i tag a digest immutabili. Effort: ~1 giornata setup pipeline + cron settimanale.
• GPU dedicata per Immich ML / j4rv1s STT (issue da audit perf, P3): oggi face recognition Immich + Whisper STT girano su CPU 11th gen del G8. Latency accettabile ma non ottimale (inferenza Whisper large-v3 1000-1500ms su CPU vs 300-500ms su GPU consumer). Opzioni hardware: Intel Arc A310 (~150 EUR, supportata Vulkan), NVIDIA T1000 (~200 EUR, CUDA pieno). Decisione: a fine Fase 4 se libreria Immich grande (>100k foto) o se opex j4rv1s rivela bottleneck STT.
• Service node LLM dedicato (modulo j4rv1s, decisione D2): oggi LLM locale gira su CPU del G8 (Llama 3.1 8B Q4 a ~5-8 t/s). Riapri se opex cloud Mistral/Anthropic supera 30 EUR/mese o se servono modelli 14B+ in realtime. Tre opzioni tracciate:
  • Minisforum N5 (~1500 EUR): AMD Ryzen AI 9 HX 370 + 32GB DDR5 + 1TB NVMe. Linux nativo, integrazione diretta nel docker-compose monolitico st4ck, x86 + ROCm/Vulkan per inferenza. Ventilato (~25-80W). Inferenza Llama 8B Q4 ~12-15 t/s. Coerente col modello mentale "tutto Linux + tutto Docker" del resto dello stack.
  • Mac mini M4 base ricondizionato (~800 EUR, 24GB unified / 512GB SSD): chip Apple M4 + Neural Engine 38 TOPS. Fanless silenzioso (~5-35W). Stack llama.cpp + MLX framework Apple-optimized → inferenza Llama 8B Q4 ~30-40 t/s (2-3x N5). Trade-off: macOS rompe "tutto Linux", Docker non nativo (Colima/OrbStack), accoppiamento debole con st4ck (j4rv1s-api distribuito su 2 nodi via REST+tailnet invece che via apps-net). Ottimo per Whisper STT acceleration via Metal.
  • Mac mini M4 Pro ricondizionato (~1250 EUR, 24GB unified / 512GB SSD): M4 Pro 12-core CPU + GPU 16-core. Inferenza Llama 8B Q4 ~50-70 t/s, Mistral 22B Q4 ~22-28 t/s. Stesso trade-off macOS dell'M4 base, con room di crescita verso modelli 14-22B realtime. Niente 70B (servirebbe M4 Max 64GB+, ~3000 EUR — fuori scope).
  Recommended in caso di riapertura: Mac mini M4 base 24GB/512GB ricondizionato (sweet spot prezzo/prestazioni, costo dimezzato rispetto a N5, inferenza piu' veloce, consumi 1/3). Decisione finale: a uso reale post-Fase 2, dopo aver misurato opex cloud effettivo e profilo di utilizzo skill.

Action items immediati per Aldo

Source of truth completo in Backlog & Next Steps. Qui solo Tier A (pre-Fase 1) e Tier B (documenti fuori dossier) per cross-reference.

Top 5 ranked: H1 (verifica CF Pages dashboard), A2 (CF account hardening), B1+B2 (Letter+DR runbook), A3+A4+A5 (hardware Fase 1), D5 (j4rv1s F0a scaffold). Vedi backlog per Tier C-H completi.

Appendice A - Inventario Completo

Hardware compute

Storage NVMe / SSD

Storage NAS

Hardware di rete

BOM modulo j4rv1s — edge satelliti

Opex j4rv1s mensile (run-rate stimato): Mistral Small 3.x EU 2-4 EUR (default L3, ~140 req/g con prompt cache), Claude Haiku 4.5 1-3 EUR (L4 ~6 req/g), Claude Sonnet 4.6 0-2 EUR (L5 on-demand), energia G8 +10W ~2 EUR + 2× satelliti +6W ~1 EUR. Totale: 6-12 EUR/mese con Piper TTS locale; +5 EUR se ElevenLabs Starter abilitato come opt-in skill premium.

Software stack a regime

// FINE DOCUMENTO //
st4ck.d0mus.com - Project Dossier v2.11
Aggiornato 2026-05-08 (v2.11: cover refresh con 3 meta-card colorate per stato/owner/architettura, KPI card upgrade (accent bar laterale + emoji icon + hover lift), TOC indice cliccabile (16 link interni a #sec-NN), fix "VERSIONE 2.2" obsoleto. Vedi changelog completo in cover.)
Documento privato Aldo Brunello