Informazioni su Cipi
La storia di Cipi
Cipi è stato creato da Andrea Pollastri, sviluppatore software dal 2005 specializzato in Laravel, amministrazione di sistema e cybersecurity — con esperienza in aziende come Docebo e Musement. Ha costruito Cipi da un bisogno pratico: un modo veloce e scriptabile per provisionare e fare deploy di applicazioni Laravel sul proprio VPS, senza cedere il controllo a un pannello SaaS. Quello che era iniziato come strumento privato è diventato un progetto open source cresciuto fino a oltre 1.000 star GitHub e centinaia di deploy attivi in tutto il mondo. Ecco un breve resoconto di come si è evoluto in sei anni e cinque versioni major.
L'idea
Una raccolta di script shell per automatizzare le parti noiose del setup di un server Laravel su un VPS Ubuntu nuovo — Nginx, PHP, MariaDB, Supervisor. Nessuna web UI, nessun package. Solo bash.
Prima release — pannello Laravel
Gli script shell furono avvolti in un'applicazione web Laravel che faceva da pannello di controllo server. Gli utenti potevano creare app, gestire deploy e configurare Nginx tramite UI browser hostata sullo stesso server. Il progetto fu pubblicato su GitHub e attirò rapidamente interesse dalla community Laravel.
Crescita funzionalità
Un anno di iterazione rapida aggiunse configurazione SMTP, backup database locali, fix permessi PHP-FPM, gestione servizi server e reset password root. La serie v2 raggiunse 2.4.9 attraverso decine di release patch, stabilendo Cipi come opzione stabile per hosting Laravel di piccoli team.
Il grande salto — API, PHP 8, UI realtime
Costruito su Laravel 8, v3 introdusse una REST API completamente documentata (Swagger / OA), supporto PHP 8, grafici CPU/RAM in tempo reale, editor Cronjob, gestione Supervisor, repository manager GitHub, Node 15, Composer 2 e autenticazione JWT. Cipi poteva ora gestire lo stesso server su cui girava. Il progetto raggiunse 1k star GitHub.
L'ultima web UI — e una domanda
PHP 8.1 divenne la versione default. Node fu aggiornato a v16, Certbot fu rinnovato e la gestione alias dominio fu corretta. La serie v3.1.x fu la release più curata dell'era web-UI e molti team la tennero in produzione per anni.
Fu anche la versione che sollevò una domanda più dura: un pannello di controllo browser era ancora l'interfaccia giusta? I workflow di sviluppo moderni si erano spostati verso SSH, pipeline CI/CD, GitOps e — sempre di più — agenti AI che potevano orchestrare infrastruttura tramite comandi shell. Una web UI richiedeva autenticazione, un processo Laravel attivo e un database solo per emettere un deploy. Una CLI non richiedeva nulla di tutto ciò. La risposta ha plasmato tutto ciò che venne dopo.
La riscrittura — CLI-first, esclusivamente Laravel
Dopo anni di manutenzione di un'applicazione web Laravel completa come control plane, v4 prese la decisione più audace: eliminare completamente la web UI. Cipi divenne uno strumento CLI puro operato via SSH. Lo scope si restringò anche da PHP generico a esclusivamente Laravel, permettendo di ottimizzare ogni parte dello stack per un solo framework. MySQL fu sostituito da MariaDB 11.4, git pull fu sostituito da release zero-downtime Deployer, le deploy key condivise divennero chiavi ed25519 per-app, e backup S3 automatizzati e supporto webhook nativo per GitHub e GitLab furono aggiunti dal giorno uno. v4 introdusse anche una REST API completa per gestione programmatica di host e applicazioni, integrazione nativa con provider Git GitHub e GitLab, un'architettura rivoluzionaria server MCP dual — uno per-app e uno globale — abilitando gestione infrastruttura completa guidata da AI direttamente da qualsiasi IDE o agent AI compatibile MCP, sync server criptato per migrare app tra istanze VPS, e un anonymizer database integrato per export dati conformi GDPR.
cipi self-update non resta più bloccato su Migration 4.7.16 (clash delimitatore sed con || true); upgrade da versioni sotto 4.7.16 (es. 4.7.14 → 4.8.x) completano di nuovo. 4.8.0 — database multi-engine (MariaDB su 3306 + PostgreSQL opzionale su 5432): cipi db install pgsql / uninstall, cipi db default, cipi db engines, e --engine=mariadb|pgsql su create/list/delete/backup/restore/password; cipi app create --engine=pgsql (prompt interattivo per app Laravel); cipi www per alias www/apex e redirect 301 canonici (add, force-to-root, force-from-root, clear, status); cipi ssl force riapplica redirect HTTP→HTTPS senza riemissione; cipi alias add|remove riapplica SSL via certbot install --redirect così HTTPS non viene perso (migration 4.8.0). 4.7.23 — cipi help è un indice breve per area; liste complete in cipi help <topic> o cipi help all. 4.7.20–4.7.22 — fix AppArmor/setgid cipi smtp (solo /etc/msmtprc di sistema; legacy /etc/cipi/.msmtprc rimosso). 4.7.19 — deploy SSH mode ~/.ssh 700; cipi app delete purga utenti/home orfani. 4.7.15–4.7.18 — Panel API e cipi db list su Ubuntu 25.10+ / 26.04: /etc/sudoers.d/cipi-api compatibile sudo-rs (cipi db restore *), guard read-only /etc/cipi (niente init chmod quando root è remontato ro; fix HTTP 503: chmod … Read-only file system), open_basedir PHP-FPM API include /usr/local/bin/ per helper log, database vuoti elencati via information_schema.schemata, e errori vault/MariaDB mostrati invece di tabella vuota. 4.7.14 — staging cipi backup run default su /var/tmp (disco) invece di /tmp (spesso tmpfs RAM piccolo), così backup app grandi non falliscono più quando tmpfs si riempie; override con tmpdir in backup.json (via cipi backup configure) o CIPI_BACKUP_TMPDIR. 4.7.13 — check patch sicurezza PHP settimanale: pacchetti PHP esclusi da unattended-upgrades (gestiti da Cipi); cipi php upgrade esegue apt-get update e --only-upgrade su tutti i pacchetti php* / libphp* installati, riavvia pool PHP-FPM interessati e invia email quando upgrade applicati (trigger php_upgrade). Crontab root: domenica 03:30 via cipi-cron-notify; log: /var/log/cipi/php-upgrade.log (migration 4.7.13). 4.7.12 ha corretto SQL injection nei comandi cipi db (validate_db_name()) e code injection PHP via cipi app create --repository= / --branch= e cipi app edit (validate_git_branch() / validate_git_repository() prima che i valori siano scritti in deploy.php; nessuna migration richiesta). La serie 4.7.x ha introdotto l'opzionale pannello di controllo web (cipi gui, 4.7.0), spostato cipi/gui nel proprio repository GitHub (4.7.5), e consegnato hardening GUI più cipi app logs read fino a 4.7.11 (guida post-install setup per Panel API e Web GUI). 4.6.7 corregge install fresh quando unattended-upgrades tiene il lock apt (attende fino a 300s via DPkg::Lock::Timeout, cipi_wait_for_dpkg_lock per keyring Sury, migration 4.6.7 per server esistenti). 4.6.6 corregge install fresh su Ubuntu 26.04 quando repo MariaDB.org e PHP third-party non hanno ancora suite resolute (probing APT unificato via lib/php-apt.sh). 4.6.3–4.6.5 aggiunsero cipi notifications granulare, update notturni panel API, ability token canoniche per cipi api token create e fix affidabilità self-update. 4.6.2 aggiunge rename dominio primario via cipi app edit --domain= (promuove il nuovo dominio, sposta il vecchio primario negli alias, aggiorna Nginx, APP_URL, webhook e Let's Encrypt quando applicabile). Il package panel API (cipi/api) è a 1.13.0: Laravel Octane opzionale su app create (octane / octane_port), database multi-engine e redirect www (1.12+), GET /api/status, tool MCP per polling job (JobShow), log app e panel, Artisan e monitoraggio server (ServerStatus, ServiceList), più autorizzazione solo mcp-access su /mcp e redazione log produzione. Install fresh via setup.sh accettano solo Ubuntu 24.04 o 26.04 (match esatto VERSION_ID; release interim rifiutate). 4.6.1 alzò il floor Composer a 2.10.1+ su install e self-update. Release 4.5.10–4.5.12 corressero setup su Ubuntu 26.04 (layout nginx sites-available, probing APT MariaDB.org e PHP con packages.sury.org quando Launchpad non ha suite). 4.5.9 aggiunse app suspend / unsuspend (mette un'app offline dietro pagina manutenzione HTTP 503 generica senza eliminarla), collegato a REST API, server MCP e modulo WHMCS. v4.5.6–4.5.7 sostituirono Redis con Valkey, fork open source con licenza BSD, con migration automatica e self-healing Redis → Valkey su self-update. v4.5.5 aggiunse la mappa globale cipi domains (ogni dominio e alias di tutte le app in una tabella) e alias shell ll per utenti app. v4.5.4 bundled Deployer 8, così nuove install PHP sono limitate a 8.3, 8.4 e 8.5 (con guard deploy-time per app ancora pin a versioni vecchie). Release recenti aggiunsero anche HTTP basic auth per app (cipi basicauth enable/disable/status, 4.5.2) e hardened panel API contro reset permessi self-update che causava HTTP 500 intermittenti (4.5.3).
La GUI ritorna — questa volta, opzionale
Eliminare la web UI in v4 era la scelta giusta: rese Cipi snella, scriptabile e AI-native. Ma la domanda dell'era v3.1 non si chiuse del tutto — alcuni team e agenzie volevano genuinamente una dashboard browser, per sé e per i clienti. v4.7 rispose senza tradire un solo principio: un pannello di controllo web opzionale, installato con un comando (cipi gui <domain>) e rimosso altrettanto facilmente. È un package Laravel 12 separato (cipi/gui) che parla ai tuoi server sulla stessa REST API — un layer visuale sottile, non un nuovo control plane. Installalo se lo vuoi; saltalo e Cipi resta esattamente la CLI pura che era in v4. L'install default non include ancora nessuna superficie web. Vedi la documentazione Pannello di controllo.
Database multi-engine e redirect www
v4.8 mantiene MariaDB come default nativo aggiungendo PostgreSQL opzionale come motore di primo livello — installa con cipi db install pgsql, scegli per app con --engine=pgsql, e gestisci entrambi attraverso la stessa superficie cipi db. Redirect canonici www ↔ apex arrivano come cipi www, e cipi ssl force ripristina redirect HTTP→HTTPS senza riemettere certificati. Modifiche alias non perdono più HTTPS. Panel API (1.12 e web GUI rispecchiano queste capacità (engine su app/database, endpoint www, ssl/force). Vedi cipi db, cipi www e cipi ssl.
Laravel Octane, Horizon, Reverb e ops produzione
v5 rende Cipi la CLI hosting Laravel più profonda finora. Laravel Octane (FrankenPHP) opzionale gira accanto ad app PHP-FPM classiche sullo stesso server — crea con cipi app create --octane, converti qualsiasi app Laravel esistente con cipi app convert --to=octane|fpm, e lascia che Nginx faccia proxy_pass verso un processo Octane gestito da Supervisor mentre gli asset statici restano su disco. Panel API (1.13) e web GUI espongono la stessa opzione creazione Octane via REST. Laravel Horizon di primo livello (cipi worker horizon, Laravel Reverb cipi app reverb, CLI scheduler, build Node al deploy, clone app per staging, snapshot DB pre-deploy, limiti risorse per app, SSL Cloudflare DNS-01 / wildcard e healthcheck HTTP completano la release. Vedi Laravel Octane, worker / Horizon e SSL DNS-01.
horizon:terminate / octane:reload se Horizon / Octane non sono installati (evita exception digests su app senza quei package; migration rigenera deploy.php). 5.0.1 — guard first-deploy per horizon:terminate quando non esiste ancora symlink current. 5.0.0 — Laravel Octane (FrankenPHP), cipi app convert, Reverb, Horizon, CLI schedule, --node-build, cipi app clone, snapshot pre-deploy, limiti risorse, SSL Cloudflare DNS-01 e healthcheck HTTP. Changelog completo: CHANGELOG.md.
Modello di sicurezza
Hardening SSH
Durante l'installazione, Cipi crea i gruppi cipi-ssh e cipi-apps e applica la seguente architettura SSH:
| Utente | Accesso | Metodo |
|---|---|---|
root |
bloccato | PermitRootLogin no |
cipi |
solo chiave | gruppo cipi-ssh, PasswordAuthentication no globalmente |
| utenti app | utente + password | gruppo cipi-apps, Match Group cipi-apps → PasswordAuthentication yes
|
sshd_config usa AllowGroups cipi-ssh cipi-apps invece di AllowUsers. Gli utenti app possono connettersi con ssh myapp@server-ip e la password generata alla creazione app. L'accesso admin è via chiave pubblica come cipi. Le chiavi SSH sono gestite con cipi ssh list / add / remove — vedi Gestione chiavi SSH.
Gestione chiavi SSH e notifiche
Le chiavi autorizzate per l'utente cipi possono essere gestite via CLI con sicurezza integrata: validazione formato, prevenzione duplicati, protezione sessione corrente e protezione ultima chiave per evitare lockout. Quando SMTP è configurato, ogni aggiunta, rimozione o rename chiave attiva un alert email con hostname, IP, fingerprint, timestamp e conteggio chiavi rimanenti. Gli alert rename includono anche nome chiave vecchio e nuovo.
Prevenzione escalation privilegi
Gli utenti applicazione sono limitati dall'usare su per escalare privilegi a root o account cipi. Questo è applicato via pam_wheel.so group=sudo, assicurando che solo membri del gruppo sudo possano cambiare utente.
Hardening sudoers
L'utente www-data (usato da Nginx e PHP-FPM) ha accesso sudoers limitato a una whitelist esplicita di comandi invece di un pattern wildcard. Solo i sottocomandi /usr/local/bin/cipi richiesti dall'API sono consentiti. Questo impedisce a www-data di eseguire comandi arbitrari anche se l'applicazione web è compromessa.
Whitelist comandi API
L'API Cipi valida ogni comando CLI contro una whitelist interna prima di eseguirlo via sudo. Comandi non in whitelist sono rifiutati, prevenendo command injection attraverso il layer API.
Isolamento utenti
Ogni app gira sotto il proprio utente Linux con chmod 750 sulla home directory. Nessuna app può leggere i file di un'altra app. PHP-FPM esegue il pool di ogni app come utente app con il proprio socket Unix.
PHP open_basedir
open_basedir è configurato per pool FPM per limitare PHP alla home directory dell'app. Anche se un'app è compromessa, PHP non può accedere al filesystem fuori dalla propria home.
Isolamento database
Ogni app ha il proprio database e utente (MariaDB di default; PostgreSQL opzionale da v4.8.0) con privilegi limitati a quel solo database. Un'app compromessa non può leggere o scrivere sul database di un'altra app.
Deploy key SSH per app
Ogni app riceve la propria coppia chiavi SSH ed25519. Una deploy key compromessa influenza solo un repository — non tutte le app sul server.
Sicurezza webhook
I webhook GitHub sono verificati usando firme HMAC-SHA256. I webhook GitLab usano confronto token. L'handler webhook in cipi-agent restituisce 200 immediatamente e scrive un file flag — Deployer gira separatamente come utente app senza privilegi elevati.
Crittografia configurazione (Vault)
Tutti i file di configurazione Cipi — server.json, apps.json, databases.json, backup.json, smtp.json, api.json — sono criptati a riposo usando AES-256-CBC via il sistema Vault integrato. Una master key per-server (/etc/cipi/.vault_key, chmod 400) assicura che anche se un attaccante ottiene accesso in lettura al filesystem, i file di configurazione con password database, token API e credenziali sono illeggibili senza privilegi root. Vedi Vault e crittografia per l'architettura completa.
Archivi sync criptati
Quando trasferisci applicazioni tra server via cipi sync, l'intero archivio — inclusi file .env, chiavi SSH, dump database e configurazione — è criptato con AES-256-CBC usando una passphrase fornita dall'utente. Gli archivi usano estensione .tar.gz.enc e non possono essere letti senza passphrase. Questo protegge dati sensibili sia a riposo (su disco) che in transito (durante trasferimento rsync/scp). Vedi Sync per dettagli.
Retention log conforme GDPR
Cipi applica rotazione log automatica: log applicativi e sicurezza sono conservati 12 mesi, mentre log HTTP/navigazione (che contengono indirizzi IP — dati personali sotto GDPR) sono conservati 90 giorni. Questo soddisfa il principio minimizzazione dati GDPR preservando abbastanza storia per debug e audit trail. Vedi Retention log per la policy completa.
Notifiche auth e chiavi
Cipi monitora eventi autenticazione privilegiata via PAM (pam_exec.so) e invia alert email in tempo reale quando un utente eleva via sudo o su, o quando root/sudoers accede via SSH. Le notifiche login SSH includono fingerprint chiave e commento (risolto confrontando fingerprint /var/log/auth.log con authorized_keys), così identifichi immediatamente quale chiave ha accesso al server. Alert email vengono inviati anche quando chiavi SSH sono aggiunte, rimosse o rinominate sull'utente cipi, e quando app sono create, modificate o eliminate. Le notifiche includono dettagli contestuali (username, TTY, IP sorgente, fingerprint, commento chiave, conteggio chiavi) e girano in modo asincrono per evitare ritardi login. Tutti gli eventi sono anche loggati in /var/log/cipi/events.log indipendentemente da SMTP. Gli alert email richiedono SMTP configurato — fallisce silenziosamente altrimenti. Vedi Notifiche email per setup.
Nessun pannello web di default
Un'install Cipi default non ha interfaccia web — nessuna superficie attacco da pannello admin, e tutta la gestione avviene via SSH come utente cipi usando la CLI cipi. Il pannello di controllo web è strettamente opt-in: installalo solo se vuoi una dashboard browser. Quando lo fai, gira come app Laravel self-hosted isolata confinata con open_basedir; lascialo fuori e non c'è nessuna superficie web.
Virtual host Nginx default
Il virtual host Nginx default usa una regola rewrite per servire una pagina minimale "Server Up" per tutte le richieste a domini non configurati o accesso IP diretto. Questo catch-all affidabile impedisce a Nginx di esporre il numero di versione nelle pagine errore default.
Rete
UFW blocca tutte le porte di default tranne 22, 80 e 443. Fail2ban monitora SSH con ban progressivi: ban base 24 ore che raddoppia a ogni reincidenza (cap 7 giorni), con solo 3 tentativi consentiti prima del ban. Una jail recidive dedicata cattura recidivi — 3 ban entro 24 ore attivano un blocco 7 giorni. Usa cipi ban list e cipi ban unban per ispezionare e gestire ban dalla CLI.
Aggiornamenti sicurezza OS automatici
Cipi abilita unattended-upgrades durante l'installazione, così il sistema Ubuntu sottostante applica patch di sicurezza automaticamente — senza intervento manuale. Solo update classificati sicurezza sono installati unattended; upgrade major richiedono conferma esplicita. I pacchetti PHP sono esclusi da unattended-upgrades e gestiti da Cipi: da v4.7.13, cipi php upgrade applica patch sicurezza a ogni versione PHP installata on demand o settimanalmente (domenica 03:30). Vedi Gestione PHP.
Puoi verificare e gestire la configurazione in qualsiasi momento:
# check unattended-upgrades status $ systemctl status unattended-upgrades # view the upgrade log $ cat /var/log/unattended-upgrades/unattended-upgrades.log # force an immediate unattended upgrade run $ unattended-upgrade --debug --dry-run
sudo reboot.
Perché non in locale?
Cipi è un provisioner server produzione. È pensato per trasformare un VPS Ubuntu nuovo in un host Laravel live e internet-facing — non per girare sul tuo laptop, dentro un container Docker locale o dietro NAT domestico.
Questo è esplicito nei requisiti e non è un bug o funzionalità mancante. Cipi ha bisogno di un server che sia:
- Raggiungibile da internet pubblico — con indirizzo IPv4 pubblico routabile, non nascosto dietro NAT (router domestico, firewall aziendale o tier cloud solo NAT)
- In esecuzione su hardware reale o KVM completo — non su virtualizzazione shared-kernel (OpenVZ, LXC) o runtime container desktop che emulano una VM Linux sulla tua macchina
- Accessibile sulle porte 22, 80 e 443 — validazione HTTP Let's Encrypt, vhost Nginx e workflow deploy SSH assumono tutti che il traffico inbound possa raggiungere l'host
Non compatibile con dockerizzazione locale
Cipi non è compatibile con ambienti dockerizzati locali. Tool come Docker Desktop, OrbStack, Colima e runtime simili ti danno una VM Linux dietro NAT su Mac o Windows — nessun IP pubblico, nessun routing inbound da internet, e spesso kernel condiviso sotto il cofano. L'installer Cipi può completare, ma il risultato non è un server produzione:
- SSL non funzionerà — Certbot non può completare validazione Let's Encrypt quando l'host non è raggiungibile sulla porta 80 da internet
- I domini non risolveranno — non c'è endpoint pubblico a cui puntare il DNS
- Deploy e webhook si rompono — provider Git, runner CI e servizi esterni non possono raggiungere una VM locale NAT-ted
Vincolo standard del settore
Nessun provisioner server produzione supporta ambienti locali NAT-ted. Pannelli commerciali e tool open source richiedono allo stesso modo un host pubblico e accessibile da internet — è così che funzionano SSL, routing dominio e pipeline deploy remote. Cipi segue la stessa regola.
La differenza è ciò che Cipi non chiede: nessun daemon agent proprietario, nessuna porta outbound dedicata a un pannello di controllo esterno e nessun account cloud obbligatorio. Cipi gira interamente sul tuo server — entri via SSH e usi la CLI. Il requisito internet pubblico riguarda la topologia di rete, non il legarti a un vendor SaaS.
Cosa usare in locale invece
Per sviluppo Laravel locale, usa Laravel Sail, Laravel Herd, o un semplice composer install con php artisan serve. Provisiona un VPS economico con Cipi quando ti serve un ambiente staging o produzione reale.
Perché MariaDB?
MariaDB è il motore database default su ogni server Cipi (porta 3306). Da v4.8.0 puoi anche installare PostgreSQL opzionale (cipi db install pgsql, porta 5432) e scegliere un motore per app o database — vedi cipi db e Perché PostgreSQL?. MariaDB resta il default giusto per la maggior parte delle app Laravel: SQL MySQL-compatible familiare, prestazioni forti già incluse e modello licenza che resta semplice per produzione self-hosted.
Prestazioni che contano in produzione
MariaDB è costruito per carichi web ad alta concorrenza — esattamente il pattern che le app Laravel generano (molte query brevi, churn connessioni da PHP-FPM, mix read e write).
- Ottimizzatore query avanzato — pianificazione join e decisioni cost-based migliori del MySQL classico per query applicative tipiche, il che spesso significa meno full scan e latenza minore sotto carico.
- Thread pool nativo — disponibile nell'edition community, così il server gestisce molte connessioni concorrenti più efficientemente di un modello one-thread-per-connection quando PHP-FPM picca.
- InnoDB ottimizzato per il tuo VPS — Cipi imposta
innodb_buffer_pool_sizedalla RAM server (256M su host 1 GB, fino a 4 GB su macchine 16 GB+), così i dati hot restano in memoria senza affamare Nginx o PHP. - Default snello per Laravel — la maggior parte delle app ha bisogno di uno store relazionale veloce, non estensioni esotiche. MariaDB lo offre con overhead operativo basso su una singola macchina Ubuntu.
Meno grattacapi di licenza
Scegliere MariaDB evita l'ambiguità che circonda Oracle MySQL in scenari commerciali e redistribuzione — specialmente quando spedisci prodotti, hosti app clienti o gestisci infra per un'azienda.
- Server community GPL puro — MariaDB Server è GPL; non c'è fork enterprise dual-license del motore core che devi navigare solo per restare conforme.
- Nessun labirinto CLA / dual-license Oracle MySQL — non dipendi dalla linea prodotto MySQL Oracle, policy trademark o edition commerciali per funzionalità che "dovrebbero" essere gratis.
- Prevedibile per SaaS e agenzie — self-hosting MariaDB sul tuo VPS mantiene semplice la licenza database: esegui software open source su hardware che controlli, senza feature gate MySQL Enterprise o revisioni licenza a sorpresa.
- Allineato alla filosofia MIT di Cipi — stack aperto, nessun vendor lock-in, nessuno SKU database a pagamento richiesto per feature prestazioni produzione come thread pool.
Compatibilità MySQL senza il bagaglio
- Drop-in per Laravel — usa driver
mysql, stesse chiavi envDB_*e stessi file migration. Eloquent, queue e la maggior parte dei package funzionano e basta. - Tooling familiare — TablePlus, DBeaver, Sequel Ace e client CLI
mariadb/mysqlsi connettono allo stesso modo; Cipi espone comunque un URLmariadb+ssh://pronto dopo install. - Nativo su Ubuntu — installa da MariaDB.org / packaging Ubuntu senza inventare uno stack database custom; Cipi collega utenti, backup e credenziali vault sopra.
- Collaudato sul campo per il mondo LAMP/LEMP — decenni di applicazioni MySQL-compatible, documentazione e familiarità hiring — con un motore che resta community-first.
Perché PostgreSQL?
Da v4.8.0, PostgreSQL è un motore opzionale di primo livello su Cipi (porta 5432). Installalo con cipi db install pgsql, poi crea app o database con --engine=pgsql — vedi cipi db. Mantieni MariaDB come default per carichi Laravel MySQL classici, o scegli Postgres quando ti servono SQL più ricco, garanzie concorrenza più forti o uno stack che cresce verso analytics e AI.
Funzionalità oltre "solo tabelle"
- SQL ricco e tipi dati — JSON/JSONB, array, range, UUID, full-text search ed espressive constraint (CHECK, exclusion, FK deferred) che mappano pulito a modelli di dominio complessi.
- Indicizzazione potente — B-tree, GIN, GiST, BRIN, indici parziali ed espressione — così puoi indicizzare path JSON, cercare documenti o accelerare query stile time-series senza un secondo datastore.
- Ecosistema estensioni —
pgcrypto,uuid-ossp,pg_trgm, PostGIS e molti altri trasformano Postgres in una piattaforma, non solo un file SQL. - Supporto Laravel di primo livello — driver
pgsqlnativo, migration, Eloquent e un enorme ecosistema di package che assumono feature Postgres quando ti servono.
Scalabilità e concorrenza
- MVCC fatto bene — i reader non bloccano i writer; report lunghi e traffico write intenso convivono più elegantemente che su setup lock-heavy.
- Affidabile sotto carico misto — consistenza forte, DDL transazionale in molti casi e un planner che regge quando schema e shape query diventano più sofisticati.
- Spazio per crescere su un VPS — poi oltre — ottima scala verticale per un server Cipi single-node; quando superi la macchina, lo stesso motore è quello attorno cui sono costruiti Postgres gestito, replica e ecosistemi logical replication.
- Chiarezza operativa — view monitoraggio mature (
pg_stat_*), explain plan e tooling che team senior sanno già ottimizzare.
Compatibilità e portabilità
- Standard di settore — Postgres è la risposta default per molti backend SaaS, pipeline analytics e offerte cloud "managed database". Skill e runbook si trasferiscono.
- SQL standards-leaning — più vicino a ANSI SQL che dialetti MySQL, il che riduce sorprese quando condividi query tra tool, ORM e warehouse.
- Funziona con lo stack dati più ampio — tool BI, ORM, ETL e sistemi CDC parlano quasi sempre Postgres; il tuo DB hostato su Cipi non è un vicolo cieco.
- Affiancato a MariaDB su Cipi — entrambi i motori possono girare sullo stesso server (3306 + 5432). Scegli per app: stile WordPress o Laravel MySQL classico su MariaDB; prodotti, multi-tenant o app JSON-heavy su Postgres.
Pronto per AI e carichi dati moderni
- Vettori ed embedding — con estensioni come
pgvector, puoi memorizzare embedding accanto a dati relazionali per semantic search, RAG e feature recommendation senza agganciare un database vettoriale separato dal giorno uno. - JSONB come layer documento flessibile — mantieni colonne strutturate per invarianti e JSONB per metadata AI in evoluzione, output modello o payload tool — interrogabile e indicizzabile.
- Blocchi costruzione full-text + similarity — combina FTS, similarità trigram e vettori per retrieval ibrido (keyword + semantico) dentro un sistema transazionale.
- Analytics-friendly — window function, CTE, materialized view e aggregazione robusta rendono Postgres una buona casa per metriche prodotto e feature store prima che ti serva un warehouse.
Quando scegliere PostgreSQL su Cipi
- Ti servono constraint avanzati, JSONB o estensioni Postgres-specifiche
- Ti interessa concorrenza writer, report complessi o semantica SQL più rigorosa
- Stai costruendo feature AI (embedding, hybrid search) o ti aspetti di farlo
- Il tuo team o package upstream standardizzano già su
pgsql
MariaDB resta il default zero-friction. PostgreSQL c'è quando il prodotto ha bisogno di un motore relazionale più capace — ancora gestito attraverso lo stesso workflow cipi db per create, list, backup, restore e rotazione password.
Perché Valkey?
Cipi usa Valkey invece di Redis per diversi motivi:
- Drop-in replacement — stesso protocollo RESP sulla porta
6379, stessa estensionephpredis, stesse chiaviREDIS_*.env. Laravel non nota la differenza. - Veramente open source — fork con licenza BSD stewarded dalla Linux Foundation, creato dopo che Redis Inc. passò a SSPL / RSALv2 source-available nel 2024.
- Nativo su Ubuntu — incluso nel repository Universe di Ubuntu 24.04 (
valkey-server+valkey-tools) senza PPA third-party. - Nessun vendor lock-in — allineato alla filosofia MIT self-hosted di Cipi: gratis per sempre, supportato da AWS, Google Cloud, Oracle e una grande community.
- Auto-migrato — server esistenti passano da Redis a Valkey automaticamente su
cipi self-update, riusando la stessa password e dataset senza modifiche app.
Perché Laravel?
Quando v4 fu progettato, una delle decisioni più chiare fu eliminare completamente supporto PHP generico e WordPress e puntare tutto su un solo framework. Quel framework fu Laravel — e il ragionamento va ben oltre la preferenza personale.
Velocità di sviluppo
Laravel dà agli sviluppatori un vantaggio straordinario. Autenticazione, queue, task schedulati, file storage, email, notifiche, API resource, migration database — tutto è integrato, consistente e documentato. Un team può passare da progetto vuoto ad applicazione pronta per produzione in una frazione del tempo che servirebbe con uno stack low-level. Per Cipi, questo significa che ogni assunzione deploy — layout directory, gestione .env, queue worker, scheduler — mappa pulito a una struttura nota. Nessun guesswork.
Una community open source fiorente
Laravel ha una delle community più attive e accoglienti nel mondo PHP. Package vengono pubblicati, mantenuti e discussi ogni giorno su GitHub, Laracasts, Discord e X. Quando assumi uno sviluppatore Laravel, ottieni qualcuno che conosce già convenzioni, tooling ed ecosistema. Quando pubblichi un package Laravel, raggiunge decine di migliaia di sviluppatori overnight. Quell'effetto network è genuinamente prezioso — ed è uno dei motivi per cui il package companion di Cipi, cipi-agent, funziona così bene: lo inserisci in un'app Laravel e si integra.
Sicurezza di default
Laravel prende la sicurezza sul serio già inclusa. Protezione CSRF, prevenzione SQL injection tramite query builder, mitigazione XSS via auto-escaping Blade, rate limiting, URL firmati, cookie criptati — non sono add-on che colleghi, sono i default. Il ciclo release del framework include patch sicurezza rapide, e il team pubblica guide upgrade chiare. Per applicazioni produzione che gestiscono utenti e dati reali, quella affidabilità conta enormemente.
Longevità e supporto
Ogni versione major Laravel riceve bug fix per 18 mesi e security fix per due anni dopo release. Le versioni LTS estendono oltre. Taylor Otwell e il core team hanno mantenuto un cadence release consistente e principiato dal 2011 — un track record raro e genuinamente rassicurante per progetti long-term. Quando fai deploy su Cipi, non scommetti su un framework che potrebbe essere abbandonato l'anno prossimo.
L'ecosistema Laravel
Laravel non sta da solo. Attorno è cresciuto un ecosistema di tool first-party e community tra i migliori del settore:
- Livewire — componenti reactive full-stack senza lasciare PHP
- Filament — un admin panel e form builder splendido costruito su Livewire
- Inertia.js — il ponte tra Laravel e framework frontend moderni (Vue, React, Svelte)
- Laravel Horizon — una dashboard bellissima per monitorare queue Valkey/Redis; Cipi lo abilita con
cipi worker horizon enable - Laravel Reverb — WebSocket first-party; Cipi collega Supervisor, proxy Nginx
/appeREVERB_*concipi app reverb enable - Laravel Telescope — un elegante assistente debug per ambienti local e staging
- Laravel Octane — supercarica le prestazioni applicative con FrankenPHP (e opzionalmente Swoole / RoadRunner). Cipi esegue Octane nativamente:
cipi app create --octaneocipi app convert --to=octane - Pest — un framework testing PHP delizioso con plugin Laravel-native
- Laracasts — i migliori screencast in PHP, punto
Questi tool non esistono solo — sono attivamente sviluppati, ampiamente adottati e genuinamente piacevoli da usare. Il mondo Laravel ha una qualità rara: riesce a essere abbastanza opinionated da sentirsi coeso e abbastanza flessibile da restare fuori dalla strada quando serve.
Ship or die
Taylor Otwell, fondatore di Laravel, ha un mantra che risuona ben oltre il framework: "we must ship." È una dichiarazione semplice, ma racchiude un'intera filosofia — che il codice ha valore solo quando raggiunge gli utenti, che il perfezionismo è nemico del progresso, e che i migliori sviluppatori sono quelli che trovano modi per andare avanti anche quando le condizioni non sono ideali.
Il mondo tech più ampio ha la sua versione più diretta: ship or die. Costruisci qualcosa di reale, mettilo davanti alle persone, impara e itera — o guardalo diventare lentamente irrilevante in un cassetto. L'intero ecosistema Laravel è costruito attorno a quello spirito. Il framework riduce attrito, la community celebra release e il tooling premia velocità. Cipi esiste per la stessa ragione: rimuovere l'attrito gestione server che sta tra uno sviluppatore e un'applicazione live e deployata.
Se stai leggendo questa documentazione, probabilmente sei uno sviluppatore che vuole costruire cose, non fare babysitting all'infrastruttura. È esattamente il tipo di sviluppatore per cui Cipi è stato fatto.
Perché "ci-pi"?
Cipi è la lettura italiana delle lettere C e P — che stanno per Control Panel. È un cenno silenzioso alle radici italiane del progetto e al fatto che, sotto tutti i comandi CLI, Cipi fa esattamente ciò che fa un pannello di controllo: gestisce Nginx, PHP-FPM, MariaDB, Supervisor, Certbot e UFW per tuo conto — solo senza la tab del browser.
Il nome porta anche una leggerezza deliberata. Gli strumenti di gestione server tendono a prendersi molto sul serio. Cipi no. È uno strumento costruito da uno sviluppatore per sviluppatori, con l'obiettivo di uscire dalla strada il più rapidamente possibile.
La mascotte
La mascotte di Cipi è un pinguino — un riferimento intenzionale a Tux, la mascotte ufficiale Linux creata da Larry Ewing nel 1996. Dove Tux è curato e iconico, il pinguino Cipi è disegnato in uno stile lineare minimale, fatto a mano: stessa specie, atteggiamento diverso. Pensalo come il fratello più tranquillo di Tux, che preferisce il terminale ai riflettori.
L'illustrazione è resa come SVG puro usando il colore accent del progetto, così si adatta naturalmente alla modalità chiara e scura e scala a qualsiasi dimensione senza perdere qualità.
Cipi vs alternative
Ci sono molti strumenti per provisionare e gestire web server. Questa pagina spiega dove si colloca Cipi in quel panorama e perché potresti — o non potresti — sceglierlo rispetto a ogni categoria. Il confronto è focalizzato su otto assi: integrazione AI (server MCP dual — per-app e globale), Laravel Octane (FrankenPHP) + Horizon + Reverb, deploy Git nativo (GitHub & GitLab), REST API, automazione CLI-first, crittografia a riposo (Vault), conformità GDPR e costo totale di proprietà.
Cerchi un confronto diretto? Vedi le pagine dedicate: alternativa a Laravel Forge, alternativa a Laravel Cloud, alternativa a Ploi, alternativa a Cleavr, alternativa a moss.sh, alternativa a Kamal, alternativa a RunCloud, alternativa a ServerPilot, alternativa a CloudPanel, alternativa a Coolify, alternativa a Dokku, alternativa a Easypanel, alternativa a Vito Deploy, alternativa a cPanel, alternativa a DirectAdmin, alternativa a Plesk, più sezioni approfondite su HestiaCP & VestaCP, aaPanel e GridPane, xCloud & ServerAvatar — oppure sfoglia tutte sulla panoramica alternative.
| Tool | Pronto per AI (MCP) | CLI / automazione | Gratis / OSS | Nessuna dip. SaaS |
|---|---|---|---|---|
| Cipi | ||||
| Laravel Cloud | parziale | usage-based | ||
| Laravel Forge | parziale | $12–19/mo | ||
| Ploi | parziale | €8–30/mo | ||
| moss.sh | free limitato / $9–49/mo | |||
| Cleavr | parziale | ~$8+/mo | ||
| Kamal | ||||
| Dokku | ||||
| Easypanel | parziale | |||
| RunCloud | $12–18/mo | |||
| CloudPanel | parziale | |||
| Coolify | parziale | |||
| ServerPilot | $12–49/mo | |||
| HestiaCP / VestaCP | ||||
| cPanel / Plesk | $20+/mo | |||
| DirectAdmin | $2–29/mo | |||
| aaPanel | ||||
| Vito Deploy | ||||
| GridPane / xCloud / ServerAvatar |
Cipi vs Laravel Cloud
Laravel Cloud è la piattaforma di deploy fully-managed del team Laravel — un Platform-as-a-Service che esegue la tua applicazione su infrastruttura AWS dedicata con autoscaling one-click, database gestiti (MySQL / Postgres serverless), cache Valkey, object storage, edge network con protezione DDoS, SSL automatico e compute scale-to-zero. Colleghi un provider Git, scegli un repo e fai deploy in meno di 60 secondi — senza server da gestire. È l'estremo opposto dello spettro rispetto a Cipi: dove Cipi ti dà piena proprietà di un VPS che controlli, Cloud astrae completamente il server in cambio di una fattura usage-based.
Dove vince Cipi:
- Costo e prevedibilità — Cloud è usage-based: paghi compute, database, cache, bandwidth e storage man mano che li consumi (dopo il credito mensile da $5). I costi scalano con il traffico e possono essere difficili da prevedere. Cipi è gratis per ogni server che possiedi, per sempre — l'unico costo è il VPS stesso, a prezzo fisso e prevedibile.
- Possiedi il server — Cloud gira su infrastruttura gestita interamente da Laravel su AWS; non ottieni mai root, SSH o controllo sulla macchina sottostante. Cipi gira sul tuo VPS con qualsiasi provider (Hetzner, OVH, DigitalOcean, AWS, bare metal) con accesso root completo e controllo totale dello stack.
- Nessuna dipendenza SaaS — Cloud è una piattaforma hosted: se smetti di pagare, le tue app smettono di girare, e la gestione dipende da un cloud.laravel.com raggiungibile. Cipi vive interamente sul tuo VPS e funziona indipendentemente da qualsiasi servizio esterno.
- Nessun vendor lock-in — Cloud lega deploy, database, queue e storage al suo ambiente AWS gestito. Migrare via significa ri-architetturare l'infrastruttura. Cipi usa Ubuntu standard, Nginx, PHP-FPM / Laravel Octane, MariaDB (PostgreSQL opzionale) e Supervisor — uno stack portabile che puoi spostare o riprodurre ovunque.
- Open source — Cipi ha licenza MIT; puoi leggere, auditare, forkare e modificare ogni riga. Laravel Cloud è una piattaforma proprietaria e chiusa.
- Automazione CLI e pipeline — Cipi è interamente operabile via SSH con comandi shell componibili che possono essere scriptati, concatenati in pipeline, attivati da webhook o eseguiti da una GitHub Action. Cloud espone una Cloud API e deploy hook, ma la gestione quotidiana è dashboard-centric.
- Server MCP dual — Cipi è l'unico pannello server con architettura MCP dual: un server MCP per-app e uno globale per creare, fare deploy, modificare, eliminare e gestire SSL su tutte le applicazioni. Cloud offre un'API che gli agenti AI possono chiamare, ma nessuna integrazione MCP nativa per gestione da IDE o agent.
- Crittografia a riposo — Tutti i file di configurazione Cipi (password, token, chiavi SSH) sono criptati con AES-256-CBC via il sistema Vault, sul tuo VPS. Cloud memorizza credenziali e variabili d'ambiente sulla sua infrastruttura gestita.
- GDPR / sovranità dati — Cipi gira interamente su un VPS nella regione che scegli, e nessun dato infrastrutturale lascia la tua macchina. Laravel Cloud è operato da una società USA su AWS e processa dati applicativi e infrastrutturali come processore terzo — richiedendo un DPA e attenta selezione regione per conformità GDPR.
- Sync e replica server — Sync server-to-server criptato integrato con
cipi sync pushabilita replica failover automatizzata via cron tra due istanze VPS. Cloud non ha un equivalente sync self-managed. - PostgreSQL opzionale sul tuo VPS — mantieni MariaDB come default o installa PostgreSQL con
cipi db install pgsqle scegli un motore per app — senza i prezzi database gestito di Cloud.
Dove vince Laravel Cloud: zero gestione server, autoscaling e scale-to-zero one-click, database e cache gestiti, edge network globale con protezione DDoS, SSL e load balancing automatici, queue gestite e dashboard curata — tutto senza toccare mai un server. Se vuoi un'esperienza stile serverless, non vuoi gestire o possedere un VPS e ti va bene una fattura usage-based, Cloud è la scelta migliore. Cipi è per team che vogliono possedere l'infrastruttura, controllare i costi e automatizzare tutto dalla CLI.
Cipi vs Laravel Forge
Forge è il concorrente più diretto e il benchmark nel settore — è costruito dal team Laravel, maturo, curato e collaudato sul campo su larga scala (970k+ server, 56M+ deploy). Ha una GUI pulita, deploy zero-downtime, monitoraggio server, heartbeat, health check e integrazione con tutti i principali cloud provider (AWS, DigitalOcean, Hetzner, Vultr e altri).
Dove vince Cipi:
- Costo — Forge parte da $12/mese per server. Cipi è gratis, per tutti i tuoi server, per sempre.
- Nessuna dipendenza SaaS — Forge richiede un abbonamento attivo e un forge.laravel.com raggiungibile per gestire i server. Se il servizio ha downtime o cancelli, perdi l'interfaccia di gestione. Cipi vive interamente sul tuo VPS — funziona indipendentemente da qualsiasi servizio esterno.
- Automazione CLI e pipeline — Cipi è interamente operabile via SSH con comandi shell componibili. Ogni operazione può essere scriptata, concatenata in pipeline, attivata da webhook o eseguita da una GitHub Action. L'automazione di Forge si basa principalmente sulla GUI e script di deploy.
- Open source — Cipi ha licenza MIT. Puoi leggere, auditare, forkare e modificare ogni riga. Forge è proprietario.
- Semplicità — Forge è cresciuto in una piattaforma ricca di funzionalità. Cipi ha una superficie deliberatamente piccola — un binario, una manciata di comandi, zero GUI.
- Deploy Git nativo (GitHub & GitLab) — Cipi fornisce integrazione deploy automatica con GitHub e GitLab già inclusa, con release zero-downtime guidate da webhook configurate in un solo comando.
- REST API — Cipi espone una REST API completa per gestire host e applicazioni programmaticamente, abilitando integrazione con tool esterni, dashboard e workflow custom.
- Server MCP dual — Cipi è l'unico pannello server con architettura MCP dual: un server MCP per-app per gestire una singola applicazione e uno globale per creare, fare deploy, modificare, eliminare e gestire certificati SSL su tutte le applicazioni del server. Questo abilita gestione infrastruttura completa guidata da AI da qualsiasi IDE o agent compatibile MCP.
- Crittografia a riposo — Tutti i file di configurazione Cipi (password, token, chiavi SSH) sono criptati con AES-256-CBC via il sistema Vault. Forge memorizza credenziali server sulla propria infrastruttura SaaS; Cipi mantiene tutto criptato sul tuo VPS.
- GDPR / sovranità dati — Cipi gira interamente sul tuo server. Nessun dato infrastrutturale viene inviato a terzi. Forge è operato da una società USA e processa metadata server sotto legge USA — richiedendo un DPA per conformità GDPR. Con Cipi non c'è processore dati terzo da gestire.
- Sync e replica server — Sync server-to-server criptato integrato con
cipi sync pushabilita replica failover automatizzata via cron. Forge non ha una funzionalità equivalente. - PostgreSQL opzionale — MariaDB resta il default; installa PostgreSQL con
cipi db install pgsqle scegli un motore per app. Stessa superficie di gestione DB di primo livello per entrambi i motori. - Laravel Octane (FrankenPHP) — crea o converti app in Octane con
cipi app create --octane/cipi app convert --to=octane, fai girare app FPM e Octane affiancate, più Horizon e Reverb di primo livello — tutto dalla CLI senza pannello SaaS.
Dove vince Forge: GUI, provisioning multi-cloud, team, dashboard monitoraggio, heartbeat, health check e anni di hardening produzione. Se il tuo team non è a suo agio con SSH e preferisce un'interfaccia visuale, o se devi gestire server su più account cloud, Forge è la scelta migliore.
Cipi vs Ploi
Ploi è un pannello gestione server SaaS con forte supporto Laravel, UI pulita e buon set di funzionalità (deploy zero-downtime, backup database automatici, backup file S3, gestione queue Supervisor, gestione DNS). Parte da €8/mese per server (Basic) fino a €30/mese (Unlimited).
Ploi scambia una fee mensile e dipendenza SaaS per una GUI curata e monitoraggio integrato. Cipi scambia la GUI per zero costi, codice open source, controllo CLI completo, REST API completa, integrazione deploy GitHub & GitLab nativa, server MCP dual per gestione guidata da AI, crittografia AES-256-CBC a riposo, sync server-to-server criptato integrato e Laravel Octane (FrankenPHP) con Horizon e Reverb come funzionalità CLI di primo livello. Sulla sovranità dati: Ploi è basato in EU (Paesi Bassi) e nativamente conforme GDPR — un vantaggio genuino rispetto a pannelli SaaS USA. Cipi va oltre: nessun dato infrastrutturale lascia il tuo VPS. Ploi è la scelta migliore se vuoi un'esperienza stile Forge a prezzo più basso e preferisci una GUI all'automazione CLI-first. Per opzioni SaaS simili vedi moss.sh e Cleavr.
Cipi vs RunCloud
RunCloud è un pannello di controllo SaaS orientato PHP che supporta Nginx e Apache, più versioni PHP e script di deploy base. È popolare per WordPress e app PHP generiche e costa $12–18/mese per server.
RunCloud non è Laravel-native: non ha integrazione Deployer integrata, nessun comando shortcut artisan, nessuna configurazione Supervisor automatica per queue Laravel e nessuna comprensione della struttura directory shared di Laravel. Fare deploy di un'app Laravel su RunCloud richiede configurazione manuale di molti pezzi che Cipi gestisce automaticamente. Se fai deploy esclusivamente Laravel, Cipi ti dà molto di più già incluso a costo zero.
Cipi vs CloudPanel
CloudPanel è un pannello gratuito open source che supporta PHP, Node.js, Python e siti statici. È ben mantenuto, ha una UI curata e include una CLI. È un'opzione genuinamente buona per team che devono hostare un mix di tipi applicativi sullo stesso server.
La differenza chiave è il focus: CloudPanel è un pannello multi-stack generico; Cipi è uno strumento solo Laravel. CloudPanel non ha integrazione Deployer, comandi artisan, setup automatico queue worker e nessun sistema deploy webhook pensato per Laravel. La CLI CloudPanel copre amministrazione server ma non gestione ciclo di vita applicazioni Laravel. Se fai deploy solo Laravel, l'approccio opinionato di Cipi ti dà un'esperienza più veloce e pulita. Se devi anche hostare Node.js, Python o WordPress accanto a Laravel, CloudPanel è la scelta più appropriata.
Cipi vs Vito Deploy
Vito Deploy è uno strumento gestione server gratuito open source self-hosted con dashboard GUI pulita, costruito con Laravel e htmx. Supporta PHP (inclusi Laravel e WordPress), MySQL, MariaDB e PostgreSQL, e include gestione SSL, configurazione firewall, worker background, cron job, monitoraggio server, collaborazione team, workflow custom, plugin e API. Cipi supporta MariaDB di default con PostgreSQL opzionale da v4.8.0.
Vito Deploy e Cipi condividono la stessa filosofia: gratis, open source e self-hosted — nessuna dipendenza SaaS. Le differenze chiave sono nell'approccio e nella profondità:
- GUI vs CLI — Vito Deploy è GUI-first con dashboard web; Cipi è CLI-first senza GUI. Se il tuo team preferisce un'interfaccia visuale, Vito Deploy è adatto. Se ti serve automazione scriptabile e pronta per pipeline, Cipi è la scelta migliore.
- Integrazione AI — Cipi fornisce un server MCP dual (per-app e globale) per gestione infrastruttura guidata da AI da qualsiasi IDE o agent compatibile MCP. Vito Deploy non ha integrazione MCP o AI.
- Automazione CLI — Cipi è interamente operabile via SSH con comandi shell componibili concatenabili in pipeline, attivabili da webhook o eseguibili da GitHub Actions. Vito Deploy si opera principalmente tramite dashboard web.
- Deploy Git nativo — Cipi fornisce integrazione deploy zero-downtime automatica guidata da webhook con GitHub e GitLab, configurata in un solo comando.
- Crittografia a riposo — Tutti i file di configurazione Cipi sono criptati con AES-256-CBC via il sistema Vault. Vito Deploy non pubblicizza crittografia config a riposo.
- Sync server — Cipi include sync server-to-server criptato integrato con
cipi sync pushper replica failover automatizzata. Vito Deploy non ha funzionalità equivalente. - Footprint infrastrutturale — Vito Deploy richiede un VPS o ambiente dedicato per hostare la propria dashboard (è un'applicazione Laravel completa con database). Cipi è un singolo binario che gira direttamente sullo stesso VPS delle tue applicazioni — nessun server aggiuntivo, nessun database separato, nessuna infrastruttura extra da mantenere o proteggere.
- Database multi-engine — Entrambi supportano MySQL/MariaDB/PostgreSQL. Cipi include MariaDB come default nativo e PostgreSQL opzionale via
cipi db install pgsql, con selezione motore per app e credenziali criptate Vault.
Vito Deploy è un'alternativa genuinamente buona nello spazio free/OSS self-hosted. Se vuoi una dashboard GUI con collaborazione team e monitoraggio, e non ti serve automazione CLI-first o integrazione AI, Vito Deploy merita valutazione.
Cipi vs Coolify
Coolify è un Platform-as-a-Service gratuito open source self-hosted che fa deploy di applicazioni come container Docker tramite dashboard web curata. Supporta PHP, Node.js, Python, siti statici, database e molti altri servizi, con deploy Git-based, SSL e capacità di gestire server remoti da un unico control plane. È diventato uno degli strumenti più popolari nella community self-hosting.
Coolify e Cipi condividono le stesse fondamenta: gratis, open source, self-hosted, nessun abbonamento SaaS. Le differenze chiave sono modello di deploy e focus:
- Docker vs stack nativo — Coolify è container-first: ogni applicazione gira in Docker con Traefik o simile come reverse proxy. Cipi installa uno stack nativo Nginx + PHP-FPM / Laravel Octane + MariaDB (PostgreSQL opzionale) + Supervisor direttamente su Ubuntu. Per app Laravel standard, Cipi evita overhead container, semplifica il debug e rimuove un layer di astrazione — con Octane, Horizon e Reverb di primo livello.
- GUI vs CLI — Coolify è GUI-first con dashboard web per ogni operazione. Cipi è CLI-first senza GUI. Se il tuo team preferisce un'interfaccia visuale e provisioning servizi one-click, Coolify è adatto. Se ti serve automazione scriptabile e pronta per pipeline, Cipi è la scelta migliore.
- Profondità Laravel — Cipi è Laravel-first: integrazione Deployer, shortcut artisan, setup automatico queue worker, release zero-downtime guidate da webhook e struttura directory release shared sono tutti integrati. Coolify può hostare Laravel, ma lo tratta come applicazione PHP generica senza gestione ciclo di vita Laravel-specifica.
- Integrazione AI — Cipi fornisce un server MCP dual (per-app e globale) per gestione infrastruttura guidata da AI da qualsiasi IDE o agent compatibile MCP. Coolify non ha integrazione MCP o AI.
- Crittografia a riposo — Tutti i file di configurazione Cipi sono criptati con AES-256-CBC via il sistema Vault. Coolify non pubblicizza crittografia config a riposo.
- Sync server — Cipi include sync server-to-server criptato integrato con
cipi sync pushper replica failover automatizzata. Coolify non ha funzionalità equivalente.
Coolify è un'ottima scelta se vuoi un PaaS self-hosted con GUI web, deploy Docker-based e flessibilità per hostare molti stack diversi sulla stessa piattaforma. Se fai deploy esclusivamente Laravel e vuoi automazione CLI-first, prestazioni PHP native e tooling Laravel-specifico, Cipi è l'opzione più focalizzata. Vedi il confronto dedicato Cipi vs Coolify.
Cipi vs Kamal
Kamal (ex MRSK) è uno strumento CLI gratuito open source (MIT) del team 37signals/Basecamp per fare deploy di applicazioni su qualsiasi server via SSH e Docker. È popolare nelle community Laravel e Ruby on Rails per deploy zero-downtime basati su container senza pannello hosting. Kamal e Cipi condividono una filosofia CLI-first — ma risolvono problemi diversi:
- Tool deploy vs pannello server completo — Kamal fa deploy di container su server già provisionati; non installa Nginx, PHP, MariaDB, regole firewall, SSL, backup o queue worker. Cipi è una CLI gestione server completa che provisiona lo stack produzione completo e gestisce l'intero ciclo di vita applicazione Laravel.
- Docker vs stack nativo — Kamal è container-first. Cipi esegue uno stack nativo Nginx + PHP-FPM / Laravel Octane + MariaDB (PostgreSQL opzionale) + Supervisor su Ubuntu — overhead minore e debug più semplice per app Laravel standard.
- Profondità Laravel — Cipi include integrazione Deployer, Laravel Octane, Horizon, Reverb, shortcut artisan, queue worker automatici, deploy Git zero-downtime guidati da webhook e struttura directory release shared. Kamal può fare deploy Laravel in Docker, ma senza gestione ciclo di vita Laravel-specifica.
- Integrazione AI, crittografia, sync — Cipi aggiunge server MCP dual, crittografia Vault AES-256-CBC a riposo, sync server-to-server criptato e REST API completa. Kamal non ha nessuno di questi.
Kamal è la scelta giusta se già gestisci infrastruttura Docker e ti serve solo una CLI deploy leggera e collaudata sul campo. Cipi è la scelta giusta se vuoi uno strumento per provisionare, proteggere, fare deploy e operare server Laravel da zero. Vedi il confronto Cipi vs Kamal.
Cipi vs Cleavr
Cleavr è un pannello gestione server SaaS con forte supporto Laravel — deploy zero-downtime, queue worker, SSL, gestione database e GUI web curata. Sta nella stessa categoria di Forge e Ploi: colleghi il VPS al control plane Cleavr e gestisci tutto tramite dashboard browser, partendo da circa $8/mese per server.
Cipi scambia GUI e fee mensile per zero costi, MIT open source, controllo CLI completo, server MCP dual, crittografia config AES-256 a riposo e sync server-to-server criptato integrato. Cleavr resta la scelta migliore se il tuo team preferisce un'interfaccia visuale e non ha bisogno di automazione pipeline CLI-first o integrazione AI. Vedi il confronto Cipi vs Cleavr.
Cipi vs Dokku
Dokku è un Platform-as-a-Service gratuito open source (MIT) self-hosted — spesso descritto come "Heroku sul tuo VPS". Fai push del codice con Git e Dokku builda ed esegue container Docker, con un ricco ecosistema plugin per database, SSL e scheduling. È orientato CLI e self-hosted, senza dipendenza SaaS.
Il confronto con Cipi rispecchia Coolify a peso minore: Dokku è git-push + container; Cipi è Laravel-first su stack LEMP nativo con provisioning server completo, Deployer, artisan, queue, MCP dual, crittografia Vault e sync server. Dokku vince su semplicità git-push e isolamento container per team già committed a Docker. Cipi vince su automazione Laravel-specifica senza overhead container. Vedi il confronto Cipi vs Dokku.
Cipi vs Easypanel
Easypanel è un Docker PaaS gratuito open source self-hosted con GUI web — simile per scope a Coolify. Fa deploy di applicazioni come container, supporta molti stack e fornisce database e servizi one-click tramite dashboard.
Easypanel e Cipi differiscono sugli stessi assi di Coolify: GUI + Docker PaaS vs CLI + stack Laravel nativo. Se vuoi un PaaS self-hosted visuale con workflow container, Easypanel merita valutazione. Se fai deploy esclusivamente Laravel e vuoi automazione CLI-first senza Docker, Cipi è l'opzione più focalizzata. Vedi il confronto Cipi vs Easypanel.
Cipi vs moss.sh
moss.sh è un "sysadmin virtuale" SaaS per freelancer e agenzie. Supporta PHP, Laravel, Symfony, WordPress e Node.js su server Ubuntu, con piani da $9 a $49/mese e tier free limitato a 25 git deploy al mese.
Moss e Cipi targetizzano carichi simili ma filosofie opposte: Moss è SaaS GUI-first con quote deploy sul tier free; Cipi è CLI-first, gratis per sempre, self-hosted, senza limiti deploy, MCP dual, crittografia Vault e sync server. Moss non è Laravel-exclusive — nessun Deployer o shortcut artisan integrati. Vedi il confronto Cipi vs moss.sh.
Cipi vs ServerPilot
ServerPilot è un pannello SaaS focalizzato PHP/WordPress ($12–49/mese) che automatizza setup PHP-FPM e Nginx. Non ha tooling Laravel-specifico, nessuna CLI per gestione applicazioni e nessun sistema deploy zero-downtime. È principalmente rivolto a sviluppatori WordPress che vogliono aggiornamenti PHP automatici senza pensare all'interno del server. Per sviluppatori Laravel, offre poco valore rispetto a Cipi a costo ricorrente significativo.
Cipi vs GridPane, xCloud, ServerAvatar
Questi tre pannelli sono focalizzati su WordPress e WooCommerce, non PHP in generale e certamente non Laravel specificamente. Ottimizzano per workflow WordPress-centrici (clone staging, multisite, Redis object cache per WP, integrazione Cloudflare per WordPress). Nessuno ha tooling Laravel-specifico. Se il tuo carico è WordPress, valutali per i loro meriti. Se il tuo carico è Laravel, non sono la categoria giusta di strumento.
Cipi vs cPanel & Plesk
cPanel e Plesk sono pannelli di controllo hosting tradizionali pensati per rivenditori shared hosting: gestiscono account email, FTP, zone DNS, database e siti multipli di clienti su una macchina. Sono costosi (cPanel parte da $20+/mese per server, Plesk similmente), solo GUI, costruiti attorno ad Apache di default e portano complessità enorme — la maggior parte irrilevante quando fai deploy di un'applicazione Laravel single-stack.
Sono lo strumento giusto per provider hosting che vendono account shared hosting a clienti non tecnici. Sono lo strumento sbagliato per un team di sviluppo che possiede il proprio VPS e fa deploy di app Laravel. Cipi è costruito apposta per quest'ultimo scenario a costo zero. Per un pannello proprietario più leggero nella stessa categoria, vedi anche DirectAdmin — coperto nel confronto dedicato Cipi vs DirectAdmin.
Cipi vs DirectAdmin
DirectAdmin è un pannello di controllo shared hosting proprietario posizionato come alternativa più leggera e economica a cPanel. Gestisce email, FTP, DNS, database e siti multipli di clienti su un server tramite GUI web, con funzionalità reseller e licenze tiered da circa $2 a $29 al mese a seconda dei limiti account.
DirectAdmin e Cipi targetizzano casi d'uso opposti. DirectAdmin è per provider hosting che rivendono shared hosting; Cipi è per team di sviluppo che fanno deploy Laravel su VPS dedicato. DirectAdmin non ha integrazione Deployer, comandi artisan, queue worker automatici e nessun sistema deploy zero-downtime guidato da webhook. Può hostare PHP/Laravel manualmente, ma non offre gestione ciclo di vita Laravel-specifica.
DirectAdmin è una scelta ragionevole se gestisci un piccolo business hosting e ti serve una GUI per amministrazione multi-tenant email, DNS e siti a costo inferiore a cPanel. Per un team che possiede il proprio server e fa deploy esclusivamente Laravel, Cipi è gratis, open source, CLI-first e molto più capace già incluso. Vedi il confronto completo.
Cipi vs Webmin
Webmin è un'interfaccia gratuita open source basata su browser per amministrazione Unix low-level — gestire utenti, cron job, pacchetti, regole firewall, servizi e uso disco tramite GUI invece della shell. Non è un pannello hosting né uno strumento deploy; è una console amministrazione remota per sysadmin. Virtualmin è il modulo hosting-focused costruito sopra Webmin.
Webmin e Cipi risolvono problemi completamente diversi. Webmin ti permette di amministrare un server; Cipi ti permette di fare deploy e gestire applicazioni Laravel su un server. Non sono mutualmente esclusivi — potresti tecnicamente far girare entrambi sulla stessa macchina — ma la CLI di Cipi sostituisce qualsiasi bisogno di console admin GUI per i task che copre (creazione app, deploy, gestione PHP, firewall, SSL, backup). Webmin non ha consapevolezza Laravel: nessun Deployer, artisan, queue worker, gestione release zero-downtime.
Se il tuo team ha bisogno di un'interfaccia point-and-click per manutenzione server generale (modificare /etc/hosts, gestire utenti di sistema, rivedere log visivamente), Webmin è uno strumento complementare ragionevole. Per deploy Laravel specificamente, Cipi è più capace e non richiede browser o sessione attiva.
Cipi vs Virtualmin, ISPConfig, Froxlor, Ajenti
Questi sono pannelli hosting gratuiti open source pensati per ISP, rivenditori hosting e amministratori di sistema che gestiscono molti tenant su una singola macchina. Condividono tutti caratteristiche simili: server email (Postfix/Dovecot), DNS (BIND), FTP (ProFTPD/vsftpd), gestione virtual host multipli e permessi multi-utente complessi. Sono potenti ma hanno curve di apprendimento ripide e sono pensati per ambienti molto più complessi di un server applicazione Laravel dedicato.
Nessuno ha tooling Laravel-specifico. Nessuno integra Deployer. Nessuno è CLI-first nel senso che ogni operazione può essere scriptata. Per un team che fa deploy esclusivamente Laravel, sono overbuilt e sotto-specializzati rispetto a Cipi.
Cipi vs HestiaCP & VestaCP
VestaCP è stato di fatto abbandonato dal 2019. HestiaCP è il fork community attivo — gratis, open source e mantenuto. È un'alternativa più leggera a cPanel per hosting generico (email, FTP, DNS, più versioni PHP). Come gli altri pannelli tradizionali, non ha tooling Laravel-specifico: nessun Deployer, queue worker gestiti automaticamente, nessuna integrazione artisan. Il pubblico primario sono piccoli business hosting o individui che vogliono una GUI per gestire più siti su un server attraverso più stack. Se fai deploy solo Laravel, Cipi è l'opzione più focalizzata e semplice.
Cipi vs aaPanel
aaPanel (noto anche come BaoTa Panel) è un pannello gratuito di origine cinese, ampiamente usato nella regione Asia-Pacifico. Supporta stack LNMP/LAMP, Node.js, Docker e vari motori database tramite sistema plugin. È genuinamente capace e ha una grande base utenti, ma è uno strumento multi-stack generico con filosofia GUI-centric e nessuna automazione Laravel-native. La comunicazione server è gestita tramite l'agent del pannello, creando dipendenza dall'infrastruttura del pannello simile a tool SaaS. Per deploy Laravel-specifici e guidati da CLI, Cipi è più adatto.
Cipi vs CentOS Web Panel (CWP / AlmaLinux Web Panel)
CentOS Web Panel — ora riposizionato attorno ad AlmaLinux — è un pannello hosting tradizionale storicamente legato all'ecosistema RHEL. Cipi targetizza esclusivamente Ubuntu, che è l'OS dominante per deploy Laravel moderni e dove la PPA ondrej/php dà accesso a tutte le versioni PHP da 7.4 a 8.5 entro ore dal rilascio. Oltre al mismatch OS, CWP è un pannello generico senza tooling Laravel e overhead complessità significativo per un server applicazione Laravel singola.
Cipi vs ZPanel
ZPanel è di fatto non mantenuto e non dovrebbe essere usato per nuovi deploy. È incluso qui solo perché compare nei confronti sul web. Scegli una delle altre opzioni elencate in questa pagina.
Privacy, GDPR e sovranità dati
Questa dimensione è raramente discussa nei confronti tra strumenti ma è legalmente significativa per team che processano dati personali — aziende EU, healthcare, fintech o qualsiasi prodotto soggetto a GDPR, HIPAA o regolamenti locali protezione dati.
Pannelli SaaS e data residency
Quando colleghi un server a un pannello SaaS (Forge, Ploi, RunCloud, ServerPilot, xCloud, GridPane, ServerAvatar), stai fornendo a quel servizio dati sulla tua infrastruttura: indirizzi IP server, hostname, credenziali deploy, nomi variabili d'ambiente e in alcuni casi chiavi SSH private o deploy token. Il provider SaaS memorizza e processa questi dati sulla propria infrastruttura, che può trovarsi in giurisdizioni fuori dall'EU.
- Laravel Forge è operato da Laravel LLC, società USA. I dati sono processati sotto legge USA. Sotto GDPR, Forge agisce come processore dati per i tuoi dati infrastrutturali, il che richiede un Data Processing Agreement (DPA) firmato. Al 2025, Forge fornisce un DPA su richiesta, ma i dati restano su server USA.
- Ploi è operato da WebBuilds B.V., società olandese — basato in EU e nativamente soggetto a GDPR. Questo lo rende l'opzione SaaS più conforme in questa lista per team EU. I dati sono hostati in Europa.
- RunCloud, ServerPilot, GridPane, ServerAvatar, xCloud sono principalmente società USA o non-EU. Data residency e disponibilità DPA variano; controlla privacy policy e stato DPA di ogni provider prima di usarli con dati soggetti a GDPR.
- aaPanel è di origine cinese. La sua privacy policy e gestione dati sono soggette a legge cinese, inclusi Personal Information Protection Law (PIPL) e Data Security Law (DSL), che in certe circostanze permettono accesso governativo cinese a dati su sistemi operati dalla Cina. Per team EU o team che processano dati sensibili, questa è una considerazione compliance significativa.
- Vito Deploy è self-hosted — come Cipi, nessun dato infrastrutturale lascia il tuo VPS. Da prospettiva GDPR, Vito Deploy condivide lo stesso vantaggio: nessun processore dati terzo per gestione server. Tuttavia, Vito Deploy non pubblicizza crittografia a riposo per file di configurazione, mentre Cipi cripta tutte le config con AES-256-CBC via il sistema Vault.
- Coolify è anche self-hosted — i dati infrastrutturali restano sul tuo VPS senza dipendenza control plane SaaS. Come Vito Deploy, Coolify non pubblicizza crittografia a riposo per file di configurazione, mentre Cipi cripta tutte le config con AES-256-CBC via il sistema Vault.
- Kamal, Dokku e Easypanel sono self-hosted — nessun processore dati terzo per gestione server. Non pubblicizzano crittografia config a riposo per file di configurazione, mentre Cipi cripta tutte le config con AES-256-CBC via il sistema Vault.
Cipi: self-contained, zero data exfiltration
Cipi è installato direttamente sul tuo VPS e opera interamente nella tua infrastruttura. Non fa phone home, non invia telemetria e non contatta servizi esterni durante operazione normale (le uniche chiamate esterne sono a GitHub per self-update e a Let's Encrypt per certificati SSL — entrambe standard e opzionali). Nessun metadata server, credenziale o dato applicativo lascia mai la tua macchina.
Da prospettiva GDPR, questo significa:
- Nessun processore dati terzo per gestione infrastruttura — sei l'unico titolare e processore per le operazioni di gestione server.
- Nessun DPA richiesto con Cipi stesso (non c'è una società Cipi che processa i tuoi dati).
- Piena sovranità dati — i dati del tuo server restano nella giurisdizione dove è hostato il VPS, che scegli liberamente (Hetzner DE, OVH FR, AWS eu-central-1, ecc.).
- Audit trail più semplici — ogni azione Cipi è loggata localmente in
/var/log/cipi/cipi.log, accessibile solo a te, non a una dashboard terza.
Quando scegliere Cipi
- Fai deploy di Laravel — Cipi è pensato principalmente per Laravel, con supporto app custom per siti statici, SPA, WordPress e altri progetti PHP.
- Vuoi zero costo mensile del pannello — un server o cinquanta, il prezzo è lo stesso. e non ti serve un contratto di supporto commerciale
- Ti serve automazione CLI e pipeline completa — ogni operazione Cipi è scriptabile via SSH.
- Ti serve deploy Git nativo — integrazione deploy automatica con GitHub e GitLab, con release zero-downtime guidate da webhook.
- Ti serve una REST API — controllo programmatico completo su host e applicazioni per integrazione con tool esterni, dashboard e workflow custom.
- Ti serve gestione guidata da AI — il server MCP dual di Cipi (per-app e globale) abilita creazione, deploy, modifica, eliminazione e gestione certificati SSL su tutte le applicazioni da qualsiasi IDE o agent AI compatibile MCP.
- Vuoi nessuna dipendenza esterna — il pannello vive sul tuo VPS e funziona indipendentemente da qualsiasi SaaS.
- Valorizzi open source e auditabilità — ogni riga di Cipi è leggibile, forkabile e con licenza MIT.
- Ti serve conformità GDPR / sovranità dati — nessun dato infrastrutturale lascia il tuo VPS, nessun processore dati terzo, nessun DPA richiesto.
- Ti serve crittografia a riposo — tutti i file di configurazione, credenziali e chiavi SSH sono criptati con AES-256-CBC via il sistema Vault. Anche gli archivi sync sono criptati con passphrase definita dall'utente.
- Ti serve sync e replica server-to-server —
cipi sync pushabilita replica failover automatizzata via cron, con trasferimento criptato e aggiornamenti incrementali. - Ti servono MariaDB e PostgreSQL opzionale — MariaDB di default, PostgreSQL via
cipi db install pgsql, con selezione motore per app.