Yes, the containers have a (nearly) unrestricted access to the Internet.

Exceptions:

• Port 25 is (and will stay) closed. If you want to connect to an external SMTP server, you should use ports 465 and 587.
• Long-living connections will not survive to worker recycling. We discourage you to implement long-living connections to/from external services as this use-case is not supported by the platform.

Yes ! The platform will automatically detect your addons folders based on the manifest files (__manifest__.py) of each addon.

This is actually how submodules work: If you add a repository containing Odoo addons as a submodule of your branch, the folder holding the submodule will be detected as an addons folder to include in the addons path of your database.

A git submodule allows you to integrate other Git projects into your code, without the need to copy-paste all the code (in short).

Required before starting: a Git repository containing some Odoo modules. It can be some apps from the Odoo Apps store or some community modules.

Private repositories

Github private repositories require a few more steps in order to configure properly your submodules. They ensure that Odoo.sh will be able to fetch your private code.

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

Public repositories

Here are the steps to add your sub-repository as a submodule of your Odoo.sh project (you don't need to set up a deploy key for public repositories).

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

Python dependencies:

You can define requirements.txt files in your branch holding the python dependencies your project relies on. These requirements files can be placed in the root of the folders containing your addons. The platform will then install the dependencies for each build.

System dependencies:

It is not possible to install or upgrade system packages in an Odoo.sh instance (e.g. apt packages).

Nevertheless, if the package could be useful for more than one project, we will consider to install it by default in the containers images if the package meets the following requirements:

• there should be not 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)

The same goes for python modules requiring system packages for their compilation. In such a case, post your package request in a support ticket and provide some details about your use-case.

Please note that accepted system packages will be kept as long as the above conditions are met. Should a conflict arise when the platform is moving to a more recent OS distribution, it may be removed.

PostgreSQL dependencies:

PostgreSQL extensions are not supported on Odoo.sh hence it is not possible to install extensions (such as PostGIS, ltree, ...) in an Odoo.sh database.

Third party Odoo modules:

Third party Odoo modules are subject to the same restrictions stated above, but occasionally some modules might be incompatible by design with Odoo.sh for technical reasons. Here is the list of incompatible modules we are currently aware of:

• queue_job causing performance degradation (depending on the amount of workers) that can lead to the infringement of our Acceptable Use Policy.
• odoo_agent (and forks) causing long polling breakage on Odoo.sh

Odoo instances API

Each Odoo build comes with an XML-RPC interface. It allows you to interact from an external application. You can find here the documentation for the Odoo API.

In order to connect to your database, you will need:

1. the database URL (eg: mydatabase.dev.odoo.com)
2. the port number is 443
3. the database name can be found in the shell by typing the following command: echo $PGDATABASE.
4. the login and password for the desired user

Platform API

If you are looking for an API to interact with the Odoo.sh platform (eg: creating a new project, new branches or requesting a rebuild), this is not planned to be developed for now.

Deleting the Github repository does not delete the project, for the simple reason that an accidental deletion of the repository could potentially drop a production database without any warning.

If you wish to create another project, you must first delete the old one. You can do so by going to the page https://www.odoo.sh/project/<your_project>/settings and follow the deletion procedure at the bottom of the page.

Support for other SCM such as Gitlab, Bitbucket... might land in Odoo.sh at some point in the future but these are currently considered as a low priority in the Odoo.sh features wishlist.

That said, you still have a mean to use a repository hosted by another provider than Github on Odoo.sh by using an intermediate Github repository which links to your repository through a submodule. This is less comfortable than using Gitlab, Bitbucket... directly but this is a workaround you'd want to consider.

Yes, but port 25 is not allowed.

For more information, refer to the question Do I have Internet access on Odoo.sh containers?

Builds are garbage collected after some time to make room for new development builds (production instances are, naturally, excluded from this process).

If you wish to rebuild an instance for an existing branch, you can use the "Rebuild" button on the Builds page.

The platform will automatically lock databases that are expired for more than 3 months. If this was a staging or development build, simply use the "Rebuild" button on the Builds page to have a new one. If you need to salvage the expired database you can still download its dump. If it's a production database, you can start over by drag and dropping the production branch to development and back to production to make a fresh start, or you can contact us if you need it unblocked.

Development branches are always built with demo data installed. Only production branches are created completely empty.

The point of the development branches is to run the unit tests. Currently, in Odoo, these unit tests depends on the demo data.

In the future, if the test data get separated from the demo data, we would then consider the possibility to create development builds without demo data.

Most of this is taken care of by the platform, for all standard integrations.

By default, in the staging environment:

• all outgoing emails are captured automatically (and custom outgoing mail servers are deactivated)
• all scheduled actions (ir.cron jobs) are deactivated, except 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

In addition, special environment variables are available if you'd like your code to dynamically adapt to the 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 (eg: 15.0)

• Partners: unlimited trial projects.
• Enterprise customers: You must subscribe to Odoo.sh, meaning your enterprise subscription has to include Odoo.sh.

You can read our pricing page to learn more.

When creating your project, if you have the error message:
The provided subscription code does not appear to be valid for Odoo.sh
It means your subscription is either not a partnership subscription, either this is an enterprise subscription which does not include Odoo.sh.

A trial project is activated with a partnership subscription code and is designed to test and evaluate Odoo.sh. It grants access to the full suite of features Odoo.sh offers unless explicitly mentioned. Trial projects are limited to 1 worker, 2 staging environments and 1GB of storage per database build.

These projects can be utilized for 30 days before they are terminated. If you intend to continue using the project, please obtain a subscription for the Odoo.sh products and update the activation code on the Settings page accordingly before the trial period expires.

A trial project should not be used to store valuable data, as backups of trial projects are not guaranteed like those of paid projects and may be deleted after the trial period ends.

Yes, you can.

If you decide you no longer want your production database to be hosted by Odoo.sh, you can download a dump of your database and import it on your own Odoo server.

You can generate and download a dump of your database in the backups tab of your production branch.

The Odoo releases used by Odoo.sh are the releases you can download and install on your own machines, and which are officially supported to be used as on-premise installation. For that matter, we do not plan to use the saas releases of Odoo, which are not meant to be installed on an on-premise installation.

Odoo.sh allows you to create a project in any of the supported major versions.

Once a version reaches its end of support, projects still using this version will have 2 years to upgrade to any of the supported major versions. After these 2 years, any database still using this version will no longer be available for its users.

Yes, on production or staging branches under the backups tab you can import a database dump. Make sure it is of the requested format and runs on the same version of Odoo.

Note: Odoo.sh only hosts major Odoo versions, intermediate versions (eg: 14.1, 15.2) are not supported.

In the settings page of your project, under the section "Custom domains", you will be able to add custom domains for your production database.

Once your domain added to this list, you will have to set the DNS entries in the manager of 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 allow to configure naked domains in the platform because these domains must be configured with A records which only accept IP addresses as possible values. The IP address of each database can change, following an upgrade or a hardware failure, and this would mean the configuration of the A record for the naked domain could suddenly no longer work, without notification.

Note: when adding a domain name, the /robots.txt website route will be disabled for requests reaching your project's .odoo.com domain in order to avoid SEO duplicated content penalties.

SSL/HTTPS

SSL is enabled by default. If the redirection is correctly set up, the platform will automatically generate an SSL certificate with Let's Encrypt within the hour.
It is currently not possible to configure your own SSL certificates on the Odoo.sh platform. We are considering the feature.

You don't have to, the platform does it for you. On a weekly basis, the platform freezes a revision by selecting the last green set of builds for each version on our R&D CI platform and the servers's Odoo repositories (odoo, enterprise, themes) are updated accordingly. On special occasions, this procedure might be triggered a second time during the week in case of major software issue or when an urgent security update is published.

Note: in case of severe security update or hardware/performance problem, we reserve the right to interrupt the service in order to upgrade the platform or restart a server, and this in accordance with our SLA.

Odoo provides support and bug fixing for the 3 last major versions of Odoo.

Odoo.sh was designed to enforce this policy, but we allow for a 2-year extension after a version becomes unsupported. During this two-year extension period, users will see a weekly intermediate message before accessing the backend, and there's no way to remove this message.

After this 2-year extension, when an unsupported Odoo version reaches the age of 5 years, it is phased out of Odoo.sh. The project on Odoo.sh as well as all tools required for a successful upgrade remain available, however project's instances still using a phased out version will no longer be accessible.

Production builds are backuped every 24 hours.

We keep 14 full backups of each Odoo production instance for up to 3 months: 1/day for 7 days, 1/week for 4 weeks, 1/month for 3 months.

We do not backup nor ensure recovery of development and staging builds as those builds are not assumed to be used for persistent data storage

PostgreSQL External Access allows read-only connections from remote machines to an Odoo.sh database, such as for connecting BI tools. This feature is exclusively accessible to projects operating on dedicated hosting. The use of PostgreSQL clients that support SSL is mandatory. Some PostgreSQL clients are not compatible with Odoo.sh. To date, PgAdmin and Qlik Sense have been identified as incompatible. Most mainstream Business Intelligence tools (Power BI, Tableau, DBeaver, Datapine, Zoho Analytics) have been successfully tested against the feature. It should be noted that sometimes there are no checkboxes to force SSL. In such cases, ?sslmode=require should be specified in the ODBC/JDBC additional parameters.

When operating in shared hosting mode, if you require communication with a third-party system or application (e-commerce, BI reporting, etc.), you will need to establish the integration at the HTTP layer.

Odoo.sh uses the following GCP data centers:

• 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 to change the region of an Odoo.sh project 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 locations of the data centers within a zone are not contractual and subject to change without notice. Read more about our third party service providers.

An Odoo.sh instance is not bound to a particular server for it's whole lifetime and will be migrated many times on different servers during OS upgrades, server consolidation, ...
Therefore we do not communicate those varying noncontractual details.

Under Dedicated hosting, a project's IP address changes during architectural migrations (approximately every two years) or in the event of disaster recovery.

The Shared hosting infrastructure employs a server consolidation strategy, which may result in projects being relocated to different servers in response to abnormal resource consumption or changes in worker configurations.

In all cases, a notification is sent to project administrators when an IP address change occurs. Additionally, a mechanism is available to apply custom actions in response to the IP address change (eg: sending an email, contacting a firewall API, ...). For more details, please refer to the documentation.

It is indeed possible to rename the repository linked to your Odoo.sh project. However, the change will only be reflected on Odoo.sh after the next commit.

Even an empty commit is sufficient to trigger the update. Here is an example of empty commit:

git commit --allow-empty -m "Changed repository ownership"; git push

It is indeed possible to 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 need to manually re-enable these webhooks:

1. Log into your GitHub organization with administrator privileges.
2. Navigate to the Settings > Webhooks section of your transferred repository.
3. Select Edit on the Odoo.sh webhook. Verify that there is no yellow notification at the top indicating that the webhook is muted.
4. If the webhook is indeed 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 webhooks reactivation, the platform will be aware of the ownership and url change upon the reception of the next commit's webhook. Even an empty commit is sufficient to trigger the update, here is an example of empty commit:

git commit --allow-empty -m "Changed repository ownership"; git push

Note: in case the repository transfer is done from/to a github organisation, 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 .