Deploying a Fully Dockerized Runbot


= Foreword =
In this article, we will deploy a fully Dockerized Runbot for use with testing or demoing your Odoo modules.

Runbot is a module for Odoo that will build, test, and subsequently run other Odoo instances based on commits in a git repo. For more information on using Runbot, check out these docs.

There are plenty of existing deploy strategies in use at the moment, but all of them have some drawbacks and none of them were fully compatible with our infrastructure or testing methodologies.

It should be noted that we are using the same strategy for our own Runbot, and will continue to update this article as we notice issues.

=The Stack=
Stack setup is outside of the scope of this documentation. At a minimum, you need one server (or VM) with:

The strategy provided here spawns Runbot in its own Docker container, and all of the Odoo testing instances in containers of their own.

This is an expansion of the current strategy used by the Odoo Community Association, which is to use a manually installed Runbot instance to test using containerized Odoos. The containerized testing is provided by Runbot Travis2Docker, which was created by our friend Moisés López at Vauxoo.

Load balancing is provided by Traefik instead of the standard Nginx that is built into Runbot core. Traefik provides the concept of a backend and fully supports Docker as one of them, so the setup is much less hacky all around. We created a new module runbot_traefik to support this logic, which is currently up for review.

The Runbot image itself is based from docker-odoo-base, which was created by our friend Jairo Llopis at Tecnativa. We use variations of this base for all of our production and development Odoo deploys.

The best part about Docker is that the deploy step is insanely simple. We have published our image on DockerHub, which does most of the heavy lifting for you. There is a ReadMe available on the project’s Github page with some information and usage samples.

There is a sample production docker-compose file in the project repository. You will want to make sure to update the `ADMIN_PASSWORD`, `PGPASSWORD`, `PGUSER`, `POSTGRES_PASSWORD`, `POSTGRES_USER` environment variables in the compose file to something more secure.

You can immediately start a Runbot instance by saving the sample file to a machine with Docker Compose installed, then running it:

sudo docker-compose -f production.yml up

Note the use of sudo in the above command. This is required because the cron instance requires privileged access to the host in order to act as the Dockerized Build Worker. It is also worth noting that the build worker is the only instance with privileged access to the host.

The production deploy sample uses the aufs filesystem driver for the named volumes, which is not available by default in some platforms. You can safely switch the instances of aufs at the top for any of the supported Docker drivers, or take a look at the Docker documentation for setup instructions. The following is an example of the error you would see when aufs is not available:

ERROR: Volume runbot-builds specifies nonexistent driver aufs

Our production deploy automatically sets up the db and installs some required modules using the install container. Once that container has finished setting up your database, it will stop and the others will start. This strategy helps us to avoid concurrency errors that would otherwise be generated when multiple Odoo containers try to perform the same database init at the same time.

After the installation, your new runbot will be exposed on port 80 of the host machine as In order to access it, you will need a line in your hostfile that looks similar to the below


Unfortunately wild cards are not possible in a host file, so the above is really only good to see that Runbot does actually work. Accessing the test instances would require a host entry for each instance. This is not an issue when using DNS.

You can change to your own hostname by simply updating the host rule in the production.yml file:

traefik.frontend.rule: ‘Host:;’


The initial username and password of the runbot instance will be admin/admin. You should immediately change this before exposing your deploy to the interwebz.

Before setting up any repos, go into the Runbot settings (Settings => Runbot) and setup your Runbot Domain. This is required so that your builds are advertised on the correct DNS.

When setting up your Runbot repos, you must check the Travis to docker build and Is Traefik. Using these two options in combination will allow for your test Odoo instances to be built in Docker, and advertised over the Traefik load balancer.


==Repo SSH Keys==

The .ssh directory of the Odoo user is mounted to the named volume runbot-ssh. You should only expose this volume to the build workers (cron in our example) – there is no reason for any of the other containers to have access to these secure keys.

If you need to access a repository using Git over SSH instead of over HTTPS, you will need to set this folder up to include the following files as well as the necessary private keys:

* config
* known_hosts

All of the files in this directory should be owned to the Odoo user, with 600 permissions. In order to make sure, you should exec into one of the Runbot containers as root and edit them:

docker exec -it –user root HASH_OR_NAME_OF_RUNBOT_WEB_CONTAINER bash
chown odoo: -R /home/odoo/.ssh
chmod 600 /home/odoo/.ssh/*


After the Runbot instance has been deployed to your liking, you will need to make 2 DNS records – one for the Runbot domain, and one wildcard for the test instance. For example, if your Runbot domain is and your server’s public IP is you would need the following DNS entries:

* (A Record) =>
* * (CNAME) =>

After setting DNS, your Runbot instance will be exposed and ready to use!






Leave a Reply

Your email address will not be published. Required fields are marked *