The Odoo Cloud Platform | Frequently Asked Questions

For Developers

The Odoo.sh platform enforces specific memory and CPU usage limits to ensure equitable distribution of server resources. Consequently, idle Odoo workers may be terminated after a predefined period but are automatically re-spawned upon subsequent activity, ensuring continuous operation.

Odoo.sh is exclusively designed for hosting Odoo-based solutions. The platform does not support the use of additional daemonized or long-running processes or connections.

Scheduled actions are subject to a limited execution time. If a scheduled action consistently exceeds its allotted timeout, it will be automatically disabled by the platform, and project administrators will receive a notification.

Staging and development builds are restricted to a single worker, which has limitations on concurrent requests and system resources. For these build types, scheduled actions are only triggered a few times a day.

It is not possible to install system packages or modify the configuration of the system images within the containers, even under dedicated hosting environments. Furthermore, for security reasons, the suid bit of executables in system images is cleared, including the ping binary in older Ubuntu releases.

Overloading the long polling or WebSocket communication layer, both server-side and client-side, is not supported.

The total number of tables and sequences within an Odoo.sh database must not exceed 10,000.

The use of Odoo.sh is governed by the Odoo Cloud Acceptable Use Policy.

Internet Access for Containers

Yes, Odoo.sh containers have nearly unrestricted access to the internet, allowing for seamless integration with external services. However, there are a couple of exceptions:

Port 25 is permanently closed. To connect to an external SMTP server, you must use ports 465 or 587.
Long-living connections will not persist through worker recycling. We strongly advise against implementing long-living connections to or from external services, as this use case is not supported by the platform's architecture.

Automatic Addons Folder Detection

Yes, the Odoo.sh platform automatically detects your addons folders based on the presence of __manifest__.py files within each addon directory. This intelligent detection streamlines the process of integrating custom modules into your Odoo instance.

This mechanism is precisely how submodules function: If you integrate a repository containing Odoo addons as a submodule of your branch, the folder housing that submodule will be automatically recognized as an addons folder and included in your database's addons path.

A git submodule allows you to incorporate other Git projects into your codebase without the need for manual copy-pasting, effectively managing external dependencies.

Integrating External Addons as Submodules

Before you begin, ensure you have a Git repository that contains Odoo modules. These can be applications from the Odoo Apps store or community modules from platforms like GitHub.

Private Repositories

Github private repositories require a few additional configuration steps to ensure Odoo.sh can successfully fetch your private code.

Go to your Odoo.sh project Settings then look for the Submodules section.
Paste the URL of your sub-repository (e.g., git@github.com:USERNAME/REPOSITORY.git) and click on Add.
Copy the Public key (it should look like ssh-rsa some...random...characters...here...==). We currently support ssh-rsa and ssh-ed25519 keys.
Go to your sub-repository Settings page on Github then look for the Deploy keys tab.
Click on Add deploy key and paste the public key into the Key field. You can add "Odoo.sh" as title and save.
Now follow the steps described hereunder for the Public repositories.

Public Repositories

For public repositories, you do not need to set up a deploy key. Follow these steps to add your sub-repository as a submodule to your Odoo.sh project:

Let your project "know" that you require a submodule: git submodule add -b BRANCH git@github.com:USERNAME/REPOSITORY.git PATH.
Commit this change and push it: git commit -a && git push -u origin master.
Wait while Odoo.sh builds your project... and it's done!

Python Dependencies

You can specify Python dependencies for your project by including requirements.txt files. These requirements files should be placed at the root of the folders containing your addons. The Odoo.sh platform will then automatically install these dependencies for each build, ensuring your environment is always ready.

System Dependencies

It is not possible to directly install or upgrade system packages (e.g., apt packages) within an Odoo.sh instance. However, if a package demonstrates broad utility across multiple projects and meets specific criteria, we may consider installing it by default in the container images. The requirements for such packages are:

There should be no conflict with the rest of the packages.
The software should not run as (or depend on) a long-running service or daemon.
No elevated privileges or additional system users should be required.
The software should not directly or indirectly represent a security attack vector nor favor the infringement of our Acceptable Use Policy.
The software should run flawlessly in a constrained Linux namespace environment with cgroup limits on memory, processes, threads, files, ... (this excludes greedy VMs such as Java).

Similarly, for Python modules that require underlying system packages for compilation, please submit a support ticket providing details about your specific use case. Our team will review the request.

It is important to note that accepted system packages will be maintained as long as the aforementioned conditions are met. Should conflicts arise during platform upgrades to a more recent OS distribution, a package may be subject to removal.

PostgreSQL Dependencies and Extensions

PostgreSQL extensions, such as PostGIS or ltree, are not supported on Odoo.sh. Consequently, it is not possible to install these extensions within an Odoo.sh database.

Third-Party Odoo Modules

While third-party Odoo modules are generally subject to the same restrictions outlined above, some modules may be inherently incompatible with Odoo.sh due to technical design. Below is a list of known incompatible modules:

queue_job: This module can cause performance degradation (depending on the amount of workers) that may lead to the infringement of our Acceptable Use Policy.
odoo_agent (and its forks): This module can cause long polling breakage on Odoo.sh.

Odoo Instances API (XML-RPC)

Each Odoo build includes an XML-RPC interface, enabling external applications to interact with your Odoo instance. Comprehensive documentation for the Odoo API is available on the official Odoo website. In order to connect to your database, you will need:

The database URL (e.g., mydatabase.dev.odoo.com)
The port number is 443
The database name can be found in the shell by typing the following command: echo $PGDATABASE
The login and password for the desired user

Odoo.sh Platform API

Currently, there are no immediate plans to develop an API for direct interaction with the Odoo.sh platform itself (e.g., for creating new projects, branches, or requesting rebuilds). This feature is considered a lower priority in the Odoo.sh development roadmap.

Deleting Projects and Associated GitHub Repositories

Deleting a GitHub repository does not automatically delete the corresponding Odoo.sh project. This design choice prevents accidental deletion of a production database without proper warning. If you intend to create a new project, you must first delete the existing one. This can be done by navigating to your project's settings page (https://www.odoo.sh/project/<your_project>/settings) and following the deletion procedure at the bottom of the page.

Support for Other Source Code Management (SCM) Systems

While support for other Source Code Management (SCM) systems like GitLab or Bitbucket may be introduced to Odoo.sh in the future, it is currently considered a low priority on the Odoo.sh feature wishlist. Nevertheless, a workaround exists to use repositories hosted by providers other than GitHub on Odoo.sh. This involves utilizing an intermediate GitHub repository that links to your primary repository via a submodule. While perhaps less convenient than direct integration, this method allows for broader SCM compatibility.

For Testers

Internet Access for Testing Environments

Yes, testing environments on Odoo.sh do have internet access, with the exception that port 25 is not permitted for outgoing connections. For more detailed information on internet access within Odoo.sh containers, please refer to the question Do I have Internet access on Odoo.sh containers?.

Build Lifecycle and Garbage Collection

To optimize storage and make room for new development builds, older builds are periodically garbage collected. Production instances are, of course, excluded from this process to ensure data persistence. If you need to rebuild an instance for an existing branch, you can easily do so using the "Rebuild" button on the Builds page.

Expired Database Management

Databases that have been expired for more than three months are automatically locked by the Odoo.sh platform. If this applies to a staging or development build, you can simply use the "Rebuild" button on the Builds page to create a fresh instance. Should you need to recover data from an expired database, its dump remains available for download. For production databases, you have the option to start anew by drag and dropping the production branch to development and then back to production, or you can contact our support team if you require assistance with unblocking it.

Demo Data in Development Branches

Development branches on Odoo.sh are always created with demo data pre-installed. In contrast, production branches are initiated as completely empty instances. The primary purpose of development branches is to facilitate the execution of unit tests, which, in the current Odoo framework, rely on the presence of demo data. In the future, if test data becomes distinct from demo data, we will re-evaluate the possibility of creating development builds without demo data.

Staging Environment Configuration

The Odoo.sh platform automatically manages most standard integrations within the staging environment to ensure a safe and controlled testing space. By default, several key functionalities are modified:

All outgoing emails are captured automatically (and custom outgoing mail servers are deactivated).
All scheduled actions (ir.cron jobs) are deactivated, with the exception of the "Garbage Collection" one.
All ir.logging entries generated by Odoo.sh are removed.
Social integrations are turned off (Push notifications, Facebook, LinkedIn, ...).
Shipment provider configurations are put in test mode or deactivated (DHL, Fedex, UPS,...).
Bank account synchronizations are put in sandbox mode (Yodlee, Ponto, ...).
Seller accounts for marketplaces sync are removed (eBay, Amazon, ...).
All built-in payment processor credentials are removed (Stripe, Paypal, Ingenico, ...).
Calendar and drive sync tokens are removed (Google Calendar and Google Drive, Microsoft calendar, ...).
In-App-Purchase (IAP) accounts are removed (Lead enrichment, Invoice OCR, ...).
Localization-related government EDIs (e-Invoice, ...) tokens are removed.
The /robots.txt website route is disabled to prevent duplicated content SEO penalties.

Additionally, special environment variables are provided to allow your code to dynamically adapt to the specific environment:

ODOO_STAGE: Contains the current stage; possible values can be (but are not limited to): production | staging | dev. Other values are used for non-customer-facing internal stages and for support.
ODOO_VERSION: Matches the current build's Odoo version (e.g., 15.0).

For Project Managers

Odoo.sh Project Access and Subscriptions

Access to Odoo.sh projects varies based on your subscription type:

Partners: Benefit from unlimited trial projects, providing extensive opportunities for evaluation and testing.
Enterprise customers: Must include Odoo.sh in their enterprise subscription to gain access to the platform.

For comprehensive details on subscription tiers and pricing, please consult our official pricing page.

Subscription Code Validity Error

If you encounter the error message: "The provided subscription code does not appear to be valid for Odoo.sh" during project creation, it indicates that your subscription is either not a partnership subscription or an enterprise subscription that does not include Odoo.sh. Please verify your subscription details or contact support for clarification.

Trial Project Overview and Limitations

A trial project is activated using a partnership subscription code and is specifically designed for testing and evaluating the Odoo.sh platform. It grants access to the full suite of Odoo.sh features, unless explicitly stated otherwise. Trial projects are subject to certain limitations, including a single worker, two staging environments, and 1GB of storage per database build.

These projects are available for a period of 30 days, after which they are automatically terminated. If you wish to continue using the project beyond this period, it is essential to obtain a subscription for the Odoo.sh products and update the activation code on the Settings page accordingly before the trial expires. It's crucial to understand that trial projects should not be used for storing valuable data, as backups for trial projects are not guaranteed in the same way as paid projects and may be deleted after the trial period concludes.

Exporting Your Production Database from Odoo.sh

Yes, you have the flexibility to export your production database from Odoo.sh if you decide to host it on your own Odoo server. This process involves generating and downloading a dump of your database, which can be done from the backups tab of your production branch.

Odoo Releases on Odoo.sh (On-Premise vs. SaaS)

The Odoo releases utilized by Odoo.sh are the same versions available for download and installation on your private machines, which are officially supported for on-premise deployments. We do not plan to incorporate the SaaS-specific releases of Odoo, as these are not designed for self-hosted installations, ensuring consistency with standard Odoo deployments.

For System Administrators

Importing Database Dumps

Yes, on both production and staging branches, you can import a database dump via the backups tab. It is imperative to ensure that the dump adheres to the requested format and is compatible with the exact Odoo version running on your instance. Please note that Odoo.sh exclusively hosts major Odoo versions; intermediate versions (e.g., 14.1, 15.2) are not supported for import or hosting.

Configuring Custom Domains

Within the settings page of your Odoo.sh project, under the "Custom domains" section, you can add custom domains for your production database. Once your domain is added to this list, you will need to configure the appropriate DNS entries with your domain name registrar. Perform the following operations:

Create a CNAME record www.yourdomain.com pointing to <yourdatabase>.odoo.com.
If you want to use the naked domain (e.g., yourdomain.com), you need to redirect yourdomain.com to www.yourdomain.com.

We do not permit the direct configuration of naked domains within the platform because these domains require A records, which accept only IP addresses as values. The IP address of an Odoo.sh database can change due to upgrades or hardware failures, potentially rendering your A record configuration invalid without prior notification.

Note: When adding a domain name, the /robots.txt website route will be disabled for requests targeting your project's .odoo.com domain. This measure is implemented to prevent SEO penalties related to duplicated content.

SSL/HTTPS Configuration

SSL is enabled by default across all Odoo.sh projects. If your domain redirection is correctly configured, the platform will automatically generate an SSL certificate using Let's Encrypt within approximately an hour. Currently, the platform does not support the configuration of custom SSL certificates; however, we are actively considering this feature for future development.

Odoo Release Updates and Maintenance

You are not required to manually manage Odoo release updates, as the platform handles this process automatically. On a weekly basis, the Odoo.sh platform freezes a revision by selecting the latest stable set of builds for each version from our R&D CI platform (Runbot). The servers' Odoo repositories (odoo, enterprise, themes) are then updated accordingly. In exceptional circumstances, such as a major software issue or an urgent security update, this procedure may be triggered a second time within the week.

Note: It is important to acknowledge that in the event of severe security updates or critical hardware/performance problems, we reserve the right to interrupt service to upgrade the platform or restart a server, in full accordance with our SLA.

Odoo Version Support Lifecycle

Odoo offers free support, bug fixes, upgrades, and security updates for the three most recent major versions. Projects operating on older versions will incur additional charges for these services until they are appropriately upgraded. During this transition period, users will receive a weekly intermediate upgrade reminder before accessing the backend, and this message cannot be removed.

When an Odoo version reaches five years of age, it is phased out from Odoo.sh. While the project on Odoo.sh, along with all necessary upgrade tools, remains available, instances still running a phased-out version will no longer be accessible.

Backup Policy for Production Builds

Production builds on Odoo.sh are backed up every 24 hours. We maintain 14 full backups of each Odoo production instance for a period of up to three months: daily backups for seven days, weekly backups for four weeks, and monthly backups for three months. It is important to note that development and staging builds are not backed up, nor is their recovery guaranteed, as these builds are not intended for persistent data storage.

PostgreSQL External Access (Dedicated Hosting Only)

PostgreSQL External Access enables read-only connections from remote machines to an Odoo.sh database, primarily for integrating Business Intelligence (BI) tools. This feature is exclusively available to projects operating on dedicated hosting plans. The use of PostgreSQL clients that support SSL is mandatory. While some PostgreSQL clients are not compatible with Odoo.sh (e.g., PgAdmin and Qlik Sense have been identified as incompatible), most mainstream BI tools such as Power BI, Tableau, DBeaver, Datapine, and Zoho Analytics have been successfully tested. In cases where clients lack explicit SSL checkboxes, ?sslmode=require should be specified within the ODBC/JDBC additional parameters.

When operating in shared hosting mode, any required communication with third-party systems or applications (e-commerce, BI reporting, etc.) must be established at the HTTP layer.

Odoo.sh Data Center Locations

Odoo.sh leverages Google Cloud Platform (GCP) data centers in various global regions to ensure optimal performance and availability. These locations include:

Americas: Iowa, United States
Europe: Saint-Ghislain, Belgium
Middle East: Dammam, Saudi Arabia
Southern Asia: Mumbai, India
Other Asia: Singapore
Oceania: Sydney, Australia

It is not possible to request a change of region for an Odoo.sh project directly. However, this operation can be completed manually by transferring a backup from one project to another. Please note that the underlying hosting provider and the specific data center locations within a given zone are not contractual and are subject to change without prior notice. More information about our third-party service providers can be found in our privacy policy.

Server IP Address and Migration Policy

An Odoo.sh instance is not permanently bound to a specific server throughout its lifetime; it will be migrated multiple times across different servers during OS upgrades, server consolidation efforts, and other operational activities. Therefore, we do not disclose these variable and non-contractual details regarding server specifics.

Under dedicated hosting, a project's IP address may change during architectural migrations (occurring approximately every two years) or in the event of disaster recovery. For shared hosting, the infrastructure employs a server consolidation strategy, which can lead to projects being relocated to different servers in response to abnormal resource consumption or modifications in worker configurations.

In all scenarios, project administrators receive a notification when an IP address change occurs. Additionally, a mechanism is available to implement custom actions in response to an IP address change (e.g., sending an email, interacting with a firewall API). For comprehensive details, please refer to the documentation.

Renaming Your GitHub Repository

It is indeed possible to rename the repository linked to your Odoo.sh project. However, this change will only be reflected on Odoo.sh after the next commit is pushed to the repository. Even an empty commit is sufficient to trigger this update. An example of an empty commit command is: git commit --allow-empty -m "Changed repository ownership"; git push

Transferring GitHub Repository Ownership

You can transfer the ownership of the repository linked to your Odoo.sh project.

When a GitHub repository is transferred to an organization, OAuth restrictions are automatically enabled, which can disable webhooks. To ensure the platform continues to function properly, you must manually re-enable these webhooks:

Log into your GitHub organization with administrator privileges.
Navigate to the Settings > Webhooks section of your transferred repository.
Select Edit on the Odoo.sh webhook. Verify that there is no yellow notification at the top indicating that the webhook is muted.
If the webhook is muted, click on the last link in the yellow notification and Grant access to the Odoo.sh application within your organization.

This step is crucial for maintaining the functionality of your projects on the platform.

After performing the transfer and reactivating the webhooks, the platform will recognize the ownership and URL change upon receiving the next commit's webhook. An empty commit is sufficient to trigger this update; for example: git commit --allow-empty -m "Changed repository ownership"; git push

Note: In case the repository transfer is done from/to a GitHub organization, you need to have the appropriate permissions. If you don't, a workaround is to transfer the repository to a standard account as a middle step. In case of trouble please read the GitHub repository transfer documentation.