Odoo Online, Odoo.sh or your own infrastructure
The hosting decision looks like a line item and behaves like a constraint. It determines what you are allowed to build, who is responsible when it breaks, and how hard it is to change your mind.
Hosting gets decided early, quickly, and usually on price. It then quietly governs what the implementation is able to do for the next several years.
Worth ten minutes of thought rather than two.
What actually differs
Set aside the marketing and there are three things that change between the options: how much you can customise, who is accountable when something breaks, and how much operational work lands on you.
Odoo Online is the managed, hosted product. Upgrades, backups and infrastructure are handled. The trade is that you work within what the platform allows, which rules out custom code. For a business whose requirements are met by configuration, that is not a limitation, it is the whole point: nobody has to think about a server again.
Odoo.sh is the platform intended for implementations that need real code. You get staging environments, a deployment pipeline tied to a repository, and the ability to run custom modules, while Odoo still handles the underlying infrastructure. It is the middle option and for most businesses running any custom development it is the sensible default.
Self-managed means you or your provider run it. Complete freedom, including the freedom to do things that will hurt you later, and complete responsibility: operating system patching, database administration, backups, restores, monitoring, upgrades, capacity. Legitimate when there is a real constraint driving it, such as an integration that must sit inside your own network, or data residency requirements you have to satisfy specifically.
The question that decides it
Not price. Will this implementation need custom code?
If no, and you are confident, Odoo Online removes an entire category of work from your life. If yes, or if you are honestly unsure, you want a platform that supports it, because discovering the constraint after go-live is an expensive migration rather than a settings change.
The second question is who is going to run it at 2am. Self-managed is only cheaper if you already have, and will keep, the capability to operate a production database platform. Most businesses of forty people do not, and the saving on hosting is consumed by the first serious incident.
The parts people underestimate
Backups are not the same as recovery. Whichever option you choose, know how long a restore takes and prove it once. On a managed platform this is a question to ask; on self-managed it is a task to schedule.
Staging environments matter more than they sound. Testing a configuration change, a custom module or an upgrade against a copy of production is what makes changes routine. Without one, every change is performed live, which is how businesses end up afraid to change anything.
Integrations shape the choice. If Odoo needs to reach line equipment, a device on a factory network, or a system that has no public endpoint, that constrains where it can sensibly live. Work this out before choosing, not after.
Moving later is possible and not free. Database migration, re-testing custom code, a cutover window. Treat the decision as durable even though it is technically reversible.
Licensing, briefly
Hosting and licensing are separate things and get conflated. The user count and the apps you enable drive licence cost regardless of where it runs, so a hosting decision made to reduce licensing will not.
We resell Odoo licensing through the partnership, so read that in the appropriate light: it is a reason to check our advice, and a reason we would rather set out the tradeoffs than recommend one option generally.
What we would ask you
Two questions, in this order. Does anything about how you work require code rather than configuration? And is there a specific constraint, network, residency or integration, that requires this to run inside your own infrastructure?
Most businesses answer no to the second. The first is the one that decides it, and it is answerable during discovery, before anyone commits to a platform.