Audit infrastruttura 2026-07-01

Audit eseguito il 2026-07-01 su obelica-prod in modalita read-only.

Scopo: capire quanto l'infrastruttura e' pronta a sostituire progressivamente Vercel, Neon e servizi esterni simili per i progetti cliente, e quali interventi rendono Obelica una piattaforma dedicata affidabile.

Perimetro

Controlli eseguiti senza stampare valori segreti:

• host, OS, disco, memoria, pacchetti e reboot richiesto;
• Docker, Compose, container, reti, immagini e build cache;
• Traefik, porte pubbliche, router e domini production/staging;
• Forgejo, runner, docs e repository locali;
• backup locale/offsite e stato ultimo job;
• crontab, cron applicativi, monitoraggio e log principali;
• inventario env solo per nomi/categorie di provider, non valori;
• validita della documentazione Fumadocs e navigazione meta.json.

Non sono stati cambiati DNS, database, backup, servizi systemd o segreti.

Stato sintetico

Valutazione globale attuale: 78/100.

L'infrastruttura e' gia utilizzabile per migrazioni controllate app per app. Non e' ancora una piattaforma pienamente autonoma e ripetibile per sostituire Vercel/Neon su scala clienti senza ulteriori hardening.

Evidenze principali

Host e risorse

• Provider: DigitalOcean Droplet in FRA1.
• OS: Ubuntu 24.04.4 LTS, kernel 6.8.0-124-generic.
• Disco root: 77 GB, circa 35 GB usati, 42 GB liberi, 46%.
• RAM: 3.8 GiB totali, circa 2.4 GiB disponibili al momento dell'audit.
• Swap: 2.0 GiB totali, circa 965 MiB usati.
• Pacchetti aggiornabili presenti: Docker 29.6.1/Compose 5.2.0 e update security libnss3, libsqlite3-0.
• Nessun reboot richiesto.

Docker runtime

• Container running: 21.
• Immagini: 12.95 GB, reclaimable 4.826 GB.
• Build cache: 2.377 GB.
• Solo forgejo-db ha healthcheck Docker nativo.
• I container usano restart: unless-stopped, ma non hanno limiti memory, cpus, pids_limit o read_only.
• Forgejo e' il container piu pesante: circa 1.6 GiB al momento dell'audit.

Routing e domini

• Porte pubbliche attese: 22, 80, 443.
• Dashboard Traefik: 127.0.0.1:8080.
• Forgejo: 127.0.0.1:3333.
• Docs: 127.0.0.1:3334.
• Tutti i domini staging *.vps.obelica.com controllati dallo smoke test sono verdi.
• Router production gia presenti su Traefik:
  • tulpastudio.com, www.tulpastudio.com;
  • otticastyleorsola.it, www.otticastyleorsola.it.

Backup

• Ultimo backup locale: /opt/obelica/backups/auto/20260630-040001.
• Stato: OK.
• Manifest offsite verificato su Spaces.
• Retention locale: 1 snapshot.
• Gap residui gia noti:
  • definire retention remota su Spaces;
  • cifrare anche repos.tar.zst, oggi non cifrato.

Database e dipendenze esterne

Classificazione senza stampare URL o credenziali:

Conclusione: la migrazione fuori da Neon e' in gran parte gia avvenuta verso DigitalOcean Managed Postgres, ma questo non equivale ancora a una piattaforma database personale. Se l'obiettivo e' ridurre anche il managed DB, serve un progetto Postgres proprietario con ruoli, backup, PITR, pooling, restore e monitoraggio.

Cron e automazioni

Crontab reale al momento dell'audit:

• backup giornaliero alle 04:00;
• health check ogni 5 minuti;
• cron applicativi Wash Dog alle 05:00, 09:00, 10:00, 11:00;
• cron Tulpa mensile;
• cron Sonja giornaliero con || true per tollerare timeout SMTP;
• Docker cleanup alle 02:00.

Gap: la pagina operations/cron-jobs dichiarava i cron applicativi in pausa. Lo stato reale e' diverso e va governato come produzione.

Monitoraggio

Presente:

• health check Bash ogni 5 minuti;
• alert Telegram con deduplicazione;
• bot Telegram interattivo;
• smoke test staging globale;
• log rotation Docker.

Gap:

• nessuna serie storica di metriche;
• nessun SLO/uptime per app cliente;
• nessun alert per singolo cron fallito se l'output non viene trasformato in stato;
• monitor.log mostra righe duplicate, probabilmente per uso combinato di tee -a nello script e redirection crontab sullo stesso file.

Sicurezza

Punti positivi:

• SSH password login e root login disabilitati nella config leggibile;
• servizi admin su loopback;
• secret principali con permessi corretti;
• Traefik exposedbydefault=false;
• Forgejo e docs privati via tunnel.

Punti da chiudere:

• doctl non disponibile sul server, quindi Cloud Firewall non verificato da CLI;
• UFW/fail2ban/effective sshd -T richiedono sudo o verifica manuale;
• utente bona nel gruppo docker, quindi root-equivalent;
• Traefik legge il Docker socket host;
• runner Forgejo docs monta /opt/obelica, da trattare come componente privilegiato;
• nessun hardening container con filesystem read-only o limiti risorse.

Repository e documentazione

Repo locali:

• tutte le app principali risultano pulite tranne ottica-style con 1 modifica non committata;
• obelica-docs ha modifiche non committate e due nuove pagine migrazione gia presenti;
• obelica-docs e' la fonte di verita, ma molte pagine snapshot sono ferme al 2026-06-24.

Problemi documentali rilevati:

• current-state non riflette pienamente cron attivi, cutover Ottica e stato 2026-07-01;
• services/apps descrive tutte le app come candidate staging e alcuni DB come DigitalOcean anche per app senza DB;
• operations/cron-jobs non rispecchia il crontab reale;
• alcune pagine esistenti non erano presenti nei rispettivi meta.json e quindi rischiavano di non comparire in navigazione: monitoring, cron-jobs, autodeploy, cutover-tulpastudio, obelica-backup, certificates.

Rischi critici

1. Single droplet senza piano HA Backup e restore sono buoni, ma un incidente sul droplet richiede ricostruzione manuale. Per clienti production serve almeno runbook di rebuild e obiettivo RTO/RPO esplicito.

2. Piattaforma DB non ancora proprietaria L'uscita da Neon e' quasi completata verso DigitalOcean Managed Postgres, ma il requisito strategico e' infrastruttura personale. La decisione va formalizzata: managed DO come compromesso accettato oppure Postgres self-hosted con oneri operativi completi.

3. Verifica sicurezza non probante La shell conferma poche superfici pubbliche, ma non prova Cloud Firewall, UFW, fail2ban e configurazione SSH effettiva. Va creato un comando/procedura che produca evidenza ripetibile.

4. Cron production attivi ma governance incompleta I cron applicativi sono attivi e scrivono log, ma manca stato per-job, alert per fallimento e documentazione allineata.

5. Container senza healthcheck e resource policy Un container puo essere running ma non sano. Inoltre un'app o Forgejo possono consumare RAM senza limiti e degradare le altre app.

6. Osservabilita insufficiente per molti clienti Health check e Telegram bastano per bootstrap, non per capire trend, saturazione, errori applicativi, cron falliti e incidenti post-migrazione.

Rischi non critici ma importanti

• residui Vercel env diffusi in quasi tutti gli env app;
• token Vercel Blob ancora presenti in app gia parzialmente migrate a Spaces;
• dipendenza @neondatabase/serverless ancora presente in Wash Dog;
• production router misti staging/production da documentare app per app;
• pagine Fumadocs non sempre indicizzate nei meta.json;
• update Docker/security disponibili ma non urgenti;
• repos.tar.zst backup non cifrato;
• monitor.log duplicato;
• assenza di registry immagini e release artifact versionati.

Priorita consigliata

P0 - Entro 24 ore

1. Allineare documentazione navigabile: audit, roadmap, cron reali e production router attivi.
2. Verificare Cloud Firewall DigitalOcean da pannello o workstation con doctl.
3. Decidere se i cron applicativi attuali sono production-intent o vanno sospesi fino a governance completa.
4. Documentare stato cutover per tulpastudio.com e otticastyleorsola.it.
5. Aggiornare current-state dopo il cutover Ottica e l'audit.

P1 - Entro 7 giorni

1. Aggiungere health endpoint e Docker healthcheck alle app dinamiche.
2. Aggiungere limiti risorse minimi ai container piu importanti.
3. Creare obelica cron status con stato ultimo run per job.
4. Ripulire env Vercel residue o classificarle come compatibilita intenzionale.
5. Definire policy DB: Managed Postgres accettato o Postgres self-hosted.

P2 - Entro 30 giorni

1. Standardizzare CI/CD Forgejo per tutte le app.
2. Creare registry o naming release immagini con rollback rapido.
3. Aggiungere metriche storiche e dashboard privata.
4. Implementare retention remota backup e cifratura repos.tar.zst.
5. Eseguire drill restore periodico documentato.

P3 - Entro 90 giorni

1. Separare staging e production in modo piu netto.
2. Valutare secondo droplet o standby restore per clienti critici.
3. Introdurre socket proxy Docker e hardening container.
4. Portare ogni app a scheda production completa con RTO/RPO, domini, DB, storage, cron e rollback.

Esito

Obelica e' gia oltre il semplice VPS artigianale: ha Traefik, Forgejo, backup offsite, smoke test, deploy Rust, docs e monitoraggio. Il salto successivo non e' installare altri tool a caso, ma trasformare questi pezzi in un contratto operativo ripetibile per ogni cliente: app contract, DB contract, cron contract, deploy contract, backup/restore contract e observability contract.