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