Odoo Hosting
The Glo team are specialists in all aspects of
business IT solutions from cyber security,
networking infrastructures to cloud-based
hosting and remote access support.
We've turned our IT background into a
strength in the Odoo world.
Why choose Glo?
We’ll host your Odoo instance with the same security, protection and care that we give our own Odoo instance. We’ll also reduce the time and costs involved in developing, maintaining, and updating it.
Many Odoo partners will only support Odoo.sh. We don't.
As of April 2025 Odoo reported that there are over 9500 partners worldwide. The number of those partners, some of which are Gold partners, who fundamentally do not understand how to run Odoo, provide complete backups, are scared of tiny 10GB databases, or seemingly care is horrifying.
We use our extensive knowledge and experience in the IT world and bring it to running your Odoo installation. We aren't just another partner that uses Odoo.sh, or Cloudpepper.io, and we have no plans to be.
Glo | Odoo.sh | Cloudpepper | |
Managed service | Yes. We don't offer hosting to anyone with a credit card. We're here to understand your installation, what makes it unique, tune it and proactively monitor it. We're here for the long term partnership. | Semi-managed You're expected to understand GitHub, branches, etc. | Semi-managed We'll prefix this with that fact that we're really impressed with Cloudpepper. It's pretty cool. However, we believe that it hides the complexity too much. That moment where Odoo has a wobble and you're back into needing to know what Linux is and how it works, or face a restore. |
Slow? (We all know that Odoo isn't necessarily blazingly fast, but within the boundaries of what Odoo is and how it performs) | No | Can be. Odoo's cloud platform, automatically shuts down inactive Odoo instances to manage server resources and ensure fair usage, however at the expense of leaving Odoo slow to load. | Variable. |
Highly available PostgreSQL (that's the database that powers Odoo) | Yes. All of our hosted production installs run a dedicated highly available PostgreSQL just for your install, by default. That's just the way that it should be. | Unknown | No |
Highly available Odoo instances | Yes. We run Odoo on a highly available cluster with monitoring, powered by Kubernetes, with auto-recovery. | Historically, no. Under recent Odoo.sh migration to GCP we're unclear. | No |
Backup frequency | We are truly paranoid about backups (continuous PostgreSQL backups, multiple snapshots per day) - and we are happy to ship you a copy of your backups for you to store. If you're curious, check out the little description below. | Daily | Variable |
Supports EoL Odoo versions | Yes. We're also happy to support older versions of Odoo that Odoo.sh cannot. However, there does need to be a point where you consider upgrading. Luckily we can help with that. | No. | Yes |
Shared and dedicated options | Yes | Yes | Dedicated only |
Sidecar services | As great as Odoo.sh is, there's many things you'll find that once you get to a certain size, Odoo.sh won't accomodate. Our hosting is bespoke, managed and monitored. If you need a site-to-site VPNs, ODBC access, SFTP or FTP servers for EDI integration, or just peace of mind, then we can help. | No | Yes. However, you self manage these, meaning you require Linux experience. |
Core part of the business | Yes. We're so confident that we openly blog about how we run Odoo for you. | We believe that Odoo SA don't prioritise Odoo.sh, or apps.odoo.com. Recent incidents:
| Yes |
Core & Enterprise patch/update frequency | As required, or automated as often as you like | Weekly | Variable |
Easy to boot up locally? | This is an arguable one. We think it's easier to boot up projects that we setup and run using our Odoo project scaffolding vs Odoo.sh. Of course you can take a backup and restore locally irrespective of how it's hosted. However, we use the same project template for all customers. Booting up a running copy is a 2 command process (once all the rereqs are installed). | No | No |
Why should you not consider Glo?
Our offering isn't for everyone. We don't try to be.
We're offering a fully managed solution. If you're after access via SSH, Odoo shell, log or other monitoring access, we're not the solution you're looking for.
Our container and project setup does not follow the Odoo.sh "standard".
Due to the fact that we're technically "on-premise" Odoo SA will consider any long term (read: > 30 days) active testing/UAT/staging deployment as needing their own set of licenses.
We're truly paranoid about backups
Odoo.sh takes production backups every 24 hours. That's completely unacceptable if you're running an active business. Imagine 24 hours of lost sales and stock movements!
We take 2 forms of backup as standard as part of hosting your production copy of Odoo. Both forms are kept for 14 days by default. One is "continuous" and another is 3x a day.
All backups are stored off-site and encrypted, and replicated to multiple physical locations (We will be likely changing the backup destination to another land mass in the near future).
If you have special requirements we can happily change this (for example we have some customers who also want weekly, monthly and yearly kept for 2 years - however there is additional cost for that storage. We also have other customers where we export a backup daily for them to manage and retain).
Want to get technical about backups?
To explain in a bit more detail about the 2 different types of backups and why.
As a refresher, Odoo keeps its data in 2 places: a database and something called the "filestore" which typically stores attachments.
By default we take:
- 3x a day full snapshots of both the database and filestore. These are kept for 14 days.
- Additionally, we also have something called "WAL" archiving for the database only. Think of this as effectively a form of continuous backup for the database. These allow us to do what is called a Point in Time Restore for the entire database (i.e. say 10:04pm Tuesday).
In addition to the WAL archiving, all production installs hosted with us, now have a minimum of 2 running copies of the database cluster, should one database server become damaged the secondary will automatically take over.
Each copy is always running on a different virtual machine. We actually use this process during security patching to ensure that you have minimal downtime!
We're so confident that we've even demonstrated deleting our own primary database on a call with a customer, in real time, and allowed them to watch the automated recovery process.