Piattaforma
Tutto quello che serve per ospitare codice importante
L'hosting git che il tuo team conosce già, con regole che il server applica sempre. Ecco cosa trovi nella piattaforma.
Ogni giorno
Il git di sempre, senza sorprese
Per chi sviluppa non cambia nulla: clone, branch, push e tag come oggi. La differenza la fa il server.
-
File browser
Evidenziazione della sintassi e README in anteprima.
-
Cronologia e blame
Storia paginata, blame riga per riga, confronto fra branch.
-
Confronto
Diff fra branch, tag e commit, anche su storie lunghe.
-
Ricerca
Nei repository a cui hai accesso, e solo in quelli.
-
Organizzazioni e progetti
Ruoli ereditati e restrizioni per singolo utente.
-
HTTPS e SSH
Clone e push con il protocollo che il team usa già.
Protezioni lato server
Regole che non si aggirano, nemmeno da owner e admin
Le protezioni sono verificate dal server prima di accettare qualunque push. Non dipendono dagli hook installati sui computer degli sviluppatori e non esiste un ruolo che le scavalchi.
-
Branch protetti per pattern
main, release/*, develop: per ogni pattern scegli il ruolo minimo per il push. Force-push e cancellazione sono vietati.
-
Tag di rilascio immutabili
Un tag come v2.4.0 si crea una volta e non si sposta né si cancella: lo stesso numero di versione indica sempre lo stesso codice.
-
Rifiuti spiegati nella tua lingua
Chi tenta un'operazione vietata legge nel terminale quale regola l'ha fermato e come procedere, in italiano o in inglese secondo la sua preferenza.
-
Restrizioni per utente
Limita il ruolo di un singolo utente su un repository, ad esempio un consulente in sola lettura.
~/progetti/api $ git push --force origin v2.4.0remote:remote: CodeQuay: push RIFIUTATOremote: - refs/tags/v2.4.0: il tag 'v2.4.0' è immutabileremote: (pattern v*) e non può essere spostato; per unaremote: correzione pubblica una nuova versioneremote: ! [remote rejected] v2.4.0 -> v2.4.0 (pre-receive hook declined)Segreti e policy di push
Le credenziali si fermano prima di entrare nella storia
Una chiave committata per errore, una volta nella storia, va considerata compromessa. CodeQuay analizza i file nuovi di ogni push e respinge quelli che contengono credenziali riconoscibili.
Credenziali riconosciute
- Chiavi private PEM (RSA, EC, DSA, OpenSSH, PGP)
- Chiavi di accesso AWS
- Chiavi API Google
- Chiavi Stripe di produzione
- Token GitHub, anche fine-grained
- Token Slack
- Token personali CodeQuay
Regole aziendali sul contenuto
- Formato dei messaggi di commit con un'espressione regolare, ad esempio
feat|fix|docs: …. - Dimensione massima dei file: i binari pesanti restano fuori dal repository.
- Nel registro di audit finisce la regola violata, mai il valore del segreto.
~/progetti/api $ git push origin feature/pagamentiWriting objects: 100% (7/7), 2.31 KiB | 2.31 MiB/s, done.remote:remote: CodeQuay: push RIFIUTATOremote: - possibile segreto in 'config/prod.env' riga 12:remote: chiave di accesso AWS (AKIA7Q2M…(20 caratteri));remote: rimuovilo dalla storia (non basta un commitremote: successivo) e revoca la credenzialeremote: ! [remote rejected] feature/pagamenti -> feature/pagamenti (pre-receive hook declined)Accesso moderno
Identità solide, per le persone e per gli script
Gli utenti entrano come preferiscono, gli script usano credenziali limitate nel tempo e nei permessi.
- Passkey
- Accesso con impronta, volto o PIN del dispositivo, senza password da ricordare.
- App di autenticazione
- Verifica in due passaggi configurata con codice QR, con codici di recupero.
- Accesso federato
- Google, Apple, Microsoft 365 e provider aziendali compatibili OIDC.
- Token con scadenza obbligatoria
- Scope separati per API e git, scadenza massima di un anno, revoca immediata.
- HTTPS e SSH
- Clone e push con il protocollo che il team usa già, con le stesse regole.
- Blocco dei tentativi
- Limiti di frequenza e blocco temporaneo dopo ripetuti accessi falliti.
- Verifica del dispositivo nuovo
- Chi entra con la sola password da un dispositivo mai usato prima conferma l'accesso con un codice ricevuto per email.
- Email di sicurezza
- Avvisi per nuovi accessi da dispositivi non riconosciuti, passkey e 2FA modificate, password o email cambiate, nuovi token e chiavi SSH.
Team e collaborazione
Le persone giuste, sul codice giusto
Spazi separati per il lavoro personale e per quello aziendale, inviti che scadono, accessi limitati al singolo repository quando serve.
-
Spazi personali e aziendali
Ogni account ha uno spazio personale per prove ed esperimenti, visibile solo a te e a chi inviti. Il codice di lavoro sta nelle organizzazioni aziendali, sotto il controllo degli amministratori.
-
Inviti per email o username
Owner e maintainer invitano un collega con un ruolo mai superiore al proprio. L'invito vale 7 giorni e si può reinviare o revocare.
-
Collaboratori sul singolo repository
Un consulente può lavorare su un solo repository senza vedere gli altri repository del progetto.
-
Registrazione sotto controllo
Gli amministratori scelgono se la registrazione è aperta, riservata ai domini aziendali o chiusa. Un invito basta sempre per entrare.
-
In inglese e in italiano
Console, email e messaggi di git nella lingua scelta da ciascun utente.
-
Mirror verso GitHub per repository
Chi è maintainer attiva dalle impostazioni del repository la replica automatica di ogni push su GitHub.
Prestazioni
Veloce anche quando la storia è lunga
Navigazione del codice, cronologia, blame e diff restano fluidi anche su repository molto grandi. Gli indici di git vengono mantenuti ogni notte, senza interventi da parte tua.
< 2 s
p95 di storia, diff e blame
100k
commit nel repository di prova usato per la misura
CodeQuay Actions
CI/CD integrata, con la sintassi di GitHub Actions
I workflow in .github/workflows girano sui runner di CodeQuay, accanto al codice e sotto le stesse regole. La sintassi resta quella che il team conosce: di solito cambiano solo registry, segreti ed etichette dei runner.
- Trigger
- Push su branch e tag con filtri di percorso, esecuzione manuale con input, esecuzione programmata e workflow riutilizzabili.
- Segreti e variabili cifrati
- Per organizzazione, progetto, repository e ambiente. Mai restituiti dalle API, mascherati nei log.
- Ambienti con approvazione
- Un deploy in produzione parte solo dopo l'approvazione e solo dai branch o dai tag ammessi.
- Artefatti e cache
- upload-artifact e cache funzionano come su GitHub; gli artefatti si scaricano dalla console.
- Action da un mirror interno
- Le action pubbliche arrivano da un mirror su CodeQuay: i run non dipendono da github.com.
- Container o host del runner
- Job in container Docker oppure direttamente sull'host del runner, per deploy con ssh, helm o kubectl.
L'esecuzione si basa su act (nektos/act), open source. Nella console: log per step, riesecuzione dei job falliti, annullamento, approvazione dei deploy.
on: push: tags: ["v*"]jobs: deploy: runs-on: [self-hosted, linux] environment: production steps: - uses: actions/checkout@v4 - run: ./deploy.sh ${{ github.ref_name }}Migrazione
Da GitHub a CodeQuay, senza fermare la CI
L'import porta branch e tag e analizza tutta la storia alla ricerca di segreti. Il mirror replica poi ogni push su GitHub, dove la CI su GitHub Actions può continuare a girare. Il formato resta git standard: nessun vincolo per il futuro. Oppure i workflow passano a CodeQuay Actions, con la stessa sintassi.
Perché CodeQuay
Gli altri plus di CodeQuay
Vuoi vedere le protezioni all'opera sui tuoi repository?
Crea il tuo account e inizia gratis. Per un'istanza dedicata o un contratto su misura, scrivici: ti rispondiamo noi, in italiano.