A module tested in a sandbox is not yours yet until it lives in your repository. This page covers the last two steps: versioning, then deploying.

Connecting your repository

Aidoo pushes the code to your GitHub repository. You remain the owner, and nothing depends on Aidoo to read it back or take it over.

Authorize Aidoo on GitHub

From Aidoo's GitHub page, grant access to the repository that will host your modules. A dedicated repository, separate from your other projects, keeps things readable.

Link the repository to the project

Each module project points to a repository and a branch. Several modules can share one repository, each in its own folder.

Pushing the code

The module works, push it to GitHub.

Claude sends the module's full directory tree to the configured branch, with a commit message describing the change. What you find in the repository is standard Odoo code: Python models, XML views, access rights files, manifest.

Push early, push often

Nothing requires waiting until the module is perfect. Every push creates a restore point, and the Git history tells the module's story far better than the conversation does.

Approval before production

Claude cannot deploy to production

This is a product limit, not a setting. No tool in the Modules connector can install anything on your real Odoo. The module can be marked ready; installing requires a human action in the Aidoo interface.

Going live has three cumulative conditions:

the module has been sandbox-tested in its current state
someone with the right role approves it explicitly
your plan allows production deployment, which excludes the free trial

Any file change after a test voids the first condition. There is no workaround: that is what guarantees nothing reaches your Odoo without having passed through a test instance.

What happens on deployment

The module is installed on your production Odoo like any other module: Odoo applies the migrations, creates the tables, loads the views and the access rights.

Take a backup first

An Odoo module can create columns and alter views. The operation is reversible in most cases, but a recent backup is the only real guarantee. On Odoo.sh, take the restore point; on Odoo Online, trigger a manual backup.

Deploy outside business hours where possible: installation restarts the Odoo service.

Evolving a module already in production

The cycle starts again identically: you describe the change, Claude edits the files, the project returns to draft, fresh sandbox test, fresh Git push, fresh approval.

Data migrations deserve particular care

Adding a field is risk-free. Renaming or removing a field that already holds production data is not: Odoo does not migrate existing values automatically. Say so explicitly to Claude so it writes the migration script, and test it on a sandbox loaded with a representative data set.

Diagnostics

The sandbox installation fails

That is normal development, not an incident. Claude reads the logs, identifies the Python or XML error, and fixes it. If the same failure returns three times, rephrase the need: the problem usually lies in the request, not the code.

The module installs but nothing is visible

Almost always a mis-targeted view or missing access rights. Check that your user belongs to the expected group, and ask Claude to verify the view inheritance.

The GitHub push fails

Check that the authorization is still valid and that the branch exists. A revoked GitHub token can be re-authorized from Aidoo's GitHub page.

Production deployment is greyed out

One of the three conditions is missing: no sandbox test since the last change, insufficient role, or a free trial in progress.

I want to take the module over without Aidoo

That is by design: the code sits in your repository, in standard Odoo format. Clone it, open it in your editor, install it like any module. No dependency on Aidoo remains in the produced code.

Next step

Developing a module from Claude: reviewing the full cycle
Creating a module: starting again from the need