For Developers

The containers do not have internet access.

The only way to contact the outside world is through http(s). The requests go through a proxy. wget, curl or the python module requests work out of the box.

This means that SMTP connections will not go through, preventing the use of custom SMTP servers. This is a current limitation of Odoo.sh.
Incoming emails are automatically proxied to the instances.

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.

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:

This is currently not possible to install system packages (e.g. apt packages).

Nevertheless, if the package could be useful for more than one project, we can consider to install it by default for everyone. Same goes for python modules requiring system packages for their compilation. In such a case, leave us a feedback.

We do not have an API for Odoo.sh, yet.

APIs, by design, must be as stable as possible, with the minimum of changes in the calls and the results behavior, so users using the API do not have to change their own development according to the changes of the API.

We cannot guarantee at the moment that we won't make changes in the way Odoo.sh works, so we are not comfortable developing such an API now. But that might come.

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 low priority in the Odoo.sh features wishlist.

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

For Testers

All development instances are accessed using the usual demo data credentials:

  • admin/admin
  • demo/demo
  • portal/portal

When a branch is switched to production, the credentials are admin/admin.
You then have to set them up yourself as you would on an on-premise installation.

Once the production database is set, every staging branch will be a duplicate of the production database, including the users & credentials.

No.
The containers do not have access to the internet.

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 in the Builds page.

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 relies 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.

For Project Managers

  • Partners: Freely.
  • Enterprise customers: You must subscribe to Odoo.sh, meaning your enterprise subscription has to include Odoo.sh.
You can read our pricing to know more about the costs of Odoo.sh.

If the free offer for partners changes in the future, we guarantee that any project created under this offer will remain free for the same set of features.

When creating your project, if you have the error message:
The subscription <referral 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.

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 download a dump of your database at anytime on the builds page of your project.

The Odoo releases used by Odoo.sh are the releases you can download and install on your own machines, and which are officialy 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.

For System Administrators

In the current beta version of Odoo.sh, there is no easy way to do this operation altough an "Import database" feature is planned for the release of Odoo.sh in January.

Meanwhile, it is actually possible to import a database manually through the webshell:

  • Download your database dump and filestore using wget
  • Drop all tables of your current database:
    psql -t -c "select 'drop table if exists ""' || tablename || '"" cascade;' from pg_tables WHERE schemaname = 'public';" | psql
  • Drop all remaining sequences of your current database:
    psql -t -c "select 'drop sequence ' || c.relname || ';' FROM pg_class c WHERE (c.relkind = 'S')" | psql
  • Restore your dump in the database you just emptied
    e.g. cat dump.sql | psql
  • Copy your filestore in the folder
    /home/odoo/data/filestore/<database_name>

After the import, the following changes should be made:

  • In the general settings, the catchall domain should be adapted to the Odoo.sh domain.
  • In the general settings, the outgoing mails servers should be disabled to let the one of Odoo.sh be used.

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 in 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 an hardware failure, and this would mean the configuration of the A record for the naked domain could suddenly no longer work, without notification.

SSL/HTTPS

To enable SSL, you can use a third-party CDN service provider such as CloudFlare.com.
This is currently not possible to configure your own SSL certificates in the Odoo.sh platform. We are considering the feature.