Deploy automatico su Coolify da CodeCommit (EventBridge)¶

Come funziona il deploy automatico di qAlarm su Coolify dev e come replicarlo sugli altri progetti. Configurazione letta con la AWS CLI in sola lettura il 28/10/2026 (account 407138933921, regione eu-west-1).

Come funziona¶

flowchart LR
  DEV[git push sul branch deploy_dev] --> CC[CodeCommit<br/>qAlarm2_be / qAlarm2_fe]
  CC -- "evento: CodeCommit Repository State Change" --> EB[EventBridge<br/>regola qalarm-*-deploy-dev]
  EB -- "corpo: {uuid, force}" --> AD[API destination<br/>qalarm-coolify-dev-deploy]
  AD -- "POST + header Authorization" --> CO[Coolify dev<br/>/api/v1/deploy]
  CO --> APP[build e deploy della risorsa]

Hold "Ctrl" to enable pan & zoom

Un push su deploy_dev genera in CodeCommit un evento "CodeCommit Repository State Change" (referenceUpdated).
Una regola EventBridge filtra repository, tipo di riferimento e nome del branch.
Il target della regola è una API destination: EventBridge fa una POST https://coolify.dev.bsqdev.uk/api/v1/deploy con il corpo {"uuid": "<uuid risorsa Coolify>", "force": false}.
L'API destination usa una connection con autenticazione API_KEY: header Authorization con il token API di Coolify (Bearer <token>). Il token è conservato da EventBridge in Secrets Manager e non compare nelle descrizioni.
Coolify avvia il deploy della risorsa indicata dall'uuid (build da git, come da configurazione della risorsa).

Non c'è nessun trigger CodeCommit né SNS: è tutto EventBridge.

Componenti attuali¶

Componente	Nome	Dettagli
Regola backend	`qalarm-be-deploy-dev`	bus `default`; pattern: `source = aws.codecommit`, `detail-type = CodeCommit Repository State Change`, `resources = …:qAlarm2_be`, `event = referenceUpdated`, `referenceType = branch`, `referenceName = deploy_dev`
Regola frontend	`qalarm-fe-deploy-dev`	come sopra, repository `qAlarm2_fe`
Target (corpo)	—	backend `{"uuid": "xwb64hvh1hx3pz7vtgayibx8", "force": false}` (Coolify: QAlarm - BE - DEV / dev); frontend `{"uuid": "vtxee22uwvszmt3gvto36e0f", "force": false}` (QAlarm - FE - DEV / qAlarm FE dev)
API destination	`qalarm-coolify-dev-deploy`	`POST https://coolify.dev.bsqdev.uk/api/v1/deploy`, massimo 1 chiamata al secondo, creata il 20/10/2026
Connection	`qalarm-coolify-dev-deploy`	`API_KEY`, nome header `Authorization`, stato `AUTHORIZED`
Ruoli IAM	`service-role/Amazon_EventBridge_Invoke_Api_Destination_1696033803` (BE), `…_648791786` (FE)	entrambi permettono solo `events:InvokeApiDestination` su `api-destination/qalarm-coolify-dev-deploy/*`

Funziona: negli ultimi 14 giorni (al 28/10) ogni regola ha avuto 1 invocazione e nessun errore (metriche AWS/Events Invocations e FailedInvocations).

L'API destination, la connection e i ruoli non sono specifici di qAlarm: puntano all'istanza Coolify dev e si possono riusare per qualsiasi risorsa della stessa istanza. Per un nuovo progetto basta una nuova regola con il suo target.

UUID delle risorse su Coolify dev (28/10/2026)¶

Progetto Coolify	Risorsa	UUID	Repository / branch
QAlarm - BE - DEV	dev	`xwb64hvh1hx3pz7vtgayibx8`	`qAlarm2_be` / `deploy_dev` (già automatico)
QAlarm - FE - DEV	qAlarm FE dev	`vtxee22uwvszmt3gvto36e0f`	`qAlarm2_fe` / `deploy_dev` (già automatico)
MDM-MidServer	stage	`cosyzg1t9yv2pjqdur6qn53j`	`mdm_mid_server` / `refactor/v1` (docker compose)
MDM-Midpanel	dev	`ptbstm0l3kno4c9kttda9lcd`	`mdm_web_panel` / `dev`
MDM-Midpanel	midpanel-dev	`njif37x45r8fx0yncfk4vr12`	ferma
Monitoring	monitoring-dev	`dcspaeqcnu10nx12l000lh7f`	—

Gli UUID si leggono anche dalla URL della risorsa nel pannello di Coolify o con list_resources dell'MCP coolify-dev.

Replicare su un altro progetto¶

Esempio: midserver v3 (mdm_mid_server, risorsa cosyzg1t9yv2pjqdur6qn53j).

0. Decidere il branch¶

Il deploy parte a ogni push sul branch scelto. Conviene un branch dedicato al deploy (come deploy_dev per qAlarm), su cui si fa merge quando si vuole aggiornare il dev, invece del branch di lavoro. Il branch della regola deve essere lo stesso configurato nella risorsa Coolify, perché Coolify costruisce il branch della risorsa, non quello dell'evento.

1. Regola EventBridge¶

Console: EventBridge → Rules → Create rule (bus default, "Rule with an event pattern") con questo pattern:

{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Repository State Change"],
  "resources": ["arn:aws:codecommit:eu-west-1:407138933921:mdm_mid_server"],
  "detail": {
    "event": ["referenceUpdated"],
    "referenceType": ["branch"],
    "referenceName": ["refactor/v1"]
  }
}

CLI equivalente:

aws events put-rule \
  --name mdm-midserver-deploy-dev \
  --description "Deploy automatico del midserver v3 su Coolify dev" \
  --event-pattern file://pattern-midserver.json

Aggiungere "referenceCreated" a event se il deploy deve partire anche alla creazione del branch.

2. Target: l'API destination esistente¶

Console: target EventBridge API destination → qalarm-coolify-dev-deploy; Configure target input → Constant (JSON text): {"uuid": "cosyzg1t9yv2pjqdur6qn53j", "force": false}; ruolo: uno dei due esistenti oppure "crea nuovo ruolo".

CLI equivalente (targets-midserver.json):

[
  {
    "Id": "coolify-dev-deploy",
    "Arn": "arn:aws:events:eu-west-1:407138933921:api-destination/qalarm-coolify-dev-deploy/37a21a64-c726-42b5-b600-2f28a4141d42",
    "RoleArn": "arn:aws:iam::407138933921:role/service-role/Amazon_EventBridge_Invoke_Api_Destination_1696033803",
    "Input": "{\"uuid\": \"cosyzg1t9yv2pjqdur6qn53j\", \"force\": false}"
  }
]

aws events put-targets --rule mdm-midserver-deploy-dev --targets file://targets-midserver.json

3. Verifica¶

Push di un commit innocuo sul branch.
In Coolify: Deployments della risorsa, o list_deployments dell'MCP.
In CloudWatch: metriche AWS/Events → Invocations e FailedInvocations per la regola.
Se FailedInvocations sale: controllare il token della connection (scaduto o revocato in Coolify), l'UUID nel corpo e la raggiungibilità di coolify.dev.bsqdev.uk.

Altri progetti candidati¶

Repository	Risorsa Coolify	Branch suggerito	Note
`mdm_mid_server`	`cosyzg1t9yv2pjqdur6qn53j`	`refactor/v1` oppure un `deploy_dev` dedicato	risorsa docker compose: il deploy riavvia tutto lo stack (anche MySQL, Redis, Mosquitto, OME)
`mdm_web_panel`	`ptbstm0l3kno4c9kttda9lcd`	`dev`	la configurazione è dentro l'immagine (M13)

Attenzioni¶

Token di Coolify: il token API nella connection può fare deploy su tutte le risorse che il suo utente vede. Va creato con il minimo dei permessi (solo deploy) e ruotato aggiornando la connection (EventBridge → API destinations → Connections → Edit). Non va scritto in documenti o repository.
Nessun controllo prima del deploy: ogni push sul branch va in deploy, anche se i test non passano. Per qAlarm il branch dedicato deploy_dev fa da filtro.
Nessuna dead-letter queue né retry policy personalizzata sui target: valgono i default di EventBridge. Un deploy fallito si vede solo in Coolify e nelle metriche.
force: false: Coolify può riusare la cache di build. Usare true solo se serve una ricostruzione completa.
Due ruoli IAM identici: la console ne ha creato uno per regola. Per i nuovi target conviene riusare un ruolo esistente o crearne uno con nome chiaro (es. eventbridge-coolify-dev-deploy).
Coolify di prod: se nascerà un'istanza separata (decisione P1), servono una nuova connection e una nuova API destination verso il suo URL, con un token diverso. Per la prod è preferibile il deploy da immagini ECR con tag (build in CodeBuild, poi chiamata a Coolify), così si deploya solo ciò che è stato costruito e testato.