Incluso in ogni piano
Enzonic CI
Pipeline ospitate per i tuoi repository GitHub sui runner Enzonic: test e build a ogni push e pull request, con cache, log in tempo reale e artefatti. Minuti CI, job paralleli e conservazione sono inclusi nel tuo piano.
Una console pensata per le pipeline
Esecuzioni, job e passaggi con i loro log, sullo stesso account di Deploy e Database. Schermate della console con dati di esempio.


Cosa fa
Viene eseguito a ogni push e pull request
Collega un repository GitHub: le pipeline girano su push, tag e pull request, secondo una pianificazione, oppure quando le avvii dalla console o dall'API.
Build a matrice e dipendenze tra job
Dividi il lavoro in job, distribuiscili su una matrice e ordinali con needs. I container di servizio, come Postgres, entrano nella rete del job.
Cache delle dipendenze
Le cache di npm, pnpm, Yarn, Bun, pip, Go, Cargo, Maven e Gradle vengono conservate per repository entro la dimensione della cache del tuo piano, così le esecuzioni successive saltano gran parte dell'installazione.
Sandbox isolate
Ogni job gira nella propria sandbox gVisor, su una rete dedicata, senza accesso alle reti private o all'host.
Log in tempo reale e artefatti
Segui ogni passaggio mentre viene eseguito, riesegui i job falliti e scarica gli artefatti finché il tuo piano li conserva.
Correzioni per i job falliti
Enzica, l'assistente di Enzonic, può leggere i log di un job fallito e proporre una correzione del codice che rivedi prima che cambi qualcosa.
Misurato rispetto a GitHub Actions
Lo stesso file di workflow su entrambe le piattaforme, in un repository privato di benchmark. Mediane in secondi; più basso è, più veloce.
| Passaggio | Enzonic CI | GitHub Actions |
|---|---|---|
| Esecuzione completa, dal push alla fine di tutti i job | 22 s | 37 s |
| Tempo in coda prima dell’avvio | 6 s | 9–10 s |
| Checkout | 0.06 s | 1 s |
| npm ci con lockfile invariato | 0.09 s | 3 s |
| go test con cache vuote | 2.8 s | 20 s |
| Job Go, tempo reale | 2 s | 11 s |
| npm ci, prima installazione di un nuovo lockfile | 6.8 s | 4 s |
Dove siamo più lenti: la prima installazione di un nuovo lockfile, perché ogni file passa dalla sandbox del job. Ogni esecuzione successiva con lo stesso lockfile richiede 0.09 s. Metodo: mediane di tre esecuzioni con cache calde (le righe a freddo usano cache vuote; GitHub a freddo è una sola esecuzione), GitHub su ubuntu-latest, misurato il 1 novembre 2026.
Una configurazione che già conosci
Scrivi .enzonic/ci.yml, oppure mantieni i workflow GitHub Actions che hai già: Enzonic CI esegue il sottoinsieme supportato e ti segnala il resto.
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
test:
image: node:22-bookworm-slim
services:
postgres:
image: postgres:17-alpine
env:
POSTGRES_PASSWORD: postgres
env:
DATABASE_URL: postgres://postgres:postgres@postgres:5432/postgres
steps:
- name: Install
run: npm ci
- name: Test
run: npm testUn esempio. Il riferimento CI nella documentazione elenca ogni chiave e azione supportata.
Limiti CI per piano
I minuti CI si azzerano ogni mese. I piani a pagamento aggiungono più minuti, job paralleli e una conservazione più lunga.
| Funzione | Gratis gratis | Starter 5 USD/mese | Pro 10 USD/mese | Growth 19 USD/mese | Business 29 USD/mese |
|---|---|---|---|---|---|
| Enzonic CI | |||||
| CI minutes | 3000/mese | 5000/mese | 6000/mese | 15.000/mese | 60.000/mese |
| Concurrent jobs | 2 | 4 | 6 | 10 | 20 |
| Job timeout | 360 min | 360 min | 360 min | 480 min | 720 min |
| Dependency cache | 2 GB | 5 GB | 10 GB | 20 GB | 50 GB |
| Artifacts / logs kept | 90 / 14 days | 90 / 30 days | 90 / 30 days | 180 / 60 days | 400 / 90 days |
Domande
Enzonic CI è incluso nel mio piano?
Devo riscrivere i miei workflow di GitHub Actions?
Come vengono conteggiati i minuti CI?
I segreti sono al sicuro nelle pull request dai fork?
Esegui la tua prima pipeline
Collega un repository GitHub con il piano Free. Senza carta.