La sovranità digitale è facile da proclamare e costosa da operare. La scorsa primavera abbiamo costruito Fortitudex, un’app di card collezionabili dedicata alla Convention del nostro Gruppo: tre progetti distinti, alcune centinaia di utenti concorrenti e una scadenza prefissata.
La strada più rapida sarebbe stata delegare a tre piattaforme SaaS americane e concludere il setup in un weekend. Abbiamo scelto un percorso alternativo, eseguendo l’intero progetto su un PaaS self-hosted, su un’infrastruttura da noi controllata.
Il divario tra una policy e una git push
Fortitude Group è sempre stata esplicita nel considerare la sovranità digitale come posizionamento strategico: autonomia e controllo sulla localizzazione dei workload, senza sacrificare la velocità di innovazione. Questa discussione avviene tipicamente a livello dei sistemi critici, quelli sottoposti a verifiche di conformità, mappati e sottoposti al comitato di compliance.
Le dipendenze, tuttavia, tendono a concentrarsi altrove. Si accumulano nel progetto interno non sottoposto ad audit specifici: una demo, uno strumento interno o, come in questo caso un’app per un evento aziendale. Nessuno redige un data residency assessment per questi. Qualcuno apre un laptop, connette una repository a una piattaforma di hosting ed entro il pomeriggio codice, build log, database e comunicazioni in uscita del progetto risiedono presso tre vendor in due giurisdizioni, sotto accordi click-through.
Replicate questa dinamica per tutti i progetti secondari in un’azienda IT e il risultato è la vostra effettiva posizione in termini sicurezza, molto spesso diversa da quella descritta nei documenti di policy.
Cosa non eravamo disposti a rinunciare
Noi del team dedicato alla creazione dell’app non abbiamo cercato un semplice “on-premise migration”. Volevamo preservare l’esperienza developer che rende le piattaforme SaaS la scelta predefinita, modificando solo il luogo di esecuzione.
L’elenco è esiguo e l’abbiamo trattato come non negoziabile:
- Ambiente di preview per ogni pull request, con URL dedicato
- Deploy al push, senza intervento manuale
- Certificati TLS e DNS gestiti dalla piattaforma, non da amministratori
- Rollback in tempo inferiore al tempo di incident reporting
Questo ha implicazioni significative. Una strategia di sovranità che degrada le performance di sviluppo non sopravvive al primo deadline critico: viene silenziosamente aggirata e l’organizzazione paga comunque l’infrastruttura conservando elementi di Shadow IT. Per avere successo, l’opzione sovrana deve essere più efficiente nel momento in cui lo sviluppatore prende la decisione.
Gli ambienti di preview illustrano questo punto chiaramente. Con modello di pricing a consumo, ogni PR ha un costo e conseguentemente i team razionano le preview. Su hardware già ammortizzato, una preview aggiuntiva è gratuita, quindi la pratica viene utilizzata come previsto. Il modello di pricing smette di influenzare le decisioni architetturali.ractice gets used the way it was meant to be. The billing model stops making engineering decisions for you.
Perché un PaaS e non solo un server
Controllare l’hardware è la parte semplice. Avremmo potuto prendere la stessa macchina, installare Docker, configurare manualmente un reverse proxy, automatizzare i certificate renewal e collegare un deploy hook. Ogni passaggio è ben documentato e nessuno è concettualmente complesso.
Tuttavia, questo è il percorso che porta a un server che solo una persona può mantenere in sicurezza. La configurazione risiede nella testa di quella persona e in file sparsi sull’host. L’onboarding di un collega richiede sessioni di knowledge transfer. Gli ambienti di preview non vengono mai creati, perché consistono in lavoro manuale che qualcuno deve motivarsi a implementare.
Un PaaS self-hosted fornisce la struttura di un prodotto gestito su un hardware controllato: interfaccia web, orchestrazione container, TLS automatico, CD innescato da git, preview environment per-PR. La caratteristica che volevamo garantire era la possibilità che altri utenti potessero operare nel sistema senza riunioni di handover. Su un progetto con scadenza fissa e diversi membri del team di sviluppo, questo è stato il fattore decisivo.
Coolify o Dokploy?Due piattaforme dominano questo segmento, con caratteristiche e proprietà leggermente differenti.
| Coolify | Dokploy | |
| Prima release | 2022, maturo con community consolidata | Aprile 2024, evoluzione rapida |
| Licenza | Open source, self-hosted gratuito, no feature gatekeeping | Open source, self-hosted gratuito |
| Scope | Ampio: 280+ servizi one-click, multi-host, MCP server nativo da v4.0 (maggio 2026) | Volontariamente minimale: Docker-first, attack surface ridotto |
| UX | Feature-dense, curva di apprendimento maggiore | Interfaccia leggibile e performante |
| Preview environment | Per-PR preview, first-class citizen | Supportati, meno maturi |
| Release cycle | Iterazioni strutturali | Incrementale |
| Use case ideale | Sostituto completo di una piattaforma managed | Wrapper minimalista su Docker Compose |
Abbiamo selezionato Coolify per due ragioni indipendenti dal conteggio di feature. In primo luogo, gli ambienti preview per-PR erano non-negoziabili e l’implementazione di Coolify era la più robusta. Il secondo motivo era la maturità, che nel caso del software self-hosted è indicativa di qualcosa di specifico: quando la piattaforma smette di funzionare, il canale di assistenza a cui rivolgersi sono le altre persone che hanno riscontrato lo stesso problema. Un progetto di quattro anni può rispondere a questioni che uno più giovane ancora non ha affrontato.
Si tratta di una valutazione di idoneità specifica per il nostro caso. Un team che desideri solo un livello leggero e intuitivo sopra Docker Compose, senza nulla di più, avrebbe ragione a scegliere lo strumento più snello; inoltre, la minore complessità rappresenta un vantaggio concreto quando quando siete voi gli on-call per il sistema.
Costi operazionali non previsti
Quello che ci si assume qui è una serie di responsabilità ricorrenti, che richiedono un responsabile preciso. Backup, patching, certificate renewal e capacity headroom diventano voci di routine nell’agenda di qualcuno. Se nessuno se ne fa carico, non sono eliminati; migrano su un risk register ignorato.
Nessuno dei seguenti è documentato e tutti e tre avrebbero influenzato il nostro design iniziale.
La configurazione se va dal repository. Lo stato della piattaforma—servizi, variabili d’ambiente, routing—risiede nell’interfaccia web, non nella history git. Per team abituati a versionare l’infrastruttura insieme al codice, è un’involuzione: l’applicazione è versionata, la piattaforma no. A questa scala è gestibile. Per dieci volte la scala non lo è.
I deploy hanno isolation boundaries deboli. Produzione, ambienti di sviluppo e PR aperte condividono un singolo host e punto di ingresso, rendendoli vicini nel grafo delle dipendenze. Un deploy in uno potrebbe avere effetti transitivi sui vicini. Per una demo non è critico. È però il motivo per cui non deployeremmo sistemi con SLA definiti su questa configurazione attuale.
Ogni servizio managed acquisito diventa responsabilità permanente. Siamo partiti con database managed e successivamente migrato a Postgres self-hosted sulla stessa piattaforma. La migrazione è stata ordinaria: un pomeriggio di lavoro. Cosa è cambiato realmente: backup verification e maintenance window sono diventati nostri compiti, e lo rimarranno negli anni a venire.
Conclusioni
Il valore reale di Fortitudex non riguarda Coolify, software valido ma sostituibile. Riguarda piuttosto il fatto che il compromesso che la maggior parte delle aziende dà per scontato (la sovranità da un lato e l’esperienza degli sviluppatori dall’altro) non si applicava alla nostra scala. Abbiamo mantenuto preview per-PR, Continuous Deploument al push e TLS automatico, deployando su hardware controllato in un ciclo di poche settimane.
Nulla di tutto ciò viene raccomandato in maniera assoluta. Si tratta di un singolo progetto, con un piccolo team, un pubblico interno e una scadenza che potevamo gestire autonomamente, e sono state proprio queste caratteristiche a fare la maggior parte del lavoro. Il carico operativo è l’aspetto da cui non siamo riusciti a sfuggire. La sovranità digitale non è un acquisto che si conclude una volta effettuato. È una capacità che deve essere gestita e mantenuta, e l’infrastruttura è la parte meno impegnativa di tutto ciò. Nei casi in cui abbiamo visto che questo approccio falliva, l’infrastruttura era stata pianificata, ma non era stato previsto il tempo necessario per gestirla.
Autore: Andrea Mazza, Senior Front-end Developer @Bitrock
FAQ
Un self-hosted PaaS è appropriato per grossi carichi di lavoro in produzione?
Nei nostri casi sì: strumenti interni, demo, servizi dove downtime di pochi minuti è tollerabile. Non eseguiamo nulla con SLA contrattuali su questa stack; prima di farlo, consulteremmo il team di platform engineering.
Setup: alcuni giorni. Carico ricorrente: minimo ma effettivo. Patching, backup verification, certificate e capacity monitoring.
I segnali a cui prestiamo attenzione sono: implementazioni che interferiscono tra loro, attività di manutenzione che non rientrano più nel tempo a esse assegnato e la prima richiesta di garanzia di disponibilità. Ognuna di queste situazioni smette di essere una questione di strumenti e diventa una questione di platform engineer, il che rappresenta un lavoro diverso, piuttosto che una versione più ampia di questo.
Coolify se cercate un sostituto completo di una piattaforma managed, con preview environment maturi e community consolidata.
Dokploy è l’ideale se desideri uno strato leggero e intuitivo sopra Docker e apprezzi un’interfaccia abbastanza semplice da poterla comprendere appieno.