Odoo.sh: Own Your Custom Code and Infrastructure

The Problem with Delegated Odoo.sh Control

Odoo.sh offers a streamlined cloud platform for building and deploying customized Odoo instances. It integrates tightly with GitHub, facilitating automated deployments and staging environments. This setup is ideal for businesses leveraging custom development to extend Odoo's core functionalities. However, the convenience of outsourcing development to an Odoo Partner can obscure critical ownership and access issues, particularly concerning the custom code and the underlying Odoo.sh project infrastructure. Without a clear strategy, businesses risk becoming dependent on their partner for access to their own intellectual property and operational control.

A common pitfall is the implicit assumption that the partner managing the development automatically 'owns' the project's digital assets. This can manifest in various ways: the partner might control the primary GitHub repository, hold the master administrative access to the Odoo.sh project, or host proprietary modules in a way that ties them inextricably to their own accounts. Such arrangements, while often born from a desire for efficiency, can create significant friction and cost if the business relationship changes. The potential for downtime, loss of custom development, or protracted negotiations during a partner transition makes a proactive approach to ownership essential.

This article outlines a strategy for customers to maintain control over their Odoo.sh projects and custom code, even when delegating the day-to-day development work. By understanding and implementing key principles around subscription ownership, repository control, and contractual agreements, businesses can mitigate risks, ensure business continuity, and establish a more stable and balanced project evolution path. The goal is to empower the customer with administrative control without necessitating in-house technical expertise for daily operations.

Owning Your Odoo.sh Project

The foundation of control on Odoo.sh begins with the customer organization owning the Odoo.sh project itself. This administrative ownership is distinct from the technical execution of development. Even if an implementation partner handles all coding and deployment tasks, the customer retaining primary administrative access ensures they are never locked out of their own environment. This means having the ability to grant or revoke a partner's access to the instance, ensuring that access is contingent on the business relationship.

Customer ownership of the Odoo.sh project provides several tangible benefits. It guarantees perpetual access to one's own data, irrespective of partner relationships. If a change in partners is necessary, the customer can facilitate a seamless transition without losing custom code developments or incurring significant downtime. Furthermore, it allows the customer to deploy code or restart environments themselves if they choose, or to delegate these tasks while retaining the option. Visibility into build logs—tracking what custom code was deployed and when—is also a crucial advantage, offering transparency and auditability.

Ultimately, owning the Odoo.sh project, alongside the GitHub repository, empowers the customer to make all administrative decisions regarding the project's evolution. This centralized control fosters a far more stable and balanced technical structure compared to setups where infrastructure access is split or entirely held by a third party. It prevents custom code from becoming locked into a specific partner's setup, facilitating smoother upgrades and platform management.

Securing Your Primary GitHub Repository

A critical point of failure in Odoo.sh projects arises when the customer does not own the primary GitHub repository that houses their project-specific custom code. If a third party exclusively owns this repository, access and administrative control are entirely dependent on their discretion. While this poses no immediate problem during a good working relationship, it becomes a significant risk if that relationship sours or ends.

To mitigate this risk, it is strongly recommended that the customer organization owns the primary GitHub repository. This repository should also be kept private to protect proprietary code. The implementation partner should be granted collaborator access, which allows them to work on the code, push changes, and manage branches, but does not give them administrative control over the repository itself. This distinction is vital for maintaining leverage and ensuring access to business-critical code.

When the customer owns the repository, they are never beholden to a partner for accessing or managing code that directly impacts their business operations. This independence is crucial for long-term operational flexibility and reduces the potential for disputes or delays during partner transitions. The ability to access, fork, or even transfer the repository provides a safety net that protects the investment in custom development.

Protecting Partner Intellectual Property

While the customer should own the primary repository containing their project-specific custom code, it is equally important to respect and protect the intellectual property of the implementation partner. Partners often develop reusable, proprietary modules that they leverage across multiple client projects. These modules represent their expertise and investment, and they should retain ownership over them.

Odoo.sh is designed to accommodate this scenario by securely linking multiple repositories during the deployment process. The customer's main repository, which they own, can be configured to include partner submodules. The service agreement is the natural and essential place to document how these partner-owned modules are licensed. This agreement should clearly define the customer's usage terms, any restrictions, and what happens to the license if the partnership terminates.

This approach ensures that the partner retains ownership of their proprietary assets, while the customer maintains control and ownership over their project's unique customizations. It fosters a relationship built on clear terms and mutual respect, allowing both parties to focus on delivering value. The contract becomes the mechanism that protects both sides: the customer gains peace of mind about their options and access, and the partner has a well-defined role and protection for their intellectual property.

Structuring Contracts for Clarity

The technical arrangements for Odoo.sh projects must be underpinned by a robust and clear contractual agreement. Relying on implicit understandings or general partnership terms is a recipe for future complications. The contract should explicitly address key aspects of technical ownership, access rights, and exit strategies.

Specific clauses should detail the access rights granted to the partner, not only to the Odoo.sh instance but also to the GitHub repository. It should clearly define the conditions under which code transfer will occur, including the format and timeline for handover upon termination of the relationship. Responsibilities of both parties upon termination, such as data access, code repository handover, and any ongoing obligations, must be clearly spelled out.

A well-structured contract provides peace of mind for the customer regarding their future options and ensures that custom code developments are not held hostage by a defunct or adversarial relationship. For the partner, it clarifies their role, responsibilities, and the protection of their intellectual property throughout the engagement. This clarity is paramount for a successful and sustainable Odoo implementation.

Granting Collaborator Access vs. Ownership

When working with an Odoo Partner on Odoo.sh, it is crucial to differentiate between granting collaborator access and transferring ownership. The customer organization should always retain ownership of the primary GitHub repository containing their custom code and the Odoo.sh project itself.

Collaborator access on GitHub allows an individual or team to clone, commit, push, and manage branches within a repository. This is precisely what an implementation partner needs to perform development tasks. However, it does not grant them the ability to delete the repository, change its visibility settings, transfer ownership, or manage billing and access controls for other users.

By granting collaborator access rather than ownership, the customer ensures that the partner's ability to impact the repository is limited to the scope of their agreed-upon development work. This prevents a scenario where a partner could unilaterally take control of or remove access to critical project code, thereby safeguarding the customer's investment and operational continuity.

Keeping Proprietary Partner Modules Separate

A common and effective practice involves keeping proprietary partner modules in their own, separate GitHub repository, distinct from the customer's primary repository. This reinforces the principle of intellectual property ownership and simplifies management and licensing.

The customer's primary repository, owned by the customer, will contain all custom code specific to their project and business needs. The partner can then maintain their own repository for their general-purpose or proprietary modules. Odoo.sh allows for the inclusion of code from multiple repositories, enabling the customer's primary repository to link to and deploy code from the partner's repository as a submodule or via specific deployment configurations.

This separation makes it clear which code belongs to the customer and which belongs to the partner. It simplifies the process of licensing partner modules, as the terms can be clearly defined in the contract without being confused with the customer's own code. This also makes it easier for the customer to manage upgrades or potentially switch partners, as their core custom code remains entirely under their control, independent of the partner's proprietary offerings.

Visibility into Build Logs and Deployments

One of the significant advantages of owning your Odoo.sh project and its associated GitHub repository is the inherent visibility into the build and deployment process. Odoo.sh provides detailed logs that track every code change, build execution, and deployment event.

When the customer holds administrative access, they can readily access these logs. This allows them to see precisely which custom code was deployed, when it was deployed, and whether the build process was successful. This transparency is invaluable for auditing, debugging, and understanding the evolution of the codebase. It helps in identifying potential issues early and provides a clear history of changes.

This visibility also empowers the customer to understand the impact of custom code on their Odoo instance. If a deployment introduces a bug or unexpected behavior, the logs can often pinpoint the specific commit or module responsible. Without this access, customers might be entirely reliant on their partner's reporting, which may not always be as detailed or timely as direct access would allow.

Where This Approach Does Not Fit

While owning your Odoo.sh project and GitHub repository offers significant advantages in control and risk mitigation, it is not a universally required approach for every Odoo implementation. Businesses with extremely simple Odoo customizations or those who have a long-standing, exceptionally trusting relationship with a single, reputable partner might find the overhead of managing these ownership structures less critical.

Furthermore, this approach assumes a certain level of understanding or willingness to engage with administrative aspects of cloud platforms and code repositories. If a business has absolutely no technical inclination or desire to be involved in any aspect of project management beyond functional requirements, delegating full administrative control might still be their preferred path, despite the associated risks. In such cases, the onus is on the business to thoroughly vet their partner and ensure robust contractual safeguards are in place to mitigate the inherent risks of not holding direct control.

The core benefit of this ownership strategy is risk reduction and long-term flexibility. If those are not primary concerns, or if the implementation is so basic that vendor lock-in is not a practical threat, then focusing on more granular ownership might be unnecessary. However, for any project involving substantial custom development or where future flexibility in choosing partners is desired, adopting these ownership principles is highly recommended.