GitLab non funziona oggi?

A proposito di GitLab

GitLab nasce nel 2011 dall'idea del programmatore ucraino Dmitriy Zaporozhets, che lo sviluppa da casa propria per colmare quella che considerava una lacuna negli strumenti di comunicazione tra sviluppatori disponibili all'epoca. Nel 2012 l'olandese Sytse Sijbrandij scopre il progetto leggendone su un sito di notizie tecnologiche e, dopo che Zaporozhets nel 2013 esprime pubblicamente su Twitter il desiderio di lavorarci a tempo pieno, i due si associano; la società GitLab Inc. viene incorporata nel 2014 e nel 2015 partecipa al programma dell'acceleratore Y Combinator in California, un passaggio che ne accelera sensibilmente la crescita.

Il 14 ottobre 2021 GitLab si è quotata al Nasdaq con una valutazione di 11 miliardi di dollari, dieci anni dopo l'avvio del progetto in Ucraina: una storia spesso citata come esempio di startup «unicorno» capace di nascere fuori dalla Silicon Valley. La piattaforma copre in un unico prodotto l'intero ciclo DevOps — repository Git, revisione del codice, pipeline di integrazione e distribuzione continua (CI/CD), gestione di problemi e sicurezza — proponendosi come alternativa completa a combinazioni di strumenti separati; conta oltre 3.300 tra collaboratori al codice e dipendenti in più di 60 paesi.

A differenza di concorrenti nati come servizio esclusivamente ospitato da terzi, GitLab distribuisce anche una versione Community Edition open source installabile sui propri server (self-hosted): un'azienda o un'amministrazione italiana può quindi scegliere se affidarsi a gitlab.com oppure gestire una propria istanza interna, una distinzione che incide anche su chi è responsabile della sicurezza e della disponibilità in caso di problemi.

Segnalazioni degli utenti

Ultimi disservizi noti di GitLab

Episodi documentati da fonti pubbliche, dal più recente. Fonti verificate il 18 settembre 2026.

• 11 gennaio 2024

  GitLab ha reso pubblica una falla critica, classificata CVE-2023-7028 con il punteggio massimo di gravità CVSS 10.0, che permetteva a chiunque, senza bisogno di credenziali, di dirottare la procedura di reimpostazione della password di un altro utente inserendo un secondo indirizzo email non verificato accanto a quello della vittima: il collegamento per reimpostare la password veniva inviato anche a quell'indirizzo scelto dall'attaccante, che poteva così impadronirsi dell'account. Il problema riguardava le versioni comprese tra la 16.1 e la 16.7.1 sia della Community Edition sia della Enterprise Edition, colpiva soprattutto chi non aveva attivato l'autenticazione a due fattori e interessava in modo particolare chi gestisce una propria istanza self-hosted non aggiornata tempestivamente; GitLab ha rilasciato versioni corrette per tutti i rami interessati e ha raccomandato pubblicamente l'attivazione dell'autenticazione a due fattori come misura di mitigazione aggiuntiva.

  Fonte: Rapid7, «Gitlab: CVE-2023-7028: Account Takeover via password reset»

• 31 gennaio 2017circa 18 ore, con il ripristino completato il 1° febbraio verso le 17:00 UTC

  Durante un intervento per risolvere un problema di replica tra il database primario di gitlab.com e la sua copia di riserva, un tecnico ha lanciato per errore contro il database primario, anziché contro quello secondario, il comando pensato per svuotarne il contenuto e forzarne una nuova sincronizzazione da zero; l'errore è stato interrotto dopo circa un secondo o due, ma in quel brevissimo lasso di tempo erano già stati cancellati circa 300 gigabyte di dati, comprese le modifiche al database registrate tra le 17:20 e mezzanotte UTC di quel giorno: circa 5.000 progetti, 5.000 commenti e 700 nuovi account utente creati in quella finestra sono andati persi, mentre i repository Git e i wiki non sono stati toccati. Nel resoconto pubblico l'azienda ha ammesso che, delle cinque diverse procedure di backup che riteneva di avere attive, nessuna aveva funzionato correttamente, e ha trasmesso in diretta streaming su YouTube, davanti a migliaia di spettatori, l'intero processo di recupero dai backup rimasti disponibili.

  Fonte: GitLab, «Postmortem of database outage of January 31», 10 febbraio 2017

Da sapere su GitLab

GitLab resta uno dei rari casi in cui l'azienda ha reso pubblico, con dettagli tecnici precisi e senza filtri, un proprio errore umano interno: l'incidente del gennaio 2017 viene citato ancora oggi nel settore come esempio di trasparenza, ma anche come promemoria che avere più livelli di backup dichiarati non equivale ad averli davvero verificati e funzionanti.

Chi gestisce una propria istanza GitLab self-hosted, invece di affidarsi a gitlab.com, è responsabile in prima persona di applicare gli aggiornamenti di sicurezza come quello del gennaio 2024 per il CVE-2023-7028: un ritardo nell'aggiornamento di un'istanza interna lascia quella singola installazione esposta anche quando gitlab.com ha già corretto il problema da tempo.

Informazioni utili su GitLab

• Sito ufficiale Sito ufficiale GitLab gitlab.com Versione ospitata (SaaS) del prodotto; esiste anche una Community Edition open source installabile sui propri server, con responsabilità di gestione diverse in caso di disservizio.
• Centro assistenza GitLab Support about.gitlab.com I tempi di risposta e i canali disponibili (ticket, chat) dipendono dal piano sottoscritto; chi usa il livello gratuito si appoggia soprattutto alla documentazione e al forum.
• Centro assistenza GitLab Community Forum forum.gitlab.com Forum pubblico per domande tecniche e segnalazioni tra utenti, gratuito e non riservato ai clienti a pagamento.
• Pagina di stato GitLab Status status.gitlab.com Stato dei servizi ospitati su gitlab.com con cronologia degli incidenti; non copre lo stato di un'istanza self-hosted gestita da terzi.
• Canale social GitLab su X @gitlab Comunicazioni di prodotto e, nei casi più gravi, aggiornamenti sui disservizi in corso.