Online vs .sh vs On-premise
Confronto dei 3 tipi di hosting che odoo offre.
Online (SaaS) -> Software as a service
la soluzione cloud “chiavi in mano” di Odoo.
| Pro | Contro |
| L’istanza è completamente gestita da Odoo S.A., in cloud, con server, manutenzione, backup, aggiornamenti automatici. | Non è permesso installare moduli “non standard” / modificare il core code. |
| Backup automatici giornalieri, tipicamente con replicazione su più data-centre/distribuiti geograficamente. | Non si ha controllo diretto sulle risorse server (CPU, RAM, workers) o sull’infrastruttura sottostante. |
| SLA garantito: ad esempio “99,9% uptime” indicato per Odoo Online. | Migrazione da Odoo Online ad altre modalità richiede che il database sia “pulito” da moduli non-standard o che siano prima disinstallati. |
| È previsto un server email integrato già configurato. | |
| Migrazione automatica alle nuove versioni (major) inclusa, per le app “certificate”. | |
|
Ideale per database con struttura relativamente standard, pochi moduli custom o processi molto particolari. |
|
|
Pro Tecnici |
Contro Tecnici |
|
Setup rapidissimo, gestione infrastruttura minima (quasi nulla per l’utente). |
Nessun o pochissimo accesso al layer server/infrastruttura → se hai esigenza di ottimizzare performance (workers, tuning PostgreSQL, caching) sei limitato |
|
Aggiornamenti major + minor “automatici” inclusi senza che tu debba curare upgrade server. |
Se hai moduli molto custom, modifiche al core, o integrazioni complesse, sei quasi bloccato. |
|
Backup/disaster recovery già predisposti, buona ridondanza. |
Migrazione “fuori” (verso PaaS o On-Premises) può richiedere pulizia/moduli standardizzati |
|
Budget più prevedibile (canone utente + hosting) senza sorprese infrastrutturali. |
Se hai esigenze di compliance molto severe (es. data-residency, certificazioni ISO, controllo fisico su server), potresti essere penalizzato. |
Online .sh (PaaS) -> Platform as a Service
hosting cloud gestito da Odoo con più flessibilità per personalizzazioni/moduli.
| Pro | Contro |
| Hosting gestito da Odoo S.A., ma con maggior flessibilità: consente installazione di moduli di terze parti, sviluppo di moduli custom, gestione del codice attraverso branch, staging, test, CI/CD integrato. | Non hai lo stesso livello di accesso “server fisico” come On-Premises: alcune configurazioni di infrastruttura avanzata possono non essere possibili. |
| Possibilità di scegliere numero di workers, storage, numero ambienti (produzione, staging, dev) e quindi scalare in base a esigenze. | Costi che aumentano con il numero di workers/dischi/uso risorse; modulazione più ampia ma anche più “a scatto”. Reddit dice: “you will run into problems with workers and have to upgrade … storage/backups cost”. |
| Anche qui backup automatici e ridondanza su più DC. | Anche se molto flessibile, alcune app della community possono non essere garantite al 100% in ambiente Odoo.sh (vedi post Reddit: “Any app you see from the appstore or OCA … is NOT guaranteed to work on odoo.sh.”) |
| Permette una buona integrazione con GitHub, test automatici per commit di codice, gestione branch ecc. | |
| Ideale per aziende di medio livello che hanno moduli custom, integrazioni, ma non vogliono gestire tutti i server internamente. | |
|
Pro Tecnici |
Contro Tecnici |
|
Ottimo compromesso “gestito + personalizzabile”. |
Mancanza di controllo assoluto su infrastruttura → se hai requisiti di tuning molto avanzato (es. cluster Postgres, sharding, GPU, custom caching distribuito) potresti restare limitato. |
|
Ambiente dev/test/staging pronto e integrato, flusso di sviluppo supportato nativamente. |
Costi che possono crescere velocemente in base a risorse necessarie (storage, workers, backup volume). |
|
Scalabilità e opzioni (workers, storage) modulabili. |
Richiede competenze tecniche (sviluppo moduli, branch management, CI/CD) o partner competente. |
|
Backup rimanendo parte del servizio gestito. |
Alcune app 3rd-party o OCA potrebbero dar problemi o non essere perfettamente compatibili — quindi testare bene è fondamentale |
On-Premises (self-hosting)
installazione in casa / su server controllato dall’azienda o da un partner, con pieno controllo
| Pro | Contro |
| Installazione su infrastruttura che scegli tu: può essere un server interno all’azienda, oppure “cloud self-managed” (es. VPS, IaaS) che però controlli tu. | Richiede competenze interne o partnership forte: sysadmin, DBA, dev Odoo, networking, sicurezza. |
|
Hai accesso al livello server/infrastruttura completo: sistema operativo, tuning DB (PostgreSQL), caching (Redis, memcached), workers, configurazione cluster, backup custom, disaster recovery, sicurezza fisica o virtuale, network, firewall. |
Devi definire e gestire SLA, monitoraggio, disaster recovery, test/staging/produzione, eventuali cluster di DB se necessario. |
| Nessuna limitazione in termini di moduli: puoi installare moduli enterprise, moduli community, moduli fatti su misura, modificare il core se vuoi. | Sei responsabile della manutenzione: backups, aggiornamenti di Odoo, aggiornamenti del sistema operativo, patch di sicurezza, monitoraggio, scalabilità, failover, DRP (disaster recovery plan) ecc. |
| Se hai requisiti di dati (es. risidenza dati UE, norme GDPR, certificazioni ISO, requisiti di sicurezza elevati) puoi scegliere dove fisicamente risiedono i server e come sono gestiti. | |
| Migrazione: se proveniente da Online o Odoo.sh, puoi “scaricare” il dump del database e filestore e restaurarlo. Nel processo, devi assicurarti compatibilità di versioni, filestore, moduli | |
|
Pro Tecnico |
Contro Tecnico |
| Massima libertà e controllo su: infrastruttura, tuning prestazioni, sicurezza, personalizzazioni, integrazioni molto complesse. | Richiede notevole investimento iniziale (hardware/VM, licenze, personale) e costi ricorrenti di gestione (manutenzione, backup, sicurezza, aggiornamenti). |
|
Possibilità di scalare come vuoi e ottimizzare costi/hardware in base alle tue esigenze. |
Maggiore complessità e tempo per setup, test, messa in produzione. |
| Flessibilità estrema: scegliere provider, configurazione, sistema operativo, hardware, backup, DRP, architettura (cluster, alta disponibilità). |
Bisogna gestire internamente la disponibilità, ridondanza, disaster recovery: se non lo fai bene rischi downtime, problemi di performance, sicurezza. |
|
Ideale per ambienti mission-critical, grandi volumi dati, processi molto complessi, normative stringenti. |
Aggiornamenti major/minor Odoo: anche se Odoo rilascia versioni, sei tu a doverli installare/testare, gestire compatibilità moduli custom. |
|
|
Se la tua azienda non ha competenze IT adeguate, rischi costi nascosti o affidabilità inferiore. |
Tabella riassuntiva
| Modalità | Livello personalizzazione | Controllo infrastruttura / risorse | Backup / DR / upgrade | Requisiti competenze | Quando usarla |
|---|---|---|---|---|---|
| Odoo Online | Limitatissima (solo Odoo Studio) | Basso | Gestiti da Odoo (backup giornalieri, upgrade automatici) (Odoo) | Minime | Startup / piccole aziende con processi standard |
| Odoo sh | Alta (moduli custom, branch, CI) | Medio (alcuni parametri regolabili: workers, storage) | Backup automatici + strumenti dev/test (Heliconia Solutions) | Medio (sviluppatori / partner) | Aziende medie che hanno bisogno di personalizzazione |
| On-Premises | Massima (accesso a tutto) | Massimo (decidi hardware, DB, cluster) | Devi gestire tu backup, DR, upgrade (a1consulting.asia) | Elevate (IT interna o partner forte) | Aziende grandi / regolamentate / processi complessi |
Checklist per proporre la soluzione adatta
| Domanda | Se sì → indica che sei pronto per modalità più “alta” | Se no → segnala area di attenzione |
|---|---|---|
| Abbiamo processi aziendali abbastanza standard, con poche personalizzazioni custom? | ⇒ Odoo Online potrebbe bastare | ⇒ Potrebbe servire Odoo.sh o On-Premises |
| Prevediamo integrazioni con sistemi esterni (es. ecommerce, BI, sistemi legacy)? | ⇒ Favorisce Odoo.sh o On-Premises | ⇒ Odoo Online potrebbe essere sufficiente |
| Abbiamo un team IT o partner capace di gestire server, backup, aggiornamenti, tuning DB? | ⇒ On-Premises è fattibile | ⇒ Se no, orientarsi verso Odoo.sh o Odoo Online |
| Abbiamo bisogno di installare/modificare moduli non-standard o modificare il core di Odoo? | ⇒ Odoo.sh o meglio On-Premises | ⇒ Se no, Odoo Online può andare |
| Abbiamo requisiti normativi elevati (es. GDPR, data residency UE, certificazioni, audit)? | ⇒ Preferibilmente On-Premises o Almeno scegliere zona UE in cloud | ⇒ Odoo Online va bene ma verifica data centre |
| Prevediamo di scalare significativamente utenti/volume/dati nei prossimi anni? | ⇒ Importante considerare Odoo.sh o On-Premises con scalabilità | ⇒ Se crescita modesta, Odoo Online ok |
| Vogliamo ambienti di test/staging/dev separati dall’ambiente produttivo? | ⇒ Odoo.sh (ha supporto) o On-Premises | ⇒ Odoo Online ha limitazioni |
| Il budget iniziale e gestione operativa (IT, server) è limitata? | ⇒ Odoo Online più semplice da gestire | ⇒ Se budget maggiore, valutare On-Premises |
| Stiamo già usando moduli community/terze parti e non possiamo rinunciarci? | ⇒ Odoo.sh o On-Premises | ⇒ Se solo moduli certificate Odoo, Odoo Online può essere sufficiente |
| Prevediamo migrazione futura da Odoo Online verso altro? | ⇒ Verificare che database sia “pulito” (senza moduli non standard) | ⇒ Se non prevediamo migrazione, meno vincoli |