Coolify dev (VM 200 MidServerDEV)¶

Fonte: Coolify MCP in sola lettura, 27/10/2026; note in raw/altro.txt.

VM 200, IP 170.10.0.107, pubblico 185.31.66.187, VPN 172.16.16.252.
Coolify 4.5.0, un solo server (localhost), proxy Traefik v3.6 con Let's Encrypt (HTTP challenge). Dashboard: https://coolify.dev.bsqdev.uk.
Tutte le risorse sono build da git (CodeCommit), nessuna immagine da ECR. Nessun healthcheck di Coolify attivo.
Deploy automatico a ogni commit solo per qAlarm BE e FE (branch deploy_dev), tramite EventBridge → API destination → POST /api/v1/deploy di Coolify. Gli altri servizi vanno ridistribuiti a mano. Dettagli e replica: deploy-automatico-coolify.md.
È anche il server "di prova" usato in passato per qAlarm.

Risorse¶

Risorsa	Branch	Tipo	Stato	Domini (`*.bsqdev.uk`)
MDM-MidServer / refactor-v1	`refactor/v1`	docker compose (`docker-compose.coolify.dev.yml`)	running	`mdm.dev.midserver`, `mdm.dev.mqtt`, `mdm.dev.ome:3333`, `mdm.dev.db` (phpMyAdmin), redis exporter
MDM-MidServer / dev branch	`dev` (Flask)	docker compose	fermo dal 10/06/2026	—
MDM-Midpanel / dev	`dev`	Dockerfile, `3000:80`	running	`mdm.dev.midpanel`
MDM-Midpanel / midpanel-dev	—	—	fermo	—
QAlarm BE / dev	`deploy_dev`	docker compose	running	`mdm.dev.qalarm.backend`, redis exporter
QAlarm FE / qAlarm FE dev	`deploy_dev`	Dockerfile	running	`mdm.dev.qalarm.panel`
Monitoring / monitoring-dev	`dev` (repository `monitoring`)	docker compose (`docker-compose.base.yml` + `deploy/compose/coolify/dev.yml`)	running	`mdm.dev.monitoring` (Grafana), `mdm.dev.monitoring.loki`, `mdm.dev.monitoring.tempo`, `mdm.dev.monitoring.tempo.otlp` (scheda)

Aggiornamento del 28/10/2026 (MCP): la risorsa del midserver v3 si chiama ora stage (progetto MDM-MidServer, UUID cosyzg1t9yv2pjqdur6qn53j, branch refactor/v1, docker-compose.coolify.dev.yml); la risorsa Flask "dev branch" non esiste più. Le altre risorse: QAlarm BE xwb64hvh1hx3pz7vtgayibx8, QAlarm FE vtxee22uwvszmt3gvto36e0f, Midpanel dev ptbstm0l3kno4c9kttda9lcd, midpanel-dev (ferma) njif37x45r8fx0yncfk4vr12, Monitoring dcspaeqcnu10nx12l000lh7f.

Limiti attuali¶

Il pannello dev punta alla v3: le funzioni mancanti nella v3 non funzionano in dev (parità).
Redis senza volume nel compose dev; immagini con tag latest.
Essendo risorse "docker compose", nessuna ha il rolling update.
Traefik pubblica anche la porta 8080: in un Coolify di prod andrebbe tolta (conflitto con ewelink se installato su ServerIT).
Ci sono box di dev/stage che mandano comunque il video all'OME di prod (IP nel codice, M15).
Non è noto un box di test collegato stabilmente al dev: va predisposto (attività del piano).

Accesso via MCP¶

È configurato un server MCP coolify-dev per gli agenti: le azioni distruttive richiedono conferma esplicita dell'utente.

Tentativo di deploy qAlarm del 28/10/2026¶

Deploy del solo backend qAlarm dev, richiesto dall'utente, sul branch deploy_dev, commit 46ba96796770bbf0e9804cb72d6c08e4fb124ec4. Tentativo t1sdzkg1q488flxigztjjt4c, terminato con errore alle 11:57:45 CET.

Il pull preliminare che aveva bloccato il tentativo del 20/10 viene ora saltato grazie alla gestione del comando di build personalizzato.
Il nuovo tentativo arriva all'avvio e fallisce per il nome qalarm-redis già occupato. I container principali esistenti non erano stati riconosciuti tra quelli da sostituire.
qbackend, q-worker e qalarm-redis restano in esecuzione, creati il 18/06 e avviati dal 01/07. Backend e worker dichiarano SOURCE_COMMIT=41c8f5c15e004d8f1eb451bc9a5b2a5265b3c13a nelle variabili di avvio; non sono stati aggiornati al commit del tentativo.
Ai tre container manca coolify.applicationUuid; il progetto Compose è dtj9tw7bq7uoazhg0zwccamr, diverso dall'UUID della risorsa. I nomi fissi derivano dall'override docker-compose-dev.yml. I filtri attuali di Coolify non li associano correttamente alla risorsa.
Il tentativo rimuove i precedenti exporter e promtail e lascia un nuovo promtail in stato created. Sono stati ripristinati i soli servizi redis-exporter e promtail dalla configurazione salvata, con --no-deps e il progetto del tentativo. Entrambi risultano poi avviati, con suffisso 20261028T105700.
Dopo il fallimento, l'API /openapi.json risponde 200 e l'handshake Socket.IO riesce. Non sono state eseguite prove di elaborazione eventi o di login.

Nessuna modifica al codice o alle impostazioni Coolify. Prima di un altro deploy serve riallineare progetto Compose, identificazione dei container e nomi personalizzati, preservando i volumi esistenti. Lo stato aggregato Coolify non basta a descrivere i container realmente attivi.

Correzione del deploy qAlarm e conservazione Redis del 28/10/2026¶

Intervento successivo autorizzato dall'utente sul solo qAlarm dev. Il deploy finale fyx6gahgtnh8t0kujjyubtnt del commit 46ba96796770bbf0e9804cb72d6c08e4fb124ec4 termina correttamente alle 12:27:46 CET.

Configurazione applicata¶

Entrambi i comandi personalizzati usano ora il nome progetto stabile, uguale all'UUID dell'applicazione:

# Custom Build Command
docker compose --project-name xwb64hvh1hx3pz7vtgayibx8 --profile redis -f docker-compose.yml -f docker-compose-dev.yml build app worker

# Custom Start Command
docker compose --project-name xwb64hvh1hx3pz7vtgayibx8 -f docker-compose.yml -f docker-compose-dev.yml --profile redis up app worker redis redis-exporter promtail -d

È inoltre attiva Preserve repository during deployment (is_preserve_repository_enabled=true). Il compose dev monta il repository su /app: senza questa opzione il bind puntava alla directory temporanea /artifacts/<deployment_uuid>, nascondendo il codice dell'immagine. Il primo deploy con progetto corretto (j6h7jawlboqwwatcqx0sf5bc) terminava come job, ma backend e worker andavano in riavvio perché non trovavano main e worker_main.py.

Con la conservazione del repository, il bind di backend e worker punta a /data/coolify/applications/xwb64hvh1hx3pz7vtgayibx8. La configurazione è supportata dalla documentazione Coolify sui bind dal repository. Non sono stati modificati i file sorgente del repository applicativo.

Dati Redis e backup¶

Redis 8.8.0, con AOF attivo; stessa immagine e stessa password prima e dopo.
Volume dati riutilizzato: xwb64hvh1hx3pz7vtgayibx8_redis-data, montato su /data.
Conteggio prima e dopo il deploy: 8 chiavi nel DB 0, nessuna con scadenza.
Backend e worker sono stati fermati prima del salvataggio finale. Lo snapshot RDB è stato verificato con redis-check-rdb: 8 chiavi lette, nessuna scaduta.
Sul server dev, nella directory privata /root/qalarm-dev-backups/20261028T111946Z/, restano dump.rdb (900 byte), redis-data.tar.gz (17.506 byte, copia del volume fermo inclusi AOF), manifest.json e i riferimenti dei vecchi container in containers.json. Directory accessibile solo a root; file di backup con permessi 600.
SHA-256 dello snapshot: 809fe1282eb65ed2b59170218ed995879faae6e2f81a2edd465e04d895f1fc7c.
SHA-256 dell'archivio del volume: a4274cbf8eb3690cf670302897514b119cd62312f8eddf20ff844a233ae1ee86.

Le vecchie istanze sono state conservate ferme durante la verifica, poi rimosse senza rimuovere volumi, perché le loro etichette continuavano a far risultare l'applicazione degradata. Le vecchie immagini applicative non erano più disponibili nel daemon: il rollback alla vecchia revisione richiede una nuova build dal commit registrato, non l'avvio di quei vecchi container. Il backup dei dati Redis rimane disponibile.

Esito verificato¶

qbackend, q-worker, qalarm-redis, exporter e promtail avviati, con zero riavvii al controllo.
Tutti i nuovi container appartengono al progetto Compose xwb64hvh1hx3pz7vtgayibx8.
Coolify legge i log dei servizi app, worker e redis tramite service_name, senza i precedenti 404.
API /openapi.json: 200; handshake Socket.IO: 200; richiesta anonima a /user/self/details: 403.
Stato aggregato Coolify dopo la pulizia: running:unknown. Nessuno dei cinque container definisce un health check Docker; questo stato non equivale a una validazione funzionale completa.
Non eseguite prove di login, elaborazione di allarmi, chat o video, né un ripristino del backup in un'istanza separata. Produzione, midserver e box dei clienti non sono stati modificati.